[alesj]

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.

[ron_sigal]

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

[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).

[gaohoward]

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.

[jharting]

Do you know where does org.jboss.weldx.jms.Destination$Queue come from? AFAIK it is not something Weld provides.

[alesj]

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.

[alesj]

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.

[gaohoward]

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.

[jharting]

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.

[ron_sigal]

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

[ron_sigal]

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

[jharting]

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).

[ron_sigal]

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

[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?

[jharting]

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.