|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
@Steve
Please keep in mind that most EE specs we have so far come from an era where we did not have modularity. For example, with a flat class path it may make sense to use java.util.ServiceLoader - in a modular environment does not. There are other constructs that break modularity - the obvious one is the thread context class loader.
This is not specific to OSGi it would be generally true for modular environments. When you work with OSGi, the service registry is your friend. The use of some other service discovery mechanism or factories that assume a flat class path should make you want to think a little.