Does injection perform standard JSF conversion?

[adambrod]

Hi-

I have a property in my managed bean that is injected from the request parameters. Will Seam perform standard conversions like regular JSF managed properties?

This property fails:

@In("#{param.managedFileId}")
protected Long managedFileId;

with the exception below. From what I can tell, Seam is trying to inject the request parameter as a String, but the target expects a Long. How can I fix this? Here is the request url I'm using: http://localhost:8000/files/dFile.faces?managedFileId=30050

java.lang.IllegalArgumentException
 at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
 at java.lang.reflect.Field.set(Field.java:656)
 at org.jboss.seam.Component.setFieldValue(Component.java:1210)
 at org.jboss.seam.Component.injectFields(Component.java:1024)
 at org.jboss.seam.Component.inject(Component.java:795)
 at org.jboss.seam.interceptors.BijectionInterceptor.bijectTargetComponent(BijectionInterceptor.java:30)
 at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:13)
 at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
 at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
 at org.jboss.seam.interceptors.ConversationInterceptor.endOrBeginLongRunningConversation(ConversationInterceptor.java:82)
 at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:13)
 at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
 at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
 at org.jboss.seam.interceptors.BusinessProcessInterceptor.manageBusinessProcessContext(BusinessProcessInterceptor.java:60
 at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:13)
 at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
 at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
 at org.jboss.seam.interceptors.TransactionInterceptor.doInTransactionIfNecessary(TransactionInterceptor.java:34)
 at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:13)
 at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
 at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
 at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:39)
 at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:13)
 at org.jboss.seam.interceptors.Interceptor.aroundInvoke(Interceptor.java:90)
 at org.jboss.seam.interceptors.SeamInvocationContext.proceed(SeamInvocationContext.java:60)
 at org.jboss.seam.ejb.SeamInterceptor.aroundInvokeInContexts(SeamInterceptor.java:73)
 at org.jboss.seam.ejb.SeamInterceptor.aroundInvoke(SeamInterceptor.java:45)
 at org.jboss.seam.interceptors.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:51)
 at org.jboss.seam.interceptors.JavaBeanInterceptor.intercept(JavaBeanInterceptor.java:39)
 at com.intralinks.web.managedfile2.DisplayManagedFileController$$EnhancerByCGLIB$$c2e391ae.toString(<generated>)

[adambrod]

Actually, I found the solution. Instead of using standard @In injection, I needed to use @RequestParameter. @RequestParameter will perform the correct type conversion, whereas @In won't.

Here is the corrected code:

@RequestParameter("#{managedFileId}")
protected Long managedFileId;

[adambrod]

Doh! One more correction:

@RequestParameter("managedFileId")
protected Long managedFileId;

Not supposed to use regular JSF expressions if I'm using RequestParameter injection...

[adambrod]

FYI, I created an Issue so that Seam treats request parameters more consistently.

http://jira.jboss.com/jira/browse/JBSEAM-354

[bfo81]

You can leave out that stuff in the brackets since its exactly the same like the property name. You only need to explicitely type it in when the property's name differs from the request parameters name ;).

[adambrod]

That's a good point. I don't yet feel comfortable using private variable names as a shared public name. That feels like a violation of encapsulation to me. Plus, it is much to easy for a developer to rename a private variable without realizing the side-effects.

Anyway, thanks for the tip!

[bfo81]

Hm... that's a little like programming against interfaces or not. If you do so, then you can easyly switch the implementation, but you have more "overhead" code and files. And here your @In annotation "grows", though it's only some chars. But I always intend to have the smallest and simplest code as possible to make at is readable and easy to understand as possible. But everything depends on what you prefer ;).

However, I'd like to say something about the JIRA request. IMO

- @In annotations shall be reservered for Seam components (namely those classes annotated with @Name or @Role), and nothing else. The point is that @In (and @Out, too) has a scope attribute which is only applicable to Seam components! And EL expressions might represent a Seam component, but they often don't ;).

- @RequestParameter shall be for request parameters. The name is king (ok, and Gavin, too *g*).

- And for EL expressions I think it's better to retrieve the concrete objects and access their accessor methods directly. But ok, dependency injection / inversion of control is a very nice feature.... so I'd prefer a completely new annotation.

But as I said that's just an opinion ;).

[pmuir]

Adam, if you prefer not to annotate private member variables you can annotate the getter/setter with @In/@Out which is consistent with the EL (getName -> name etc) (which can then be put in your interface etc).