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
7 months, 2 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, 3 months
Modularity
by Pete Muir
I was talking to Ales and Lincoln on IRC about how Weld handles modular environments. Whilst we have a full structure for representing module visibility relationships, we don't have any way of expressing that a bean is private to a module - all beans are exported. I don't think this really is consistent with how modular systems work, and so I think we need to add this to the BDA contract e.g.
public Collection<String> getPrivateBeanClasses();
I would suggest returning private/hidden classes rather than public ones here, as it means non-modular envs don't need to adjust their code much to have everything work as normal.
15 years
Conversation questions
by Nicklas Karlsson
Some conversation-related questions
1. In WeldPhaseListener.activateConversations(), it appears as if the
conversation context is never activated if an unknown cid comes in.
Shouldn't the conversation context still be active but with a transient
conversation? Moving the conversationContext.activate(cid); before the check
might work.
2. Is there any way of setting the conversation timeout globally? The
constant defined in AbstractConversationContext appears to be injected into
the constructor of the ConversationImpl. If it would be acquired from a
producer method, could it then be specialized?
3. Should we have a concept of a "foreground conversation" in Weld so that
an incoming cid to a known, non-transient conversation would resurrect the
conversation even if it has been expired (but not yet cleaned up)? If I read
the code correctly, a cid that comes in after the expire time has passed is
still taken into use for the request but at the end marked as ended and then
cleaned up as transient.
--
---
Nik
15 years
