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
13 years, 9 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
15 years, 1 month
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
15 years, 1 month
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
15 years, 1 month
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]
15 years, 1 month
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
15 years, 1 month
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
15 years, 1 month
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
15 years, 2 months
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
15 years, 2 months
