8:47 a.m.
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
--
- DML