That looks to me like you're having CP issues. Do you have the weld jars in 
your archive as well as the app server?

WRT the @Out question if you want the same kind of functionality you have to 
create a wrapper component and play the scope game with it that way 
(Conversation scoped wrapper with a setter for the actual instance).

Hope that helps. 

Sent from my iPhone

On Apr 4, 2011, at 15:42, Antoine Sabot-Durand <[email protected]> wrote:

> Hi Dan and Team,
> 
> Sorry to go back to this subject but I don't get the expected result from 
> @produces.
> In Seam social Web client example, I tried to outject currentServiceHdl in 
> SocialClient bean  like this :
> 
> @Produces
>    @Named
>    public OAuthServiceHandler getCurrentServiceHdl()
>    {
>       return currentServiceHdl;
>    }
> 
> and I get the following exception when Social client is initialized 
> (apparently in the @Postconstruct callback) from JSF call (notice that 
> currentServiceHdl is not in the JSF view that triggers the exception only 
> socilaClient) :
> 
> 
> java.lang.NoClassDefFoundError: org/jboss/weld/exceptions/WeldException
>       at 
> org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:595)
>       at 
> org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.postConstruct(ManagedBean.java:200)
>       at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:340)
>       at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:121)
>       at 
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
>       at 
> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:87)
>       at 
> org.jboss.seam.social.example.webclient.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$antoine$Documents$Eclipse_workspaces$seam-social$$metadata$$plugins$org$jboss$ide$eclipse$as$core$JBoss_6$0_Runtime_Server1295753022377$deploy$seam-social-web-client$war"-ManagedBean-class_org$jboss$seam$social$example$webclient$SocialClient_$$_WeldClientProxy.getServiceHandlers(org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$antoine$Documents$Eclipse_workspaces$seam-social$$metadata$$plugins$org$jboss$ide$eclipse$as$core$JBoss_6$0_Runtime_Server1295753022377$deploy$seam-social-web-client$war"-ManagedBean-class_org$jboss$seam$social$example$webclient$SocialClient_$$_WeldClientProxy.java)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
> removing @Produces @Named make the exception disappears.
> 
> Any clue ?
> 
> Antoine SABOT-DURAND
> 
> 
> Le 16 mars 2011 à 23:09, Antoine Sabot-Durand a écrit :
> 
>> Thanks for the douse I'm going to test this right away.
>> 
>> Antoine Sabot-Durand
>> 
>> Le 16 mars 2011 à 18:29, Dan Allen <[email protected]> a écrit :
>> 
>>> You can create a producer that aliases a name to a property, like this:
>>> 
>>> @Produces @Named
>>> public Hotel getHotel() { return booking.getHotel(); }
>>> 
>>> #{hotel}
>>> 
>>> You can also use a producer field, like so:
>>> 
>>> @Produces @Named
>>> private Hotel hotel;
>>> 
>>> #{hotel}
>>> 
>>> Produces sort of turns outjection on it's head. But if you think about it, 
>>> it's a better way to go about it because it's more robust to read the state 
>>> of the model as it is, then try to shift the information around into 
>>> variables from which to read them, as outjection did.
>>> 
>>> What you can't do is use the same variable name to refer to state on two 
>>> different models, unless of course your producer method does some 
>>> conditional logic (saying if this screen, give this result, if this screen, 
>>> give a different result). But again, that's a good thing because then 
>>> tooling can actually tell you where the data is coming from.
>>> 
>>> This is a key topic for the migration guide. Feel free to contribute 
>>> examples of how you might solve an outjection scenario with produces. It's 
>>> a good exercise anyway.
>>> 
>>> -Dan
>>> 
>>> On Wed, Mar 16, 2011 at 13:03, Ken Finnigan <[email protected]> wrote:
>>> If you want the result of @Produces to be EL accessible just throw a @Named 
>>> on it.
>>> 
>>> Ken
>>> 
>>> Sent from my iPhone
>>> 
>>> On Mar 16, 2011, at 13:02, Antoine Sabot-Durand <[email protected]> 
>>> wrote:
>>> 
>>>> For what I understand, it's not quite the same. I think it's more like 
>>>> @Factory, but I agree it's nearly the same and I could use it was possible 
>>>> to "Named" the "outjected" property in order to use it in EL...
>>>> 
>>>> Antoine 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Le 16 mars 2011 à 17:54, Ken Finnigan a écrit :
>>>> 
>>>>> Antoine,
>>>>> 
>>>>> I'm pretty sure the equivalent for CDI is to use @Produces.
>>>>> 
>>>>> Ken
>>>>> 
>>>>> 
>>>>> On Wed, Mar 16, 2011 at 12:47 PM, Antoine Sabot-Durand 
>>>>> <[email protected]> wrote:
>>>>> Hi all,
>>>>> 
>>>>> I try to shorten my Expression language code and don't want to create 
>>>>> delegate methods in my controller to access  propertir of a business 
>>>>> component.
>>>>> 
>>>>> I didn't found something like @Out. Does it exists ?
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Antoine
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> seam-dev mailing list
>>>>> [email protected]
>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> seam-dev mailing list
>>> [email protected]
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Dan Allen
>>> Principal Software Engineer, Red Hat | Author of Seam in Action
>>> Registered Linux User #231597
>>> 
>>> http://www.google.com/profiles/dan.j.allen#about
>>> http://mojavelinux.com
>>> http://mojavelinux.com/seaminaction
>>> 
>> 
> 
> _______________________________________________
> seam-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev

Reply via email to