5 Replies Latest reply on Jul 24, 2006 10:13 AM by iradix

Proper way to instantiate seam managed component

iradix Jul 21, 2006 4:53 PM

I have a SFSB that, when invoked by a JSF action, needs to delegate its' function to multiple other SFSB of the same type. I can't use the standard @In(create = true) annotation here because besides the fact that the delegates are stored in a List, I need a new unique instance for each one. What I've attempted to do is use the Component.newInstance() method, and although that does return an object of the correct type, that object does not appear to be intercepted correctly. Each of the delegates has a @Logger annotation yet the Log instance is always null. I even added @Intercept(InterceptionType.ALWAYS) but it has made no difference. This seems particular strange to me since I'd imagine all my SessionBeans would be intercepted due to the

<ejb-jar>
 <assembly-descriptor>
 <interceptor-binding>
 <ejb-name>*</ejb-name>
 <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
 </interceptor-binding>
 </assembly-descriptor>
</ejb-jar>

statement in ejb-jar.xml. Am I making any glaring mistakes?

1. Re: Proper way to instantiate seam managed component

gavin.king Jul 21, 2006 5:27 PM (in response to iradix)

You should really use Component.getInstance(), not Component.newInstance().

Are you saying that when you do that, the Log does not get injected?
Actions
2. Re: Proper way to instantiate seam managed component

iradix Jul 21, 2006 5:37 PM (in response to iradix)
You should really use Component.getInstance(), not Component.newInstance().

The problem with getInstance() is after I create the first instance subsequent calls will retrieve the same instance from whatever context it was published to. I need seperate, unique instances of the same bean and from a quick look through the code newInstance() was the only way to accomplish that.

Are you saying that when you do that, the Log does not get injected?

That's exactly what I'm saying, although after I changed the definition from

@Logger private Log log

To
private Log log = new LogImpl(ClassName.class)

It started working even though it extends an abstract class that also uses Logger injection. In other words, the subclass seems to correctly recieve a Log instance but the superclass does not. Maybe it's a bug in Component where a Log is only injected into the first annotation along the class heirarchy?
Actions
3. Re: Proper way to instantiate seam managed component

cptnkirk Jul 21, 2006 8:25 PM (in response to iradix)

So you want to be able to manually create a list of new uniquely isolated SFSBs on each call to your JSF action? This sounds like a bad thing. What is your use case?

In any case, see if adding @Intercept(InterceptionType.ALWAYS) to your component definitions help. I have a feeling that you're missing out on the normal invoke_application injection when you create your components via Component.newInstance().
Actions
4. Re: Proper way to instantiate seam managed component

gavin.king Jul 23, 2006 7:30 PM (in response to iradix)

"iradix" wrote:

Are you saying that when you do that, the Log does not get injected?

That's exactly what I'm saying, although after I changed the definition from

How are you determining that it does not get injected? I hope you are not just looking at the object in your debugger...
Actions
5. Re: Proper way to instantiate seam managed component

iradix Jul 24, 2006 10:13 AM (in response to iradix)

Sorry for the delay in replying.

In any case, see if adding @Intercept(InterceptionType.ALWAYS) to your component definitions help.

As I said before, I already tried the @Intercept annotation; no dice.

So you want to be able to manually create a list of new uniquely isolated SFSBs on each call to your JSF action? This sounds like a bad thing. What is your use case?

No, the unique instances are created when the "parent" SFSB is initialized, not on each call. I'm somewhat new to the EJB model but these instances recieve JSF actions (therefore they must be transactional themselves) and maintain state across invocations so it seems to me that SFSB are the way to go.

How are you determining that it does not get injected?

Actually, I didn't even go so far as to load the debugger up. I got a null pointer exception on my logging call so I threw a quick System.err.println statement in to confirm that the Log instance was indeed null during the method invocation.
Actions

Go to original post