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
2 months
Question about the spec for BeanManager.getBeans
by Benjamin Confino
Hello
I was made aware of the difference on the return of
beanManager.getBeans(Object.class) between OWB and Weld
In OWB, it returns all beans, unless there is an enabled @alternative
within the application. If there is an enabled @alternative getBeans()
only returns beans annotated @alternative.
However, in Weld, it returns all beans even with an enabled @alternative.
The JavaDoc for BeanMnanager says "according to the rules of typesafe
resolution" and in the CDI 1.0 spec under typesafe resolution I find one
mention of alternatives: “When an ambiguous dependency exists, the
container attempts to resolve the ambiguity. The container eliminates all
eligible beans that are not alternatives, except for producer methods and
fields of beans that are alternatives.” (This text is also in the CDI 1.2
spec)
However this would imply that if there are no enabled @Alternatives an
ambiguous resolution like beanManager.getBeans(Object.class) should
discard everything. In this case, the Weld behaviour is incorrect.
beanManager.getBeans() should only return the resolved or enabled beans.
Regards
Benjamin
Can someone verify this?
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
7 years, 6 months
Reattach to conversation
by James .
I want to join an existing conversation scope.
I start the conversation with:
conversation.begin(packageId);
I got close with using the following which seems to work:
@Inject @Http CoversationContext context;
context.activate(packageId);
However I'm seeing a warning in the log which suggests I'm not getting it right.
WARN: WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing: HttpServletRequestImpl [ POST /path/to/url ]
I'm also happy if there is an alternative way to just drop the conversation and recreate (so long as I can continue using the same custom conversation ID) I'm trying to avoid the user reloading the page multiple times filling up memory with duplicates of the same package data.
I also considered using a @SessionScoped bean but I thought if I can set the package ID to be the conversation ID then I can avoid the need to manage a @SessionScoped bean.
7 years, 7 months
Weld Probe not initalized during AfterDeploymentValidation
by Benjamin Confino
Hello
I've been seeing probe not initalized exceptions that occur on CDI 2.0 but
not CDI 1.2, from what I can see when I debug into the issue the problem
occurs in
TransactionalObserverNotifier(ObserverNotifier).notifySyncObservers
In CDI 1.2 I see that the the ArrayList observers has two entries, the
first being ProbeExtension.afterDeploymentValidation
In CDI 2.0 I see four entries, with the first being
org.apache.myfaces.cdi.config.FacesConfigExtension
And when the afterDeploymentValidation method of FacesConfigExtension is
called the result is org.jboss.weld.exceptions.IllegalStateException:
PROBE-000005: Probe is not properly initialized. I've attached a stack
from that error:
And the source is on github:
https://github.com/apache/myfaces/blob/master/impl/src/main/java/org/apac...
So what are the options here? I don't see anything under
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#after_deployment_validation
saying that you shouldn't invoke beans during after deployment validation
observers. A bit earlier in 11.5 it says "If other beans are injected into
an extension’s observer methods, non-portable behavior results" but it's
not clear if that refers to using the injected bean manager to lookup a
bean.
Presumably if weld-probe needs to run first there's some code to ensure it
does? Do we need to do something to integrate with that code, or avoid
integrating myfaces?
Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
7 years, 7 months
