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, 11 months
Question regarding EJB3-style interceptors and their usage as managed beans
by Marius Bogoevici
Hi,
This is a question for the EG regarding a conflict that arises from the
current ability to use an EJB3-style interceptor as a managed bean.
There seems to be a slight gap between the CDI spec and the general Java
EE notion of the interceptor, in the following respect: an EJB
interceptor (one that's not annotated with @Interceptor), may be, in
theory, used as a managed bean. Unfortunately, this leads to a conflict
with respect to the lifecycle interception methods.
So for example we had something like:
public class SomeClass {
@AroundInvoke
public Object interceptSomething(InvocationContext context) throws
Exception { ... }
}
one may decide to use it either as
@Inject SomeClass someClass;
or @Interceptors(SomeClass.class);
This cannot be prevented, as there is no formal way in which one can
differentiate between a managed bean with an @AroundInvoke
self-intercepting method and an EJB3-interceptor that does only business
method call interception (it is possible to do this heuristically, but
that opens the door to various interpretations). As ambiguous as it is,
that wouldn't be so bad, until one adds a @PostConstruct method too (for
example). As this has been previously discussed here:
http://lists.jboss.org/pipermail/weld-dev/2009-December/001913.html,
the intent is to stay consistent with the EJB spec and not to have two
different @PostConstruct handlers for the same class. Staying
consistent requires the lifecycle interception methods of SomeClass to
have an InvocationContext parameter (in order to be applicable on other
classes). If SomeClass was instantiated independently, as a managed
bean, its lifecycle invocation method would need to be no-arg, though.
Now, such a dual use use-case (using a class as both an interceptor and
a managed bean) is by and large, absurd - but it is not prohibited by
the current spec. In fact, in Weld, ManagedBean and NewManagedBean
instances are created for such classes (because there is nothing to
forbid it, and in certain cases, you can't be sure whether the bean is a
managed bean or an interceptor).
In summary: the current specification allows to use EJB3-style
interceptors as managed beans, but if they have lifecycle interception
methods, they cannot be instantiated in a way that is consistent with
the spec, because their lifecycle interceptor methods will expect an
argument that the interceptor specification says it should not be
provided in this case.
So, I think this needs to be somehow clarified in a future version of
the spec, either by stating explicitly that EJB3-style interceptors with
lifecycle interception methods are not managed beans, *or* at least by
saying that the use of EJB3-style interceptors as managed beans is
non-portable when they also define lifecycle methods.
WDYT?
Marius
16 years
Question for EG, was: Retrieving the Bean object for an interceptor
by Marius Bogoevici
On 10-04-22 1:44 AM, Gavin King wrote:
> On Thu, Apr 22, 2010 at 12:38 AM, Marius Bogoevici
> <marius.bogoevici(a)gmail.com> wrote:
>
>> However, once we move to subclassing (1.0.2), the call will
>> return the single instrumented instance, which is essentially a subclass
>> of the bean class. It would be necessary to retrieve the original bean
>> class from that. But I can see a few options for doing that, one being a
>> mixin interface with methods that can retrieve information about the
>> original type of the target object.
>>
> Hrm. That's a problem I had not thought of with the subclassing
> approach. The assumption in EJB is that getTarget() returns an
> unintercepted/undecorated reference. Urm.
>
>
Gavin,
This is not the same issue, but still related to what is
decorated/intercepted in CDI. Is it possible to clarify the following
from the EG's point of view:
Consider the following bean:
class SomeBean
{
@Binding
void method1() {}
@Binding
void method2()
{
method1();
}
}
The question is whether upon invoking method2(), the subsequent
invocation to method1() must be intercepted as well. While this hasn't
been possible while using proxies, the question becomes actual in the
context of subclassing. It has also been raised by users recently.
The specification says that only business method invocations on
contextual references must be intercepted, so the main question here is
whether we should treat *this* as a contextual reference. While I'm not
sold entirely either way, I can see a lot more reasons why
this.method1() would not be intercepted upon invoking method2(), the
idea being that interceptors/decorators are container-level entities
which are applied on the "contextual reference" and not on the POJO bean
itself, which would also be consistent with the way things are done in
EJB. Also, if we allow interception in this case, then the invocation to
method1() would also need to be decorated, which IMO can lead to
unexpected side-effects.
Pete and I have discussed this, and since the current subclassing
approach opens the door to an interpretation where method invocations on
"this" are also decorated and intercepted, we decided that the best
course of action is to address the EG for clarifications.
Implementation-wise, it can be done either way.
Thanks,
Marius
16 years
Re: [weld-dev] Question regarding EJB3-style interceptors and their usage as managed beans
by George Gastaldi
That´s a good question. I think that there may be more ambiguities,
but it´s something that cannot be avoided.
I guess this is where the implementation comes in (For example, an
annotation may be created in Weld to avoid that behaviour), but then,
it may still unsolve the problem.
I wonder what the CDI spec guys has to say about it.
> 2010/4/29 Marius Bogoevici <marius.bogoevici(a)gmail.com>:
>> Hi,
>>
>> This is a question for the EG regarding a conflict that arises from the
>> current ability to use an EJB3-style interceptor as a managed bean.
>>
>> There seems to be a slight gap between the CDI spec and the general Java
>> EE notion of the interceptor, in the following respect: an EJB
>> interceptor (one that's not annotated with @Interceptor), may be, in
>> theory, used as a managed bean. Unfortunately, this leads to a conflict
>> with respect to the lifecycle interception methods.
>>
>> So for example we had something like:
>>
>> public class SomeClass {
>>
>> @AroundInvoke
>> public Object interceptSomething(InvocationContext context) throws
>> Exception { ... }
>>
>> }
>>
>> one may decide to use it either as
>>
>> @Inject SomeClass someClass;
>>
>> or @Interceptors(SomeClass.class);
>>
>> This cannot be prevented, as there is no formal way in which one can
>> differentiate between a managed bean with an @AroundInvoke
>> self-intercepting method and an EJB3-interceptor that does only business
>> method call interception (it is possible to do this heuristically, but
>> that opens the door to various interpretations). As ambiguous as it is,
>> that wouldn't be so bad, until one adds a @PostConstruct method too (for
>> example). As this has been previously discussed here:
>>
>> http://lists.jboss.org/pipermail/weld-dev/2009-December/001913.html,
>>
>> the intent is to stay consistent with the EJB spec and not to have two
>> different @PostConstruct handlers for the same class. Staying
>> consistent requires the lifecycle interception methods of SomeClass to
>> have an InvocationContext parameter (in order to be applicable on other
>> classes). If SomeClass was instantiated independently, as a managed
>> bean, its lifecycle invocation method would need to be no-arg, though.
>>
>> Now, such a dual use use-case (using a class as both an interceptor and
>> a managed bean) is by and large, absurd - but it is not prohibited by
>> the current spec. In fact, in Weld, ManagedBean and NewManagedBean
>> instances are created for such classes (because there is nothing to
>> forbid it, and in certain cases, you can't be sure whether the bean is a
>> managed bean or an interceptor).
>>
>> In summary: the current specification allows to use EJB3-style
>> interceptors as managed beans, but if they have lifecycle interception
>> methods, they cannot be instantiated in a way that is consistent with
>> the spec, because their lifecycle interceptor methods will expect an
>> argument that the interceptor specification says it should not be
>> provided in this case.
>>
>> So, I think this needs to be somehow clarified in a future version of
>> the spec, either by stating explicitly that EJB3-style interceptors with
>> lifecycle interception methods are not managed beans, *or* at least by
>> saying that the use of EJB3-style interceptors as managed beans is
>> non-portable when they also define lifecycle methods.
>>
>> WDYT?
>>
>> Marius
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
16 years
Fwd: Weld doesn not support using JSF in an non-servlet environment
by Roger Kitain
Forwarding to weld dev list.
-------- Original Message --------
Subject: Weld doesn not support using JSF in an non-servlet environment
Date: Thu, 29 Apr 2010 11:03:15 -0400
From: Neil Griffin <neil.griffin(a)portletfaces.org>
To: roger.kitain(a)oracle.com
Hi Roger,
I have some guys trying to use my PortletFaces Bridge for JSF 2.0 + Portlet 2.0 in Glassfish V3, but Weld is causing an issue.
From this link:
http://www.portletfaces.org/community/forums/-/message_boards/message/430...
Here is a simple stacktrace:
Caused by: java.lang.IllegalStateException: Weld doesn not support using JSF in an non-servlet environment
at org.jboss.weld.jsf.JsfHelper.getModuleBeanManager(JsfHelper.java:119)
at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener
I realize that Portlet 2.0 is not part of "Java EE 6" but I would think Oracle (GlassFish& CDI) and JBoss (Weld) would want to support Portlet 2.0? Do you know if this is just a temporary thing in Weld? Maybe I should ask Dan Allen about it?
Thank you for your time. Hope all is well with you,
Neil
16 years
WELDSE-1
by George Gastaldi
Hello,
I am willing to contribute to Weld by starting with issue
https://jira.jboss.org/jira/browse/WELDSE-1.
Do you guys see any problem on including org.slf4j:slf4j-simple inside
the Jar ? Doing that, no external dependencies are required to run
weldse besides the JAR and placing the application in java.ext.dirs.
16 years
Ordering of TCK Tests
by Gurkan Erdogdu
Hello;
Altough I have already brought this issue onto the table, I am getting the same issues again.
Below tests are passed and failed while running multiple times of TCK. These tests are :
First Category :
If I run below tests as a seperate TestNG test class, all of them are passed.
ProducerMethodLifecycleTest # testCreateReturnsNullIfProducerDoesAndDependent
ResolutionByNameTest # testAmbiguousELNamesResolved
DuplicateNamePrefixResolutionTest # testDuplicateBeanNamePrefix
UnproxyableTest #
testInjectionPointWithUnproxyableTypeWhichResolvesToNormalScopedBean
Second Caegory:
If I run below tests as a seperate TestNG test class, all of them are
passed sometimes, failed sometimes.
ResolutionByTypeTest # testGenericBeanTypesOnProducerMethod
ResolutionByTypeTest # testGenericBeanTypesOnProducerField
ResolutionByTypeTest # testGenericBeanTypesOnManagedBean
General Observation:
At one run this tests have passed, after that I run TCK again, this time some of them are failed!
--Gurkan
16 years
Build status emails
by Pete Muir
All,
Hudson sends out emails if a commit you make causes the build to fail. If you work for Red Hat, your email address is set up automatically. If you don't, and you do commit to Weld or Seam, please could you send me your jboss.org username, and the email address you would like these emails to go to so I can check that you have the correct details entered into Hudson?
Thanks!
16 years
FYI: Plan of action for archetypes updates (javax.*-else-org.jboss.spec.javax.*)
by Steven Boscarine
Hello All,
To give an update to the community and ask for your input...
The weld archetypes need to be updated. While weld and JSF work great,
some other Java EE 6 APIs are missing, like EJB 3.1 and Servlet 3.0.
Sun/Oracle has not yet published official javax.* jars for key APIs like
EJB 3.1, so we have to rely on jars from other vendors. For example,
JBoss has made their EJB 3.1 API jars available as
http://repository.jboss.org/maven2/org/jboss/spec/javax/ejb/jboss-ejb-api...
The goal of the Java EE half of weld archetypes (in contrast to the
servlet versions) has creeped a bit from being just for weld development
to being an archetype for Java EE 6.0 development. This is because it
is pretty difficult to do much useful work with Weld and JSF alone.
Most developers will need the full Java EE stack, including other APIs
such as JPA and EJB. We'd like to provide those APIs in the archetypes,
but the official javax.* API jars are either not available at all or not
published to Maven Central.
Therefore, the strategy going forward will be to use an official javax.*
jar either from Maven Central or from the JBoss repo if it's legally
allowed to be redistributed, but not yet on central. Otherwise, we'll
be using the org.jboss.spec.javax.* equivalent API jar.
The org.jboss.spec.javax.* jars work just fine on Glassfish and
presumably other containers, they're just published with the JBoss
namespace.
We'll test the archetypes in JBoss AS 6 and Glassfish v3. If anyone
wants to help out with other containers, we'd be happy to work with you
on that as well.
Does anyone see any concerns with this approach?
The key question is if you're not using JBoss AS, will you be put off so
much by seeing a provided-scoped dependency of
org.jboss.spec.javax.ejb.jboss-ejb-api_3.1_spec-1.0.0.Beta1 that you'll
give up all hope on these archetypes, go somewhere else and blog nasty
things about all of us? :)
Thanks,
Steven
16 years
