[jboss-as7-dev] JBoss Modules: can I dynamically add dependency?

Mon Sep 24 16:57:27 EDT 2012

Have a look at

org.jboss.as.jpa.processor.JPADependencyProcessor#addHibernate3AdaptorToDeployment

This is an example of how to add additional resource roots to a module.

Stuart

ssilvert at redhat.com wrote:
> On 9/24/2012 12:45 PM, David M. Lloyd wrote:
>> On 09/24/2012 11:39 AM, ssilvert at redhat.com wrote:
>>> On 9/24/2012 12:18 PM, Jason Greene wrote:
>>>> There are two solutions to this problem.
>>>>
>>>> 1) Switch the interaction to use plugable constructs (common SPI (interfaces&  superclasses), dynamically loaded implementation which depends on the common SPI)
>>> Unfortunately, we don't control that part.  It's defined by the JSF impl.
>>>> 2) Dynamically generate a module with an extra resource root to the same jar
>>> That's what I wanted to do, but David says dynamic generation of modules
>>> is not possible given our performance constraints.
>> That's not what I said - I said the *initial* module loader is
>> static-only.  Of course modules can be dynamically generated, else our
>> deployment mechanism would not work.
> Great.  In that case I'm back in business.  Is there some doco on this?
> If not I guess I'll start looking at deployment code to see how this is
> done.
>>> The only other thing I can think of is to have a tool that installs and
>>> configures the modules for you.  Then the user or admin wouldn't have to
>>> do it by hand.  But such a tool would get rather complex in a domain
>>> configuration.
>>>
>>>> On Sep 24, 2012, at 10:29 AM, ssilvert at redhat.com wrote:
>>>>
>>>>> OK.  Thanks.
>>>>>
>>>>> This is alright for now because we only have two JSF impls.  But we want
>>>>> to allow users to install additional impls.  So it's a little ugly to
>>>>> tell them that they have to make another copy of the jsf-injection
>>>>> module for each one.
>>>>>
>>>>>
>>>>> On 9/24/2012 9:47 AM, David M. Lloyd wrote:
>>>>>> On 09/24/2012 07:49 AM, ssilvert at redhat.com wrote:
>>>>>>> On 9/24/2012 8:15 AM, David M. Lloyd wrote:
>>>>>>>> Unfortunately this premise is flawed from the start: if you had two
>>>>>>>> apps, each requiring a different JSF implementation, this idea could
>>>>>>>> never work.
>>>>>>> I'm not sure what you mean here.  This is already working.
>>>>>>>> In any case you cannot change the dependencies of a static module at
>>>>>>>> runtime.  Normally when multiple implementations are available you would
>>>>>>>> use reflection to instantiate the implementation you need.  If this is
>>>>>>>> not possible then you'll need a separate module for each implementation
>>>>>>>> type.
>>>>>>> That's the problem.  It's not that I need to instantiate something.
>>>>>>> Rather, I need to put jsf-injection in a position where the JSF impl
>>>>>>> will find my service and instantiate it.   So the way things are now I
>>>>>>> have to statically define a new jsf-injection module for each JSF impl.
>>>>>>> Those modules are exactly the same except for one dependency declaration.
>>>>>> If JSF is instantiating your module via SPI or similar then yes, you
>>>>>> will need to clone your classes for each implementation because you're
>>>>>> statically linking to the Mojarra API (meaning at run time your modules
>>>>>> are no longer exactly the same as classes have different supertypes and
>>>>>> so on).
>>>>>>
>>>>>>> If I could programatically define the module then I wouldn't have to
>>>>>>> repeat myself.
>>>>>>>
>>>>>>> Maybe JBoss Modules was never meant to be used that way?
>>>>>> If every Mojarra implementation is statically defined as a module, then
>>>>>> you will have to create separate static modules for each one.  If you're
>>>>>> loading them in from a deployment then you should use the deployers' API
>>>>>> for defining module dependencies to automatically tack on a copy of your
>>>>>> integration classes.
>>>>>>
>>>>>> The reason this is so is that in order to have the very fast startup we
>>>>>> have today, the initial module loader runs in a purely static environment.
>>>>>>
>>>>>>>> On 09/24/2012 07:06 AM, ssilvert at redhat.com wrote:
>>>>>>>>> I have a module defined like this (currently in master with main and
>>>>>>>>> slot="1.2):
>>>>>>>>> <module xmlns="urn:jboss:module:1.1" name="org.jboss.as.jsf-injection">
>>>>>>>>>        <resources>
>>>>>>>>>            <resource-root
>>>>>>>>> path="jboss-as-jsf-injection-7.2.0.Alpha1-SNAPSHOT.jar"/>
>>>>>>>>>        </resources>
>>>>>>>>>
>>>>>>>>>        <dependencies>
>>>>>>>>>            <module name="com.sun.jsf-impl"/>    <----- this needs to be dynamic
>>>>>>>>>            <module name="javax.api"/>
>>>>>>>>>            <module name="org.jboss.as.web"/>
>>>>>>>>>            <module name="javax.servlet.api"/>
>>>>>>>>>        </dependencies>
>>>>>>>>> </module>
>>>>>>>>>
>>>>>>>>> Inside a DeploymentUnitProcessor, the module above is added to the
>>>>>>>>> ModuleSpecification along with the module for the selected JSF
>>>>>>>>> implementation.  The problem I have is that the JSF Injection code is
>>>>>>>>> the same for any Mojarra implementation.  But to support multiple
>>>>>>>>> implementations I need to declare a separate jsf-injection module with a
>>>>>>>>> hard-coded dependency on each implementation installed.
>>>>>>>>>
>>>>>>>>> If I could create a module dynamically and dynamically add its
>>>>>>>>> dependencies then there would be no need to create more and more modules
>>>>>>>>> containing the same jsf-injection jar.
>>>>>>>>>
>>>>>>>>> I've been looking at the JBoss Modules API and I don't see how to do
>>>>>>>>> this.  Is it possible?
>>>>>>>>>
>>>>>>>>> Stan
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jboss-as7-dev mailing list
>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev