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

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)

2) Dynamically generate a module with an extra resource root to the same jar

On Sep 24, 2012, at 10:29 AM, ssilvert(a)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(a)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(a)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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev