On 09/24/2012 11:39 AM, ssilvert(a)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.
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(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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
- DML