On 9/24/2012 12:45 PM, David M. Lloyd wrote:
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.
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(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
>