I partly agree:
1.) yes, it's not really 100% defined in the spec, and this should get fixed
2.) no, Weld did definitely support this a few months ago
3.) Seam-faces uses the same impl thus you'd need to fix it there also
4.) the CreationalContext is also not defined as Serializable, and there is no
passivationId for those. So as per the pure spec, it would currently be impossible to
implement this if the Container doesn't provide Serializable Beans.
Weld still seems to implements Serializable (or Externalizable) for the CreationalContext,
so this part is already not spec conform. I see no reason why Weld cannot re-enable
serialisation support for Beans too ;)
We of course also need to ping Reza for resin. Pete, I don't remember anymore, was he
involved in our discussion about this early last year?
LieGrue,
strub
--- On Wed, 1/5/11, Michael Schütz <michaelschuetz83(a)gmail.com> wrote:
From: Michael Schütz <michaelschuetz83(a)gmail.com
Subject:
Re: [weld-dev] CODI and JBoss AS 6 final: ProjectStageActivationExtension didn't
implement the Extension interface
To: "Pete Muir" <pmuir(a)redhat.com
Cc:
"Pete Muir" <pmuir(a)bleepbleep.org.uk>,
"weld-dev(a)lists.jboss.org" <weld-dev(a)lists.jboss.org
Date: Wednesday, January 5, 2011, 11:15 PM
Pretty interesting!
Thanks a lot for all your help.
I did file an JIRA issue:
https://issues.apache.org/jira/browse/EXTCDI-118
Michael
2011/1/5 Pete Muir <pmuir(a)redhat.com
Basically the issue is that the spec doesn't place any mandate on a PassivationCapable
bean being serializable when passed to a Context impl. This is something we should
definitely change in the spec (see CDI-24) as it's quite simple for the container to
do for you, and something we can do in Weld for 1.2.0 (see WELD-793) but for CODI to be
"spec compliant" for CDI 1.0 it does need to remove this assumption.
NB OWB already does this hence why it works there.
On 5 Jan 2011, at 13:15, Pete Muir wrote:
Ok, so it sounds like a poor assumption by CODI that the Bean object
is serializable. Michael, I suggest you file an issue in their issue tracker for this.
On 5 Jan 2011, at 13:11, Mark Struberg wrote:
> Hmm Beans are serialized all the day if you use a @ViewScoped
context because the JSF ViewMap gets serialized/deserialized on every request. And the
ViewScopeContext stores all the beans (+contextual instances, dependent objects, etc) in
the ViewMap. I remember that this used to work in an earlier Weld version.
>
>
> LieGrue,
> strub
>
>
> --- On Wed, 1/5/11, Pete Muir <pmuir(a)bleepbleep.org.uk>
wrote:
>
>>> From: Pete Muir <pmuir(a)bleepbleep.org.uk
>> Subject: Re: [weld-dev] CODI and JBoss AS 6 final:
ProjectStageActivationExtension didn't implement the Extension interface
>>> To: "Michael Schütz" <michaelschuetz83(a)gmail.com
>>> Cc: "Dan Allen" <dan.j.allen(a)gmail.com>, "Mark
Struberg" <struberg(a)yahoo.de>, "weld-dev(a)lists.jboss.org"
<weld-dev(a)lists.jboss.org
>> Date: Wednesday, January 5, 2011, 11:24 AM
>> Weird, I wonder what is trying to
>> serialize a bean object, there is no spec requirement for
>> these to be serializable. Can you find out?
>>
>> On 5 Jan 2011, at 09:03, Michael Schütz wrote:
>>
>>> Dan,
>>> thanks again.
>>>
>>> Having MyFaces configured now.
>>>
>>> Getting following error:
>>> 09:58:21,068 INFO
>> [org.apache.myfaces.util.ExternalSpecifications] MyFaces
>> Unified EL support enabled
>>> 09:58:21,209 INFO
>>
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/myfaces-cdi-1.0.2-SNAPSHOT]]
>> No state saving method defined, assuming default server
>> state saving
>>> 09:58:28,820 SCHWERWIEGEND
>>
[org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementHelper]
>> Exiting serializeView - Could not serialize state:
>> org.jboss.weld.bean.ManagedBean:
>> java.io.NotSerializableException:
>> org.jboss.weld.bean.ManagedBean
>>> at
>>
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
>> [:1.6.0_21]
>>> at
>>
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
>> [:1.6.0_21]
>>> at
>>
java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1246)
>> [:1.6.0_21]
>>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [:1.6.0_21]
>>> at
>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> [:1.6.0_21]
>>> at
>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> [:1.6.0_21]
>>> at
>> java.lang.reflect.Method.invoke(Method.java:597)
>> [:1.6.0_21]
>>> at
>>
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
>> [:1.6.0_21]
>>> at
>>
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
>> [:1.6.0_21]
>>> at
>>
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
>> [:1.6.0_21]
>>> at
>>
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
>> [:1.6.0_21]
>>> at
>>
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
>> [:1.6.0_21]
>>> at
>> java.util.HashMap.writeObject(HashMap.java:1001)
>> [:1.6.0_21]
>>> at
>> sun.reflect.GeneratedMethodAccessor270.invoke(Unknown
>> Source) [:1.6.0_21]
>>>
>>> Does this relate to this post somehow:
>>>
>>> Project configuration or bug; Weld issue?
>>>
>>>
>>> Thanks
>>> Michael
>>>
>>>> 2011/1/4 Dan Allen <dan.j.allen(a)gmail.com
>>> Michael,
>>>
>>> To use MyFaces on JBoss AS 6, you need to provide a
>> hint as described here:
>>>
>>>
>>> Feel free to propagate that information.
>>>
>>> -Dan
>>>
>>>
>>>> On Mon, Jan 3, 2011 at 6:48 PM, Michael Schütz
<michaelschuetz83(a)gmail.com
>> wrote:
>>> This is interesting:
>>>
>>> As recommended, I did only keep myfaces-extcdi-*
>> jars.
>>>
>>> This resulted in:
>>> Error configuring application listener of class
>> org.apache.webbeans.servlet.WebBeansConfigurationListener:
>> java.lang.ClassNotFoundException:
>> org.apache.webbeans.servlet.WebBeansConfigurationListener
>>> Error configuring application listener of class
>> org.apache.myfaces.webapp.StartupServletContextListener:
>> java.lang.ClassNotFoundException:
>> org.apache.myfaces.webapp.StartupServletContextListener
>>>
>>> WebBeansConfigurationListener is contained in
>> openwebbeans-web-1.0.0.jar and StartupServletContextListener
>> in myfaces-impl-2.0.3.jar.
>>>
>>> So I did comment out Listener in web.xml:
>>> <!--
>>>> <listener
>>>
>>>
<listener-class>org.apache.webbeans.servlet.WebBeansConfigurationListener</listener-class
>>>> </listener
>>>
>>>> <listener
>>>
>>>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class
>>>> </listener
>>>> --
>>>
>>> After that server starts fine, using Mojarra 2.0.3.
>>> Applications works partially as expected:
>>> * JSF2 RequestScope does work as expected
>>> * JSF2 ViewScope does _not_ work: it seems not to be
>> initialized
>>> * CODI Conversation and CODI Window-Scope do work as
>> expected
>>> * CODI ViewAccessScoped does _not_ work as expected:
>> it has been initialized, but never expires
>>>
>>> Not commenting out
>>>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class
>> causes:
>>> class
>> org.apache.myfaces.webapp.StartupServletContextListener:
>> java.lang.ClassNotFoundException:
>> org.apache.myfaces.webapp.StartupServletContextListener
>>>
>>> This is quite strange, as this class is provided in
>> myfaces-impl-2.0.1.jar shipped with AS. Seems to be a
>> classloading issue - right?
>>>
>>> So, are this still project configuration troubles:
>> wrong Listener used etc? Or is it more likely to be a bug?
>>>
>>>
>>> Thanks a lot
>>> Michael
>>>
>>>> 2011/1/3 Mark Struberg <struberg(a)yahoo.de
>>>
>>> Hi Michael!
>>>
>>> What definitely needs to be removed:
>>>
>>> * geronimo-*_spec (all the specs are already included
>> in JBOSS)
>>> * jsr250-api
>>> * openwebbeans*
>>> * scannotation
>>> * myfaces-impl
>>> * myfaces-api
>>>
>>> you should also be able to remove all the commons
>> stuff...
>>>
>>>
>>> The only things you need are basically the
>> myfaces-extcdi-* jars.
>>>
>>
> LieGrue,
>>
> strub
>>>
>>>
>>>> --- On Mon, 1/3/11, Michael Schütz <michaelschuetz83(a)gmail.com
>> wrote:
>>>
>>>> From: Michael Schütz <michaelschuetz83(a)gmail.com
>>> Subject: Re: [weld-dev] CODI and JBoss AS 6 final:
>> ProjectStageActivationExtension didn't implement the
>> Extension interface
>>>> To: "Peter Muir" <pmuir(a)redhat.com
>>> Cc: "weld-dev(a)lists.jboss.org"
>>> <weld-dev(a)lists.jboss.org
>>> Date: Monday, January 3, 2011, 10:34 AM
>>>
>>> Pete, I already did that: I did remove geronimo-jcdi
>> and javassist.
>>>
>>> Current error:
>>> 11:19:22,486 ERROR
>>
[org.jboss.kernel.plugins.dependency.AbstractKernelController]
>> Error installing to Start:
>>
name=vfs:///C:/01-Development/Projekte/CODI/jboss-6.0.0.Final/server/default/deploy/myfaces-cdi-1.0.2-SNAPSHOT.war_WeldBoo
>>>
>>> n: WELD-001409 Ambiguous dependencies for type
>> [MessageContext] with qualifiers [@Default] at injection
>> point [[parameter 1] of [method] @Produces @Dependent @Jsf
>> @Named public
>> org.apache.myfaces.extensions.cdi.jsf.impl.message.Jsf
>>>
>>> ssageFactory>, Instance<ELProvider>,
>> Instance<ArgumentFilter>)]. Possible dependencies
>> [[Producer Method [MessageContext] with qualifiers [@Any
>> @Default] declared as [[method] @Produces @Dependent @Jsf
>> @Named public org.apache.myfa
>>>
>>> eateContext(MessageContext,
>> Instance<MessageFactory>, Instance<ELProvider>,
>> Instance<ArgumentFilter>)], Managed Bean [class
>>
org.apache.myfaces.extensions.cdi.message.impl.DefaultMessageContext]
>> with qualifiers [@Any @Default]]]
>>>
>>> at
>>
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
>> [:6.0.0.Final]
>>>
>>>
>>> Please find screenshot attached with current
>> WEB-INF/lib directory.
>>> Are you saying removing everything but
>> myfaces-extcdi-*.jar is expected to work?
>>>
>>>
>>>
>>> Thanks
>>> Michael
>>>
>>>
>>>> 2011/1/3 Peter Muir <pmuir(a)redhat.com
>>>
>>> Do what I said and remove javassist.
>>>
>>> --Pete Muirhttp://in.relation.to/Bloggers/Pete
>>>
>>>> On 2 Jan 2011, at 22:34, Michael Schütz
<michaelschuetz83(a)gmail.com
>> wrote:
>>>
>>>
>>> Thanks Dan and Pete for your replys.
>>>
>>> I did remove geronimo-jcdi and got:
>>> 23:14:08,172 ERROR
>>
[org.jboss.kernel.plugins.dependency.AbstractKernelController]
>> Error installing to Start:
>>
name=vfs:///C:/01-Development/Projekte/CODI/jboss-6.0.0.Final/server/default/deploy/myfaces-cdi-1.0.2-SNAPSHOT.war_WeldBootstrapBean
>> state=Create: java.lang.ClassCastException: org.jboss.weld
>>>
>>>
>>>
>>
.security.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$C:$01-Development$Projekte$CODI$jboss-6$0$0$Final$server$default$deploy$myfaces-cdi-1$0$2-SNAPSHOT$war"-Built-in-Principal_$$_WeldProxy
>> cannot be cast to javassist.util.proxy.ProxyObject
>>>
>>>
>>> at
>>
org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:248)
>> [:6.0.0.Final]
>>> at
>>
org.jboss.weld.bean.builtin.ee.AbstractEEBean.<init>(AbstractEEBean.java:46)
>> [:6.0.0.Final]
>>>
>>> So, I removed javassist in the next step and i got:
>>>
>>>
>>> 23:17:31,816 ERROR
>>
[org.jboss.kernel.plugins.dependency.AbstractKernelController]
>> Error installing to Start:
>>
name=vfs:///C:/01-Development/Projekte/CODI/jboss-6.0.0.Final/server/default/deploy/myfaces-cdi-1.0.2-SNAPSHOT.war_WeldBootstrapBean
>> state=Create: org.jboss.weld.exceptions.DeploymentExceptio
>>>
>>>
>>> n: WELD-001409 Ambiguous dependencies for type
>> [MessageContext] with qualifiers [@Default] at injection
>> point [[parameter 1] of [method] @Produces @Dependent @Jsf
>> @Named public
>>
org.apache.myfaces.extensions.cdi.jsf.impl.message.JsfAwareMessageContextProducer.createContext(MessageContext,
>> Instance<Me
>>>
>>>
>>> ssageFactory>, Instance<ELProvider>,
>> Instance<ArgumentFilter>)]. Possible dependencies
>> [[Producer Method [MessageContext] with qualifiers [@Any
>> @Default] declared as [[method] @Produces @Dependent @Jsf
>> @Named public
>>
org.apache.myfaces.extensions.cdi.jsf.impl.message.JsfAwareMessageContextProducer.cr
>>>
>>>
>>> eateContext(MessageContext,
>> Instance<MessageFactory>, Instance<ELProvider>,
>> Instance<ArgumentFilter>)], Managed Bean [class
>>
org.apache.myfaces.extensions.cdi.message.impl.DefaultMessageContext]
>> with qualifiers [@Any @Default]]]
>>>
>>>
>>> at
>>
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
>> [:6.0.0.Final]
>>>
>>> Seams like
>> myfaces-extcdi-message-module-impl-0.9.1.jar causes the
>> troubles. Any thoughts what needs to be done?
>>>
>>>
>>>
>>>
>>> Thanks
>>> Michael
>>>
>>>
>>>> 2011/1/1 Pete Muir <pmuir(a)redhat.com
>>>
>>>
>>>
>>>
>>> On 31 Dec 2010, at 17:39, Dan Allen wrote:
>>>
>>>
>>>
>>>> It's more than likely geronimo-jcdi jar
that's
>> causing the problem. Weld looks to see if Extension class
>> equals Extension class and since there are two independent
>> instances on the classpath, it breaks the comparison. 9/10
>> this is the source of a class not found problem.
>>>
>>>
>>>
>>>>
>>>
>>>> Java EE APIs should never be provided by an
>> archive when deploying to a compliant app server. If you
>> were moving from Tomcat to JBoss AS it's important to
keep
>> that in mind.
>>>
>>>>
>>>
>>>> I doubt the apache-commons libraries would
>> present a problem, so you can likely leave those.
>>>
>>>
>>>
>>> They (used to at least) cause problems with
>> RichFaces.
>>>
>>>
>>>
>>> In general until AS7 I would recommend not duplicating
>> libs in your war that in the AS, it will cause you a lot
>> less problems in the long run :-D
>>>
>>>
>>>
>>>
>>>
>>>>
>>>
>
>>> -Dan
>>>
>>>>
>>>
>>>> On Fri, Dec 31, 2010 at 11:00 AM, Pete Muir
>>> <pmuir(a)redhat.com
>> wrote:
>>>
>>>
>>>> Aha, as I thought you are bundling in the war all
>> sorts of stuff which AS6 provides (and doesn't support
>> overriding simply by placing in the war).
>>>
>>>>
>>>
>>>> Try removing at least:
>>>
>>>>
>>>
>>>> * geronimo*
>>>
>>>> * javassist
>>>
>
>>> * jsr250-api
>>>
>
>>> * myfaces-api
>>>
>
>>> * myfaces-impl
>>>
>
>>> * openwebbeans*
>>>
>
>>> * scannotation
>>>
>>>>
>>>
>>>> you may also need to remove commons-XXX which
>> duplicate that in the AS
>>>
>>>>
>>>
>>>> HTH
>>>
>>>>
>>>
>>>>
>>>
>>>> On 31 Dec 2010, at 15:42, Michael Schütz wrote:
>>>
>>>>
>>>
>>>>> Please see attached screenshot.
>>>
>>>>>
>>>
>>
>>> Thanks
>>>
>>
>>> Michael
>>>
>>>>>
>>>
>>>>>> 2010/12/31 Pete Muir <pmuir(a)redhat.com
>>>
>>>
>>>>> No idea.
>>>
>>>>>
>>>
>>>>> What jars are placed in WEB-INF/lib?
>>>
>>>>>
>>>
>>>>> On 31 Dec 2010, at 15:19, Michael Schütz
>> wrote:
>>>
>>>>>
>>>
>>>>>> Thanks for reply, Pete.
>>>
>>>>>>
>>>
>>>>>> Already spoke to CODI team. They do
>> implement Extension. Doesn't look like CODI bug for them.
>>>
>>>>>>
>>>
>>>>>> So, does this CDI POM config look
>> strange:
>>>
>>>>>>> <!-- MyFaces CODI --
>>>
>>>>>>
>>> <dependency
>>>
>>>>>>
>>> <groupId>org.apache.myfaces.extensions.cdi.core</groupId
>>>
>>>>>>
>>> <artifactId>myfaces-extcdi-core-api</artifactId
>>>
>>>>>>
>>> <version>${myfaces_codi.version}</version
>>>
>>>>>>
>>> <scope>compile</scope
>>>
>>>>>>
>>> </dependency
>>>
>>>>>>
>>>
>>>>>>
>>> <dependency
>>>
>>>>>>
>>> <groupId>org.apache.myfaces.extensions.cdi.core</groupId
>>>
>>>>>>
>>> <artifactId>myfaces-extcdi-core-impl</artifactId
>>>
>>>>>>
>>> <version>${myfaces_codi.version}</version
>>>
>>>>>>
>>> <scope>runtime</scope
>>>
>>>>>>
>>> </dependency
>>>
>>>>>>
>>> <dependency
>>>
>>>>>>
>>> <groupId>org.apache.myfaces.extensions.cdi.modules</groupId
>>>
>>>>>>
>>> <artifactId>myfaces-extcdi-jsf20-module-api</artifactId
>>>
>>>>>>
>>> <version>${myfaces_codi.version}</version
>>>
>>>>>>
>>> <scope>compile</scope
>>>
>>>>>>
>>> </dependency
>>>
>>>>>>
>>>
>>>>>>
>>> <dependency
>>>
>>>>>>
>>> <groupId>org.apache.myfaces.extensions.cdi.modules</groupId
>>>
>>>>>>
>>> <artifactId>myfaces-extcdi-jsf20-module-impl</artifactId
>>>
>>>>>>
>>> <version>${myfaces_codi.version}</version
>>>
>>>>>>
>>> <scope>runtime</scope
>>>
>>>>>>
>>> </dependency
>>>
>>>>>>
>>>
>>>>>>
>>>
>>>>>> Cheers
>>>
>>>
>>> Michael
>>>
>>>>>>
>>>
>>>>>>> 2010/12/31 Pete Muir <pmuir(a)redhat.com
>>>
>>>
>>>>>>
>>>
>>>>>> On 31 Dec 2010, at 14:37, Michael
>> Schütz wrote:
>>>
>>>>>>
>>>
>>>>>>> Hi to all,
>>>
>>>>>>>
>>>
>>>>>>> would like to run CODI/MyFaces
>> example within JBoss AS 6 final.
>>>
>>>>>>> Getting:
>>>
>>>>>>> WeldBootstrapBean state=Create:
>> java.lang.RuntimeException: Service class or
>>>
>>>>>>>
>>
g.apache.myfaces.extensions.cdi.core.impl.projectstage.ProjectStageActivationExtension
>> didn't implement the Extension interface
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>>
org.jboss.weld.util.ServiceLoader.loadClass(ServiceLoader.java:261)
>> [:6.0.0.Final]
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>>
org.jboss.weld.util.ServiceLoader.loadService(ServiceLoader.java:233)
>> [:6.0.0.Final]
>>>
>>>>>>>
>> at
>>
org.jboss.weld.util.ServiceLoader.loadServiceFile(ServiceLoader.java:194)
>> [:6.0.0.Final]
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>>
org.jboss.weld.util.ServiceLoader.reload(ServiceLoader.java:157)
>> [:6.0.0.Final]
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>>
org.jboss.weld.util.ServiceLoader.iterator(ServiceLoader.java:346)
>> [:6.0.0.Final]
>>>
>>>>>>>
>> at
>>
org.jboss.weld.bootstrap.ExtensionBeanDeployer.addExtensions(ExtensionBeanDeployer.java:93)
>> [:6.0.0.Final]
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>>
org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:333)
>> [:6.0.0.Final]
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>>
org.jboss.weld.integration.deployer.env.helpers.BootstrapBean.boot(BootstrapBean.java:92)
>> [:6.0.0.Final]
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [:1.6.0_21]
>>>
>>>>>>>
>>>
>>>>>>>
>> at
>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> [:1.6.0_21]
>>>
>>>>>>>
>> at
>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> [:1.6.0_21]
>>>
>>>>>>>
>>>
>>>>>>> Everything runs fine within
>> Tomcat7.
>>>
>>>>>>>
>>>
>>>>>>> Already posted question at Weld
>>>
>>>
>>>
>>>>>>>
>>>
>>>>>>> What I would like to know:
>>>
>>>>>>> 1) Is it not supposed to run?
>>>
>>>>>>
>>>
>>>>>> I would guess it is, but you should
>> check with the CODI team.
>>>
>>>>>>
>>>
>>>>>>> 2) Is it project configuration
>> issue?
>>>
>>>>>>
>>>
>>>>>> Possibly, it looks like it does really
>> impl Extension so check you aren't bundling the CDI API
in
>> your war accidentally.
>>>
>>>>>>
>>>
>>>>>>> 3) Is it a bug? (JBoss, Weld? JIRA
>> issue already filed)
>>>
>>>>>>
>>>
>>>>>> Probably not in JBoss or Weld.
>>>
>>>>>>
>>>
>>>>>>>
>>>
>>>>>>>
>>>
>>>>>>> thanks a lot
>>>
>>>>
>>> Michael
>>>
>>>>>>>
>> _______________________________________________
>>>
>>>>>>> weld-dev mailing list
>>>
>>>>>>> weld-dev(a)lists.jboss.org
>>>
>>>
>>>
>>>
>>>>>>
>>>
>>>>>>
>>>
>>>>>>
>> _______________________________________________
>>>
>>>>>> weld-dev mailing list
>>>
>>>>>> weld-dev(a)lists.jboss.org
>>>
>>>
>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>> <codi_webinf_lib.png
>>>
>>>>
>>>
>>>>
>>>
>>
>>
_______________________________________________
>>>
>>>> weld-dev mailing list
>>>
>>>> weld-dev(a)lists.jboss.org
>>>
>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>> --
>>>
>>>> Dan Allen
>>>
>>>> Principal Software Engineer, Red Hat | Author of
>> Seam in Action
>>>
>>>> Registered Linux User #231597
>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
_______________________________________________
>>>
>>>> weld-dev mailing list
>>>
>>>> weld-dev(a)lists.jboss.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>> _______________________________________________
>>>
>>> weld-dev mailing list
>>>
>>> weld-dev(a)lists.jboss.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Inline Attachment Follows-----
>>>
>
>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev(a)lists.jboss.org
>>>
>>>
>>>
>>>
>>>
>
>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev(a)lists.jboss.org
>>>
>>>
>>>
>>> --
>>> Dan Allen
>>> Principal Software Engineer, Red Hat | Author of Seam
>> in Action
>>> Registered Linux User #231597
>>>
>>>
>>
>>
>
>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
-----Inline Attachment Follows-----
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev