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
Unique BeanIdentifierIndex every time I restart a server
by Benjamin Confino
Hello.
I've been investigating a bug relating to session failover and I've
noticed that my BeanIdentifierIndex has a different hash every time I
start and stop the server. This is consistent across every app I tried.
For example:
Upon starting the server I see my debug output
GREP BeanIdentifierIndex [hash=591986009, indexed=3]
0:
WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession
1:
WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession
2:
WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader@d6318459[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession
I stop the server, and start it again
GREP BeanIdentifierIndex [hash=-375657379, indexed=3]
0:
WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession
1:
WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession
2:
WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader@b3a3f568[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession
Same three classes but the hash is completely different.
My question is simple. Is this the expected behaviour or is this a sign
that something's gone wrong?
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
9 years, 5 months
Race condition in HttpContextLifecycle requestInitialized
by Benjamin Confino
Hello.
We have a problem from a race condition in
HttpContextLifecycle.requestInitialized()
The condition is as follows:
Thread one calls nestedInvocationGuard.set(new Counter());
Thread two calls Counter counter = nestedInvocationGuard.get(); Object
marker = request.getAttribute(GUARD_PARAMETER_NAME);
Thread one has not yet called request.setAttribute(GUARD_PARAMETER_NAME,
GUARD_PARAMETER_VALUE);
This will result in thread two having a counter but no marker, leading to
ServletLogger.LOG.guardLeak(counter.value);
I believe this issue is known because of the following comment.
* This request has not been processed yet but the guard is set already.
That indicates, that the guard leaked from a previous request
* processing - most likely the Servlet container did not invoke listener
methods symmetrically. Log a warning and recover by
* re-initializing the guard
I am assuming that "symmetrically" is supposed to say "synchronised".
I have checked with the relevant team and there is no way we can call that
method from inside a synchronised block. So I was hoping that you might
have some alternatives?
I noticed that the file at
https://github.com/doctau/weld-core/blob/master/impl/src/main/java/org/jb...
has been updated and no longer has that race condition? Do you think
including that update resolve this issue? And if so which release will
include that update.
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
9 years, 5 months
