myfaces and tld scanning

[Jarek Gawor <jg...@gmail.com>]

Hi all,

I'm trying to get myfaces working in trunk. Myfaces has a TLD file (in
META-INF directory) that contains a servlet context listener that the
web container is supposed to discover and register at startup. That
servlet context listener sets things up so that myfaces works right.
The problems is that in OSGi environment the web container does not
really see other TLDs besides what's included in the application. So
I'm wondering how to discover these non-application TLDs that might be
required for the application to work. And it's not just a matter of
finding the TLD files, we also have to load/instantiate the listener
class specified in the TLDs.

I guess we could build some registry of TLDs but how would we know
that one set of TLDs are needed for app A and another set for app B?
Or what if there are two different versions of some TLDs?

Or maybe we just provide some specific solution for the jfs/myfaces
problem and not worry about generic solution for now?

Thoughts?

Jarek

Re: myfaces and tld scanning

[Jarek Gawor <jg...@gmail.com>]

I missed it initially but the myfaces builder was already dealing with
the myfaces ServletContextListener (by registering it explicitly).
However, it wasn't working right on Tomcat and with bundle-based
deployment. But I managed to fix it.
However, I still need to discover tlds in myfaces bundles, so here's
what I'm planning to do: In jasper plugin, create & register a service
that will act like a tld registry. In myfaces plugin, discover the
tlds (by following bundle wires) and register them with the tld
registry. Now, the jasper-module-builder and jasper runtime tld
scanner will be both updated to use that tld registry. Hopefully all
that will work and jasper will be able to get all the necessary tlds.
Any comments on this plan?

Even if the tld stuff works, I already see the next problem. Myfaces
is doing a resource lookup using context class loader (to find its own
jar file), gets null and fails... fun.

Jarek

On Fri, Jan 29, 2010 at 4:39 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Jan 29, 2010, at 12:54 PM, Jarek Gawor wrote:
>
>> Hi all,
>>
>> I'm trying to get myfaces working in trunk. Myfaces has a TLD file (in
>> META-INF directory) that contains a servlet context listener that the
>> web container is supposed to discover and register at startup. That
>> servlet context listener sets things up so that myfaces works right.
>> The problems is that in OSGi environment the web container does not
>> really see other TLDs besides what's included in the application. So
>> I'm wondering how to discover these non-application TLDs that might be
>> required for the application to work. And it's not just a matter of
>> finding the TLD files, we also have to load/instantiate the listener
>> class specified in the TLDs.
>>
>> I guess we could build some registry of TLDs but how would we know
>> that one set of TLDs are needed for app A and another set for app B?
>> Or what if there are two different versions of some TLDs?
>>
>> Or maybe we just provide some specific solution for the jfs/myfaces
>> problem and not worry about generic solution for now?
>>
>> Thoughts?
>
> One way to abstract this scenario might be:
>
> myfaces has a service (supplying a ServletContextListener instance)
> The myfaces MBE recognizes that the web app needs to use this service by
> finding some jsf goo in the web app.  So it could install something that
> calls the service at an appropriate time.
> When the app starts, this service-consuming code gets the servlet listener
> and installs it.
>
> This seems like it sidesteps the gooey ill-defined discovery mechanism?
>
> thanks
> david jencks
>
>
>
>>
>> Jarek
>
>

Re: myfaces and tld scanning

[David Jencks <da...@yahoo.com>]

On Jan 29, 2010, at 12:54 PM, Jarek Gawor wrote:

> Hi all,
>
> I'm trying to get myfaces working in trunk. Myfaces has a TLD file (in
> META-INF directory) that contains a servlet context listener that the
> web container is supposed to discover and register at startup. That
> servlet context listener sets things up so that myfaces works right.
> The problems is that in OSGi environment the web container does not
> really see other TLDs besides what's included in the application. So
> I'm wondering how to discover these non-application TLDs that might be
> required for the application to work. And it's not just a matter of
> finding the TLD files, we also have to load/instantiate the listener
> class specified in the TLDs.
>
> I guess we could build some registry of TLDs but how would we know
> that one set of TLDs are needed for app A and another set for app B?
> Or what if there are two different versions of some TLDs?
>
> Or maybe we just provide some specific solution for the jfs/myfaces
> problem and not worry about generic solution for now?
>
> Thoughts?

One way to abstract this scenario might be:

myfaces has a service (supplying a ServletContextListener instance)
The myfaces MBE recognizes that the web app needs to use this service  
by finding some jsf goo in the web app.  So it could install something  
that calls the service at an appropriate time.
When the app starts, this service-consuming code gets the servlet  
listener and installs it.

This seems like it sidesteps the gooey ill-defined discovery mechanism?

thanks
david jencks



>
> Jarek