You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Annotated Container is intended to be a fully-featured dependency injection container. That means, providing testing utilities to help with integration and acceptance testing using the container. With this type of testing it could be desired to change or alter services based on being in a testing profile; consider a LoggerInterface that outputs to normal locations in dev, but uses testing implementations if in test. While this works out-of-the-box, if the directory the test logger is in is not present or the autoloader does not include dev dependencies, a likely occurrence in production environments, a problem is encountered. Ultimately, if we scan a service, in this case a test logger, it must be loadable and it isn't.
Realistically, the only way to deal with this problem is to simply not scan the directory with the test service when you're in a profile that doesn't need it. This would also have the benefit of reducing the amount of files needing to be scanned when running in production environments.
This is a fairly significant change; more than 1 corresponding piece will need to be made profile-aware and a former list of scalar strings must now become a complex object capable of holding multiple pieces of information; the directory and any profiles it may be associated with.
The text was updated successfully, but these errors were encountered:
Annotated Container is intended to be a fully-featured dependency injection container. That means, providing testing utilities to help with integration and acceptance testing using the container. With this type of testing it could be desired to change or alter services based on being in a testing profile; consider a
LoggerInterface
that outputs to normal locations indev
, but uses testing implementations if intest
. While this works out-of-the-box, if the directory the test logger is in is not present or the autoloader does not include dev dependencies, a likely occurrence in production environments, a problem is encountered. Ultimately, if we scan a service, in this case a test logger, it must be loadable and it isn't.Realistically, the only way to deal with this problem is to simply not scan the directory with the test service when you're in a profile that doesn't need it. This would also have the benefit of reducing the amount of files needing to be scanned when running in production environments.
This is a fairly significant change; more than 1 corresponding piece will need to be made profile-aware and a former list of scalar strings must now become a complex object capable of holding multiple pieces of information; the directory and any profiles it may be associated with.
The text was updated successfully, but these errors were encountered: