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
13 years, 10 months
are AnnotatedType and Co immutable?
by Mark Struberg
Hi folks!
If I pat(@Observes ProcessAnnotatedType annotatedType), is it allowed to simply modify the Sets?
E.g. call
annotatedType.getAnnotations().add(myOwnAnnotation) ?
The spec imo doesn't mention that those Sets are immutable, so it should work. It works in OWB at least, but what about Weld and CanDI?
txs and LieGrue,
strub
15 years
wrong msg numbers in ConversationMessage
by Ales Justin
Any particular reason why ConversationMessage has 2xx numbers,
where it should only have 3xx, while ContextMessage is the right 2xx owner?
Also, 214 actually overlaps with ContextMessage' 214.
I guess we can fix this for v1.2.
And we just make sure we know which Weld version is used when dealing with the msg numbers.
-Ales
---
/**
* Log messages for conversations
*
* Message Ids: 000300 - 000399
*
*/
public enum ConversationMessage
{
@MessageId("000300") NO_CONVERSATION_TO_RESTORE,
@MessageId("000301") UNABLE_TO_RESTORE_CONVERSATION,
@MessageId("000302") CONVERSATION_LOCK_UNAVAILABLE,
@MessageId("000303") CONVERSATION_SWITCHED,
@MessageId("000304") CLEANING_UP_CONVERSATION,
@MessageId("000305") CONVERSATION_TERMINATION_SCHEDULED,
@MessageId("000306") CONVERSATION_TERMINATION_CANCELLED,
@MessageId("000307") CONVERSATION_TERMINATION_CANCELLATION_FAILED,
@MessageId("000308") DESTROY_LRC_COMPLETE,
@MessageId("000309") LRC_COUNT,
@MessageId("000310") DESTROY_TRANSIENT_COVERSATION,
@MessageId("000311") DESTROY_LRC,
@MessageId("000312") DESTROY_ALL_LRC,
@MessageId("000313") CONVERSATION_LOCKED,
@MessageId("000314") CONVERSATION_UNLOCKED,
@MessageId("000315") CONVERSATION_UNAVAILBLE,
@MessageId("000316") ILLEGAL_CONVERSATION_UNLOCK_ATTEMPT,
@MessageId("000317") PROMOTED_TRANSIENT,
@MessageId("000318") DEMOTED_LRC,
@MessageId("000319") SWITCHED_CONVERSATION,
---> HERE
@MessageId("000214") BEGIN_CALLED_ON_LONG_RUNNING_CONVERSATION,
@MessageId("000215") END_CALLED_ON_TRANSIENT_CONVERSATION,
@MessageId("000216") NULL_HTTP_SESSION,
@MessageId("000217") SWITCHING_MODE_RESETS_TIMEOUTS,
@MessageId("000218") CONVERSATION_ID_ALREADY_IN_USE,
15 years
Offering beans post container initialization?
by aalmiray
Hi guys,
I wonder if it's possible to offer a set of bean instances (not-managed by
the container) so that their dependencies are satisfied by the container. As
an example, you can grab a Spring BeanFactory and call autowire on it, like
this
app.applicationContext.getAutowireCapableBeanFactory()
.autowireBeanProperties(instance,
AutowireCapableBeanFactory.AUTOWIRE_BY_NAME, false)
Is there a similar API in Weld/CDI?
TIA
Andres
--
View this message in context: http://weld-development-discussions.46994.n3.nabble.com/Offering-beans-po...
Sent from the Weld development discussions mailing list archive at Nabble.com.
15 years
How to avoid classes being picked as managed beans?
by aalmiray
Hello guys. I'm new to Weld and CDI, perhaps the subject of this message is a
bit obvious to some of you but for the life of me couldn't find a portable
solution to the following problem: Weld will pick up all classes of an
application (found in a single jar that contains an empty beans.xml file),
however I would like the container to cherry pick a set of classes based on
some criteria (package name, class name convention, annotation, etc).
I've seen that Weld has an extension (non-standard) that allows classes to
be annotated with @Veto. It works fine but it poses to additional problems:
- @Veto is Weld specific
- you must annotate each class explicitly, which causes trouble with some
classes I have in my app as they are Groovy scripts, thus I can't annotated
them (Groovy script do get compiled to class files but you don't actually
'see' the class definition, it is generated by the compiler, thus the
annotation could only be added by a compiler plugin that rewrites the
generated AST (yes, it can be done but it's a heck of a Yak shaving at this
point)).
So, is there a way to specify which classes should be included/excluded in a
more generic, standard way?
TIA.
Andres
--
View this message in context: http://weld-development-discussions.46994.n3.nabble.com/How-to-avoid-clas...
Sent from the Weld development discussions mailing list archive at Nabble.com.
15 years
Potential Weld maintenance release
by Brian Leathem
Hello Weld devs,
I am under the understanding that the next Weld release will be Weld
1.2, with potential SPI changes. I am writing to ask about the
possibility of more frequent weld maintenance releases, using the same
SPI. This would greatly benefit the Seam 3.0 release, as there are a
couple of modules that currently do not work as expected due to bugs in
Weld. Specifically:
WELD-846 - Incorrect handling of cyclic dependencies between
BeanDeploymentArchives
causes: SEAMFACES-82, no injection in JSF Converters/Validators
WELD-833 - ConcurrentModificationException while deactivating conversations
renders Seam Wicket unusable
and potentially:
WELD-855 - Error while catching NonexistentConversationException with
Seam Faces/Catch
causes: SEAMCATCH-46
Some of these issues have been already resolved in Weld, and can be
worked around by using a Weld SNAPSHOT. However, it is probable that
more issues will arise as more people start using Seam 3, and a quick
turnaround on Weld releases would help greatly with user acceptance of
Seam 3. It would also bode well for containers that were quick to adopt
the Weld maintenance releases.
If there is any more details I can provide, or further strengthening of
the above arguments, please let me know.
Regards,
Brian Leathem
Seam Faces - Module Lead
15 years
