-
15. Re: Hornetq and CDI
alesj Nov 21, 2012 12:12 PM (in response to ron_sigal)How portable should this be?
e.g. could you make this HornetQ portable only?
In that case you could expose HornetQDestination as produced type, and it should work.
Alhough, it's weird, as your producer is dependant scoped, hence should produce pure instances - aka no proxies.
-
16. Re: Hornetq and CDI
ron_sigal Nov 21, 2012 1:55 PM (in response to alesj)Hi Ales,
re: "How portable should this be? e.g. could you make this HornetQ portable only? In that case you could expose HornetQDestination as produced type, and it should work."
It's fine for me, since I'm just writing some tests that run on AS 7. But it might not work for someone else.
Anyway,I changed the producer field in ResourceProducer class to
@Produces
@ResourceBinding
@Resource(mappedName="java:jboss/exported/jms/queue/test")
HornetQDestination bookQueue;
and I got:
Can not set org.hornetq.jms.client.HornetQDestination field org.jboss.resteasy.cdi.injection.ResourceProducer.bookQueue to org.hornetq.jms.client.HornetQQueue
I had the same problem when I changed it to HornetQQueue. That's weird.
By the way, Ales, I saw your name in the ProxyFactory code and just assumed that you were part of the Weld team. Sorry about that. Come to think of it, I guess I assume that you're part of every team.
-Ron
-
17. Re: Hornetq and CDI
ron_sigal Nov 21, 2012 2:04 PM (in response to ron_sigal)Questions from Jozef Hartinger
What kind of proxy is it? Could you provide the FQCN of the proxy? Which version of Weld?
1. It's a CDI proxy.
2. FQCN: org.jboss.weldx.jms.Destination$Queue$1195520705$Proxy$_$$_Weld$Proxy$
3. I'm using weld-core-1.2.0-SNAPSHOT.jar, with a fix to WELD-1174 "Incorrect interceptor invocation order when combining CDI interceptors with @Interceptors" (https://issues.jboss.org/browse/WELD-1174).
-
18. Re: Hornetq and CDI
gaohoward Nov 22, 2012 3:35 AM (in response to ron_sigal)Well I didn't see there is a HornetQQueue in the types. The strange thing is when you print out the bookQueue, the output is exactly what a HornetQQueue.toString() would return.
-
19. Re: Hornetq and CDI
jharting Nov 22, 2012 10:33 AM (in response to ron_sigal)Do you know where does org.jboss.weldx.jms.Destination$Queue come from? AFAIK it is not something Weld provides.
-
20. Re: Hornetq and CDI
alesj Nov 22, 2012 10:47 AM (in response to ron_sigal)Anyway,I changed the producer field in ResourceProducer class to
@Produces
@ResourceBinding
@Resource(mappedName="java:jboss/exported/jms/queue/test")
HornetQDestination bookQueue;
and I got:
Can not set org.hornetq.jms.client.HornetQDestination field org.jboss.resteasy.cdi.injection.ResourceProducer.bookQueue to org.hornetq.jms.client.HornetQQueue
What about if you change it to this:
@Resource(mappedName="java:jboss/exported/jms/queue/test")
Queue bookQueue;
@ResourceBinding @Produces
public HornetQDestination toDestination() {
reture (HornetQDestination) bookQueue;
}
By the way, Ales, I saw your name in the ProxyFactory code and just assumed that you were part of the Weld team. Sorry about that. Come to think of it, I guess I assume that you're part of every team.
I actually lead Weld team, until 3weeks ago. :-)
It now all in Jozef's hands.
-
21. Re: Hornetq and CDI
alesj Nov 22, 2012 10:47 AM (in response to jharting)Do you know where does org.jboss.weldx.jms.Destination$Queue come from? AFAIK it is not something Weld provides.
This looks like some Solder or old WeldExtensions.
-
22. Re: Hornetq and CDI
gaohoward Nov 22, 2012 9:51 PM (in response to ron_sigal)It seems a weld problem, not hornetq's.
Anyway if I use a holder class to wrap the queue, it seems working. Here is what I do:
1. Define a plain java class
public class QueueHolder
{
private Queue queue;
public QueueHolder(Queue q)
{
queue = q;
}
public Queue getQueue()
{
return queue;
}
}
2. Define a Produces in ResourceProducer:
@Produces
QueueHolder getQueueHolder()
{
if (queueHolder == null)
{
queueHolder = new QueueHolder(bookQueue);
}
return queueHolder;
}
3. Inject the holder:
@Inject
private QueueHolder queueHolder;
4. User the get method:
MessageProducer producer = session.createProducer(queueHolder.getQueue());
...
However I don't know much about CDI annotations, I just use whichever annotations can get my test working. For example I use @ApplicationScoped rather than @sessionScoped.
-
23. Re: Hornetq and CDI
jharting Nov 23, 2012 1:29 AM (in response to ron_sigal)It seems that we use a proxy that proxies injection point types (e.g. Queue) only. We use the proxy to make sure the reference is passivation capable. Ales's workaround should work.
-
24. Re: Hornetq and CDI
ron_sigal Dec 12, 2012 11:48 PM (in response to jharting)Hi everyone,
I've been a little distracted, and I'm just getting back to this issue.
I find that if I take Ales' suggestion in comment #20 and replace a producer field with a producer method:
// @Produces
// @ResourceBinding
@Resource(mappedName="java:jboss/exported/jms/queue/test")
Queue bookQueue;
@ResourceBinding
@Produces
public Queue toDestination()
{
return bookQueue;
}
I get a HornetQQueue instead of a Destination$Queue$1195520705$Proxy$_$$_Weld$Proxy$, and HornetQ is happy.
I don't know why the producer field and producer method behave differently ...
-Ron
-
25. Re: Hornetq and CDI
ron_sigal Dec 12, 2012 11:47 PM (in response to gaohoward)Hi Howard,
I think I understand why your suggestion works. In your case, the queue is a member of another class, so it's not turned into a proxy. That would be fine, but I don't think it should be necessary to play that trick.
Thanks,
Ron
-
26. Re: Hornetq and CDI
jharting Dec 13, 2012 10:26 AM (in response to ron_sigal)It's because the spec requires each resource is a passivation capable dependency. Weld guarantees that by using a serializable proxy which is generated for the resource type.
For producer methods this is different because the spec does not always require the object returned from the producer method to be passivation capable (and this is also checked at runtime, not deployment time).
-
27. Re: Hornetq and CDI
ron_sigal Dec 13, 2012 8:31 PM (in response to jharting)Hi Josef,
Thank you. That's good information. Not to beat a dead horse, but I don't see the distinction in the 1.0 spec (page 55):
• A producer method is passivation capable if and only if it never returns a value which is not passivation capable at runtime. A producer method with a primitive return type or a return type that implements or extends Serializable is passivation capable. A producer method with a return type that is declared final and does not implement Serializable is not passivation capable.
• A producer field is passivation capable if and only if it never refers to a value which is not passivation capable at runtime. A producer field with a primitive type or a type that implements or extends Serializable is passivation capable. A producer field with a type that is declared final and does not implement Serializable is not passivation capable.
-Ron
-
28. Re: Hornetq and CDI
ron_sigal Dec 13, 2012 9:23 PM (in response to ron_sigal)Oh, I think I see. The Queue resource itself is required to be passivation capable. But the value returned by a producer method isn't required to be passivation capable. So if the Queue is returned by a producer method ... . Hmmm. Seems kind of ambiguous. So the Queue field holds a proxy but Weld "unwraps" the Queue proxy when the producer method returns the Queue?
-
29. Re: Hornetq and CDI
jharting Dec 14, 2012 2:38 AM (in response to ron_sigal)No, the field does not hold a proxy. However, when the field value is injected somewhere it is wrapped within a proxy. This does not happen for plain producer methods and fields.