On 11/29/2010 07:07 PM, Jason T. Greene wrote:
This was talked about briefly on the pull request list, but no
resolution was made.
The issue is that JBAS-8585 and JBAS-8599 both add module dependencies
from some of the core subsystems on to the osgi subsystem (naming and
transactions). In addition we already have a module dependency from
domain to osgi. So for all intents and purposes, we are moving towards
AS7 having osgi as a required base level component. Before progressing
much further in this direction we should evaluate whether this is the
right thing to do, and how this solution compares to alternative
approaches. I can think of three approaches right off the bat.
1. Continue as is, osgi is a core required component
Pros: OSGi subsystem module is simpler, no additional subsystems or
modules needed
Cons: AS7 must always have OSGi binaries no matter the configuration
2. Change the osgi subsystem to use optional dependencies on all of the
subsystems it maps.
Pros: No additional subsystems are needed
AS7 no longer requires OSGi binaries
Cons: osgi subsystem code will need to do a lot of conditional
checking for handling different subsystems being available
3. Create an osgi subsystem per subsystem it wraps (e.g. osgi-naming,
osgi-transactions, etc)
Pros: OSGi subsystem code is simpler
AS7 no longer requires OSGi binaries
Cons: More subsystems are introduced, almost one per functional
subsystem.
Let the debate begin :)
http://community.jboss.org/people/wolfc/blog/2010/11/26/strategies-for-se...
Right now OSGi is implemented using strategy #1. Not only the module,
but also the package scope is put on a slider and OSGi is added to it.
At the very least we should have it separated via packages, but this
does mean not-so vigilant developers will ultimately take short-cuts. In
itself that could be good or bad, but I think it ultimately just leads
to a scenario were we bicker over what's considered a hack and what's
considered functional regression.
Better go for strategy #3, put OSGi into a separate sub-module. This
will still keep the number of top-level modules to a minimum and allows
cross-cutting concerns to be implemented into sub-modules.
The same thing will happen once we start integrating transaction and
security across the board.
Don't take it all the way up to #4, way too much work. ;-)
The important thing is: don't put scopes on a sliding slope. Once we've
finished up a certain scope, close the book.
Carlo