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
8 years, 8 months
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.
8 years, 10 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
8 years, 10 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);
}
}
}
8 years, 11 months
