Adding Classes at Run-time
by Jason Lee
I have an odd question. I have a situation where I'm manually opening a
JAR and adding its classes to the ClassLoader. What I'd like to be able
to do is have Weld scan these classes for any relevant annotations and
take the proper actions, just as if the JARs were in the classpath when
the application started. I've been staring at the JavaDocs (build
locally, btw, as I can't find them on the web :| ) but I don't see any
way to request that Weld inspect a given class. Is it there and I'm
missing it? Am I going to have cobble together that functionality? Am
I asking for something that can't be done (right now)? Any nudges in
the right direction would be much appreciated. :)
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
12 years, 8 months
Re: [weld-dev] clarification regarding extensions in non-bean archives
by Pete Muir
Hi Dan
JSR-299 is no longer in existence, as the spec is now complete. We will be filing a new JSR for CDI 1.1. If you want to discuss this, mail cdi-dev(a)lists.jboss.org, or file an issue in the CDI issue tracker on jboss.org.
Specifically regarding your points,
1) this was recognised as a bug in GlassFish, and has been fixed accordingly. I would suggest raising a CDI issue and pointing out that there has been confusion about this, and it would be helpful if the spec explicitly stated that the it is referring to the JAR file spec, and that service providers do not need to be placed in bean archives.
2) this also sounds like a GlassFish bug, so I don't think mailing the EG is appropriate, instead you should raise an GLASSFISH issue. This is well defined at the moment, and is simply a hard area to get right, hence why we are finding bugs. Short of actually enforcing an impl on people there is little I think we can do to improve this.
Pete
On 17 Jan 2011, at 18:04, Dan Allen wrote:
> I attempted to send this message to jsr299-comments(a)jcp.org, but it was rejected. Can you forward it on if necessary?
>
> -Dan
>
> On Mon, Jan 17, 2011 at 13:00, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> JSR-299 EG,
>
> For a while now, the Seam 3 project has been working to solve a portability issue that prevents modules (i.e., extensions) from running on GlassFish (3.0 and 3.1) [1]. After much research, we've determined that this isn't a problem that we have much control over. It's clear that there is an inconsistency in the way the JSR-299 specification is being interpreted with regard to extension loading.
>
> The question is this. Does an extension have to be in an bean archive in order to be loaded?
>
> Section 11.5 states:
>
> "An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services."
>
> If one assumes that "service provider" refers to the term defined in the jar specification [2], then one would conclude that an extension does not have to be in a bean archive to be recognized (these are orthogonal concerns). However, the Java EE 6 reference implementation (GlassFish) does not honor this interpretation prior to version 3.1-b37, as indicated by [3].
>
> Even with the recent fix to the reference implementation, there is a secondary interpretation problem:
>
> Can an extension register a bean programmatically for a class that resides in another non-bean archive?
>
> This question requires a short example.
>
> Assume one archive, a.jar, has the following contents:
>
> org/opentck/javaee/cdi/spi/beforebeandiscovery/BeanClassToRegister.class
>
> A second archive, b.jar, has the following contents:
>
> org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherBeanClassToRegister.class
> org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherManualBeanRegistrationExtension.class
> org/opentck/javaee/cdi/spi/beforebeandiscovery/ManualBeanRegistrationExtension.class
> META-INF/services/javax.enterprise.inject.spi.Extension
>
> AnotherBeanClassToRegister has an injection point of type BeanClassToRegister:
>
> public class AnotherBeanClassToRegister {
> @Inject
> private BeanClassToRegister collaborator;
> }
>
> BeanClassToRegister and AnotherBeanClassToRegister are added as beans programmatically in respective extensions listed in the service provider descriptor:
>
> public class ManualBeanRegistrationExtension implements Extension {
> public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) {
> event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class));
> }
> }
>
> public class AnotherManualBeanRegistrationExtension implements Extension {
> public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) {
> event.addAnnotatedType(bm.createAnnotatedType(AnotherBeanClassToRegister.class));
> }
> }
>
> The two libraries, a.jar and b.jar are bundled in a web archive, test.war
>
> WEB-INF/lib/a.jar
> WEB-INF/lib/b.jar
> WEB-INF/beans.xml
>
> Deploying this archive to the reference implementation fails with an error message that the injection point from above cannot be satisfied. Clearly there is a visibility problem across bean archives in this case.
>
> Adding META-INF/beans.xml to a.jar and removing the ManualBeanRegistrationExtension from b.jar resolves the issue in the reference implementation.
>
> The fact that there is so much discussion around this issue has led me to the conclusion that it needs to be addressed at the specification level.
>
> These scenarios have been prepared using Open TCK tests (based on Arquillian). [4]
>
> -Dan
>
> p.s. Thanks to Jason Porter for helping track down this issue and drafting the initial the Open TCK tests.
>
> [1] https://issues.jboss.org/browse/SOLDER-47
> [2] http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Se...
> [3] http://java.net/jira/browse/GLASSFISH-14808
> [4] https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent...
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
>
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
13 years, 12 months
clarification regarding extensions in non-bean archives
by Dan Allen
JSR-299 EG,
For a while now, the Seam 3 project has been working to solve a portability
issue that prevents modules (i.e., extensions) from running on GlassFish
(3.0 and 3.1) [1]. After much research, we've determined that this isn't a
problem that we have much control over. It's clear that there is an
inconsistency in the way the JSR-299 specification is being interpreted with
regard to extension loading.
The question is this. Does an extension have to be in an bean archive in
order to be loaded?
Section 11.5 states:
"An extension is a service provider of the
service javax.enterprise.inject.spi.Extension declared in
META-INF/services."
If one assumes that "service provider" refers to the term defined in the jar
specification [2], then one would conclude that an extension does not have
to be in a bean archive to be recognized (these are orthogonal concerns).
However, the Java EE 6 reference implementation (GlassFish) does not honor
this interpretation prior to version 3.1-b37, as indicated by [3].
Even with the recent fix to the reference implementation, there is a
secondary interpretation problem:
Can an extension register a bean programmatically for a class that resides
in another non-bean archive?
This question requires a short example.
Assume one archive, a.jar, has the following contents:
org/opentck/javaee/cdi/spi/beforebeandiscovery/BeanClassToRegister.class
A second archive, b.jar, has the following contents:
org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherBeanClassToRegister.class
org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherManualBeanRegistrationExtension.class
org/opentck/javaee/cdi/spi/beforebeandiscovery/ManualBeanRegistrationExtension.class
META-INF/services/javax.enterprise.inject.spi.Extension
AnotherBeanClassToRegister has an injection point of type
BeanClassToRegister:
public class AnotherBeanClassToRegister {
@Inject
private BeanClassToRegister collaborator;
}
BeanClassToRegister and AnotherBeanClassToRegister are added as beans
programmatically in respective extensions listed in the service provider
descriptor:
public class ManualBeanRegistrationExtension implements Extension {
public void registerBeans(@Observes BeforeBeanDiscovery event,
BeanManager bm) {
event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class));
}
}
public class AnotherManualBeanRegistrationExtension implements Extension {
public void registerBeans(@Observes BeforeBeanDiscovery event,
BeanManager bm) {
event.addAnnotatedType(bm.createAnnotatedType(AnotherBeanClassToRegister.class));
}
}
The two libraries, a.jar and b.jar are bundled in a web archive, test.war
WEB-INF/lib/a.jar
WEB-INF/lib/b.jar
WEB-INF/beans.xml
Deploying this archive to the reference implementation fails with an error
message that the injection point from above cannot be satisfied. Clearly
there is a visibility problem across bean archives in this case.
Adding META-INF/beans.xml to a.jar and removing the
ManualBeanRegistrationExtension from b.jar resolves the issue in the
reference implementation.
The fact that there is so much discussion around this issue has led me to
the conclusion that it needs to be addressed at the specification level.
These scenarios have been prepared using Open TCK tests (based on
Arquillian). [4]
-Dan
p.s. Thanks to Jason Porter for helping track down this issue and drafting
the initial the Open TCK tests.
[1] https://issues.jboss.org/browse/SOLDER-47
[2]
http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Se...
[3] http://java.net/jira/browse/GLASSFISH-14808
[4]
https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent...
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
14 years
Re: [weld-dev] clarification of AfterDeploymentValidation
by Mark Struberg
Hi Dan!
The trick with the servlet is neat ;)
> If you want to know when CDI is done starting up and when application-
> scoped beans are available, that's the AfterDeploymentValidation event.
Oki, this might work in Weld and in OWB, but does the Spec really forces this for any other container too? In other words: can a developer of an Extension _really_ count on it?
I also believe it is ambiguous, so should I file a CDI spec clarification issue?
txs and LieGrue,
strub
--- On Fri, 1/14/11, Dan Allen <dan.j.allen(a)gmail.com> wrote:
From: Dan Allen <dan.j.allen(a)gmail.com>
Subject: Re: [weld-dev] clarification of AfterDeploymentValidation
To: "Mark Struberg" <struberg(a)yahoo.de>
Cc: weld-dev(a)lists.jboss.org
Date: Friday, January 14, 2011, 9:18 PM
I've actually had this exact same dilemma in Seam. I want to know when everything is ready. So it really depends on how you define after (or started)
If you want to know when CDI is done starting up and when application-scoped beans are available, that's the AfterDeploymentValidation event. However, I also believe that this sounds too ambiguous. You have to know that deployment validation is the last phase to know that the CDI beans are ready.
Then there is the question of "when is the module deployed?" (module meaning web archive, for instance). It amazes me that there is no definitive event in Java EE for this. I've hacked around this in Seam by registering a Servlet with a very low priority and fire an event in the init() method.
https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/...
I consider that a design requirement for EE 7.
-Dan
On Fri, Jan 14, 2011 at 16:09, Mark Struberg <struberg(a)yahoo.de> wrote:
Hi!
I need to trigger a task once the whole CDI container got started, and I'm not sure if the AfterDeploymentValidation can be used for this. Basically what I like to do is to warm-up & initialise CDI based services when the server has been started.
The AfterDeploymentValidation system event is defined as:
"The container must fire a third event after it has validated that there are no deployment problems and before creating contexts or processing requests."
Thus especially the part "before creating contexts" is a bit unclear. Does this mean that no @ApplicationScoped, etc beans are available yet in this phase?
If so, do we like to introduce a new AfterServerStart event?
LieGrue,
strub
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Dan AllenPrincipal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
14 years
ODP: Re: Stateless scope in Weld?
by Marcin Mieszek
c
Sent from my HTC
-----Wiadomosc oryginalna-----
Od: Clint Popetz <cpopetz(a)gmail.com>
Wyslano: 14 stycznia 2011 16:24
Do: Adam Warski <adam(a)warski.org>
DW: weld-dev(a)lists.jboss.org
Temat: Re: [weld-dev] Stateless scope in Weld?
On Fri, Jan 14, 2011 at 10:13 AM, Adam Warski <adam(a)warski.org> wrote:
Hello,
have you considered adding a stateless scope to Weld?
I've definitely felt the paint of not having this, for all the reasons stated.
-Clint
Here's my use-case:
I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either
(a) be normal-scoped (proxyable)
(b) implement Serializable and leave the bean dependent-scoped
If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless.
So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state?
Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy informat
[Cala oryginalna wiadomosc nie zostala zalaczona]
14 years
Stateless scope in Weld?
by Adam Warski
Hello,
have you considered adding a stateless scope to Weld?
Here's my use-case:
I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either
(a) be normal-scoped (proxyable)
(b) implement Serializable and leave the bean dependent-scoped
If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless.
So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state?
Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB).
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
14 years
clarification of AfterDeploymentValidation
by Mark Struberg
Hi!
I need to trigger a task once the whole CDI container got started, and I'm not sure if the AfterDeploymentValidation can be used for this. Basically what I like to do is to warm-up & initialise CDI based services when the server has been started.
The AfterDeploymentValidation system event is defined as:
"The container must fire a third event after it has validated that there are no deployment problems and before creating contexts or processing requests."
Thus especially the part "before creating contexts" is a bit unclear. Does this mean that no @ApplicationScoped, etc beans are available yet in this phase?
If so, do we like to introduce a new AfterServerStart event?
LieGrue,
strub
14 years
Looking for volunteers
by Pete Muir
Hi all
I'm currently trawling the weld-dev archive to find issues and ideas for CDI 1.1 (the next release of the CDI specification) that have been raised but not filed in https://issues.jboss.org/browse/CDI.
Anyone want to volunteer to do the same for the forums and in.relation.to (and any other blogs they can find?). Mail me if you do and we can make sure that people don't overlap.
Thanks,
Pete
14 years
CDI TCK: InvocationContextTest:testGetTarget
by Scott Ferguson
This test has a implementation-dependency on how interception is
implemented (requires proxy implementation), but the proxy
implementation is not mandated by the spec (and the EJB spec has always
allowed both implementation methods.)
The test calls SimpleBean.getId(), which is intercepted by Interceptor1.
Interceptor1's aroundInvoke calls target.getId(), which is a circular
reference for extension and only works for proxy-based interception:
class SimpleBean {
@Interceptors(Interceptor1.class)
public int getId()
{
return id;
}
...
}
class Interceptor1 {
@AroundInvoke
public Object aroundInvoke(InvocationContext ctx) throws Exception
{
SimpleBean target = (SimpleBean) ctx.getTarget();
int id1 = target.getId();
...
}
}
The only change needed to the test is to create a SimpleBean.getBareId()
which is not an intercepted method.
(Or, if the spec is re-interpreted to require a proxy implementation,
there should be an explicit test for it, not an implicit dependency like
this test.)
-- Scott
14 years
Re: [weld-dev] CODI and JBoss AS 6 final: ProjectStageActivationExtension didn't implement the Extension interface
by Mark Struberg
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:
>>>> http://seamframework.org/Community/CannotSerializeSessionAttributeOrgapac...
>>>>
>>>> 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:
>>>>
>>>> http://community.jboss.org/wiki/JSFonJBossAS6
>>>>
>>>> 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
>>> forum without having much success: http://seamframework.org/Community/CODIAndJBossAS6FinalProjectStageActiva...
>>>>
>>>>
>>>>
>>>>>>>>
>>>>
>>>>>>>> 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
>>>>
>>>>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>>
>>>>>>>
>>>>
>>>>>>>
>>>>
>>>>>>>
>>> _______________________________________________
>>>>
>>>>>>> weld-dev mailing list
>>>>
>>>>>>> weld-dev(a)lists.jboss.org
>>>>
>>>>
>>>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> <codi_webinf_lib.png>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>> _______________________________________________
>>>>
>>>>> weld-dev mailing list
>>>>
>>>>> weld-dev(a)lists.jboss.org
>>>>
>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>> --
>>>>
>>>>> Dan Allen
>>>>
>>>>> Principal Software Engineer, Red Hat | Author of
>>> Seam in Action
>>>>
>>>>> Registered Linux User #231597
>>>>
>>>>>
>>>>
>>>>> http://mojavelinux.com
>>>>
>>>>> http://mojavelinux.com/seaminaction
>>>>
>>>>
>>>>> http://www.google.com/profiles/dan.j.allen
>>>>
>>>>
>>>>> _______________________________________________
>>>>
>>>>> weld-dev mailing list
>>>>
>>>>> weld-dev(a)lists.jboss.org
>>>>
>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> weld-dev mailing list
>>>> weld-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Dan Allen
>>>> Principal Software Engineer, Red Hat | Author of Seam
>>> in Action
>>>> Registered Linux User #231597
>>>>
>>>> http://mojavelinux.com
>>>> http://mojavelinux.com/seaminaction
>>>> http://www.google.com/profiles/dan.j.allen
>>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
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
14 years
