[weld-dev] spec question on 3.5 Resource Beans

[Mark Struberg]

Heh thanks Dan, I'm actually old enough to not take such aggro answers too personal, because everyone may have had a hard day ;) (But maybe the WebSphere programmers do take it personal? ;)

Serious, I bet Gavin has a very clear picture in _his_ mind of how it should work in the end. But not all of those details are covered in the spec. There is for example not only one way how an EJB container and a CDI container could interact/integrate with each other, so any behaviour not explicitly written down in our spec is simply undetermined. Or you do it the JSF way: if the spec doesn't make things clear, the RI is the source of truth. But I'd prefer to have it the spec.

To the facts:

> > There is maybe a very subtle (and imho inconsistent)
> detail. In section 7.3.6 is stated that such a
> > 'Resource Bean' producer field has to wrap (==proxy?)
> those EE resources even if they are
> > @Dependent scoped. This is different to a standard
> producer field, since @Dependent scoped
> > beans usually don't get proxied at all.
> 
> It doesn't say anything of the sort.
> 
> The internal implementation of the container *might* do
> something like
> that, but that would never be visible to the application.

>From the spec:
"When the create() method of a Bean object that represents a resource is called, the container creates and returns a container-
specific internal reference to the Java EE component environment resource, entity manager, entity manager factory,
remote EJB instance or web service reference. This reference is not directly exposed to the application."

Sounds like wrapping to me. Is it only a serialization issue, or do we need to take care of other facts as well? 


> Accessing a resource using EL is a really bad idea.

For _some_ resources it's a bad idea, but there are lot valid cases too. Having a configuration setting done via JNDI available in EL might be really handy.


> So is using @Named as a qualifier.

Gavin, YOU don't like it, but others might. And for integrating with legacy systems this might be really helpful.
At least neither the JSR-330 nor JSR-299 spec forbid it generally afaik. 
We would just have to do a lot code to forbid mechanisms which are most times technically valid. It's 'not a good idea' (in some cases) is simply not a scientific argument. There are pros and cons, but at the end it's still a tool one is free to use or not. We should not encourage that style though.


txs and LieGrue,
strub

--- Dan Allen <dan.j.allen at gmail.com> schrieb am Do, 18.2.2010:

> Von: Dan Allen <dan.j.allen at gmail.com>
> Betreff: Re: [weld-dev] spec question on 3.5 Resource Beans
> An: "Mark Struberg" <struberg at yahoo.de>
> CC: weld-dev at lists.jboss.org
> Datum: Donnerstag, 18. Februar, 2010 07:40 Uhr
> So it really comes down to be
> one question. Should the following line work in a CDI
> managed bean, yes or no?
> 
> 
> private
> @PersistenceContext(unitName="myUnit")
> EntityManager myUnitEm;
> 
> 
> 
> I talked to a lot of people before writing my mail,
> but noone could answer this simple question, that's why
> I asked for clarification.
> 
> Don't apologize or be intimidated to ask
> for a clarification. That's one of the main reasons we
> communicate.
> 
> -Dan
> -- 
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in
> Action
> Registered Linux User #231597
> 
> http://mojavelinux.com
> 
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
> 
> 

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com