WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
4 months, 3 weeks
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
14 years
Conversation scope in servlet context.
by Guilherme Namen
Hi.
I would like to know if someone are developing a conversation scope
for servlet context. There is a planing for it? If has how i could
help.
Recently i developed a filter that injects a conversation scope in
servlet context. The source are attached. Someone could look and
critic the code.
Thanks.
14 years, 3 months
Two interceptor bindings considered the same when the only annotation member is nonbinding?
by Marko Lukša
According to the spec, BeanManager.resolveInterceptors() should throw
IAE if two instances of the same interceptor binding type are given.
o.j.weld.tests.interceptors.tb.GenericDAO is annotated @Tx(0) and its
method find() is annotated @Tx(1). The annotation's only member is
*Nonbinding*.
- So @Tx(0) and @Tx(1) are considered to be the _same_ binding?
- The spec allows (doesn't disallow) methods to be annotated with the
same binding type as the class, right?
- However, calling resolveInterceptors with these two should throw IAE?
Currently it does not.
I've made fixes for WELD-999 and now resolveInterceptors does in fact
throw IAE in this case. But I guess I now have to remove duplicate
bindings before calling resolveInterceptors in cases where the method of
a bean is annotated with the same binding type as the bean itself.
Am I wrong in assuming that @Tx(0) and @Tx(1) are the same binding?
Regards
Marko
14 years, 3 months
inner classes and param types
by Ales Justin
Anyone seen this, or how to make this deterministic ...
I have these 2 classes - (a) and (b) - see below.
And this code:
final Annotation[][] parameterAnnotations = constructor.getParameterAnnotations();
final Type[] genericParameterTypes = constructor.getGenericParameterTypes();
// If the class is a (non-static) member class, its constructors
// parameterTypes array will prefix the
// outer class instance, whilst the genericParameterTypes array isn't
// prefix'd -- not always true ...
int nesting = Reflections.getNesting(declaringClass.getJavaClass());
for (int i = 0; i < parameterTypes.length; i++) {
int gi = i - nesting;
Annotation[] annotations = (gi >= 0 && parameterAnnotations[gi].length > 0) ? parameterAnnotations[gi] : EMPTY;
Class<?> clazz = parameterTypes[i];
Type parameterType = genericParameterTypes[i];
So, the issue is - as I added "not always true" to the existing comment,
that "genericParameterTypes" are random in my case --
sometimes they have owner class prefixed == use case (a),
sometimes they don't == use case (b), hence resulting in ArrayIOOBE.
Any idea why is this so?
-Ales
---
(a)
public class Crasher {
protected class NonStaticInner {
public NonStaticInner(@Nonnull Integer a) {
System.out.println("Hi" + a);
}
protected class NonStaticInner2 {
public NonStaticInner2(@Nonnull Double a) {
System.out.println("Hi" + a);
}
}
}
}
(b)
public class ExampleTest {
...
public class NonContextual<T> {
final InjectionTarget<T> it;
final BeanManager manager;
public NonContextual(BeanManager manager, Class<T> clazz) {
this.manager = manager;
AnnotatedType<T> type = manager.createAnnotatedType(clazz);
this.it = manager.createInjectionTarget(type);
}
public CreationalContext<T> postConstruct(T instance) {
CreationalContext<T> cc = manager.createCreationalContext(null);
it.inject(instance, cc);
it.postConstruct(instance);
return cc;
}
public void preDestroy(T instance) {
it.preDestroy(instance);
}
}
}
14 years, 3 months
