I have rolled back the changes, however I am not sure if it is possible to do this as a
decorator. From the spec section on how decorators are bound to beans:
8.3. A decorator is bound to a bean if: .... The decorator is enabled in the bean archive
containing the bean
I read this as meaning that I would need to add the Decorator to the beans.xml of
weld-extensions to bind the decorator to ResourceLoaderImpl, which would mean a dependency
on seam-servlet from weld-extensions, which is not ok.
If this is the case what about removing the private constructor of ResourceLoaderImpl and
specialising it in seam-servlet?
Stuart
On 10/04/2010, at 12:32 AM, Pete Muir wrote:
I noticed you committed a change that hard links the resource loader
to the servlet context - we really need to avoid doing things like this - now we've
tied every module that uses resources to running in Servlet! Seam 3 is no longer usable in
Weld SE....
I designed the resource loading mechanism to be full extensible, and allow alternative
sources of resources outside the classpath. So, what we can do inside the Servlet module,
is provide a decorator for ResourceLoader that adds in the ability to load from the
ServletContext. This way the need to duplicate all the logic for exposing the
ServletContext via a producer is avoided to.
Stuart, can you back out the changes you made to Weld Extensions (excluding the
getResources() changes), and add them into the servlet module from Seam as a decorator?
Thanks!
On 9 Apr 2010, at 12:52, Stuart Douglas wrote:
> Nik just pointed out on IRC that the BeanManager is availible before the
ServletContext is created, so I can fire a CDI event in the ServletContextListener and
then observe it in an Extension, which should solve my problem.
>
> Stuart
>
>
> On 09/04/2010, at 9:29 PM, Stuart Douglas wrote:
>
>> I know there are plans to add loading resources from the ServletContext to the
resource loading stuff in weld extensions, and I was wondering if anyone had any
idea's as to how to implement this?
>>
>> I was thinking about registering a ServletContextListener to get hold of the
ServletContext. For a war deployment this could be registered automatically with a web
fragment, while for an ear this will probably have to be registered manually.
>>
>> The only thing I am not really sure about is where to store the references to the
ServletContexts. As this is before Weld has started, I can't just stick it in an
application scoped bean or similar, and storing it in a static would require
weld-extensions (and thus seam-xml, and any other modules that depend upon
weld-extensions) to be included in the deployment, and not in the app servers lib
directory. I don't think that this is really acceptable, however I can't think of
any other way off the the top of my head.
>>
>> I really need this before the next release of seam-xml, as I currently can't
load beans.xml from WEB-INF.
>>
>> Stuart
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev