[jboss-as7-dev] bundles as modules?

Tue Apr 16 10:10:17 EDT 2013

On Apr 16, 2013, at 3:18 PM, Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 4/16/2013 9:07 AM, Thomas Diesler wrote:
>> 
>> On Apr 16, 2013, at 2:56 PM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>> 
>>> I'm trying to make a AS distribution that has no jars.  Instead,
>>> metadata points to a maven repository location for those jars.  I've
>>> patched Jboss Modules to make this work, but have no solution for OSGi.
>> 
>> This may relate to the Provisioner service
>> <http://community.jboss.org/wiki/ProvisionerServiceAndFeatureDeployment> topic.
>> We already have a component that understands Maven coordinates and can
>> provide named resources. If you are thinking of a special ModuleLoader
>> that can fetch modules on demand then this loader should preferably
>> simply call the Repository IMHO. In the near future it could call the
>> Provisioner service with the top level Requirements.
>> 
> 
> Here's my pull request.
> 
> https://github.com/jbossas/jboss-modules/pull/28
> 
> With this patch, only jar you need to boot jboss is jboss-modules.jar. It will optionally download (or look in local maven repository) for any other required jars.  I've written a bunch of long emails why this feature is interesting, I could forward them if you're interested.
> 
> I don't see why we'd want an AS dependency on some OSGi service.  The idea of only needing one *local* jar to boot AS is much more appealing, IMO.

I'd say that "one local jar" should first fetch a component that can provision the system in a consistent way. It would then work with a small set of top level requirements (i.e. one per subsystem). The transitive closure of jars that actually need to be provisioned to satisfy the feature requests should to be computed by a authority that guarantees a consistent solution (i.e. a Resolver) - the maven dependency tree is not suitable for this IMHO. 

Yes, there should be no dependency on the OSGi Framework. The org.osgi.resource API qualifies to model resources with associated capabilities/requirements just like any other API. It has intentionally been designed such that it is independent of OSGi. A resource can of course define named requirements on other resources as we do with modules.xml today. A named dependency however is a form of tight coupling, which violates the fundamental principal of modularity that you should be able to reason about A without having to know that B has a dependency on A - A and B should only define their own respective caps/reqs. It is the job of a resolver to figure out that B actually depends on A and not on some other resource that also provides a capability that B requires (e.g. a java package)

There should be no performance hit for that process. The Resolver could have a persistent view of wiring metadata that can be computed at build time. Performance wise this would be equivalent to reading module.xml files only that there is a guarantee that the wiring is consistent and that dependencies can be defined in a modular fashion.

> 
>>> 
>>> David Lloyd said he didn't understand why your bundles weren't
>>> deployed as modules.  I don't know what that means either, but that's
>>> what he said.
>> 
>> Don't what this means either ;-) but I regularly talk with him so I can
>> probably find out
> 
> Maybe that the OSGi layer delegates to JBoss Modules to resolve classloader dependencies?  That would make sense…

Dependencies defined by OSGi metadata are complex and go beyond the hard wired named dependencies that we have today - so in fact it would not make sense at all if you want to support the de-facto standard for modularity. Another standard that defines dependencies between resources is feasible and in its most simplistic form would use named dependencies. JBoss could decide to ignore the standard and treat everything in a proprietary way (i.e. with metadata defined in modules.xml). The result would be that JBoss says: I know the dependencies of Foo better than the author of Foo and replace loosely coupled dependency definitions by hard wired named dependencies. This would still work as long as Foo is part of the build process and subject to extensive QA validation. It would break, when Foo is allowed to come in late (i.e. at runtime). JBoss would require the author of Foo to provide an alternative set of named dependencies in a propriatary way that is only valid for a specific state of the runtime environment (i.e. the author/deployer must know the set of named resources that are available at deploy time). As a result Foo is not a module any more that can be reasoned about independently. 

> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20130416/e54c1441/attachment.html 