Could you double check please that persist() method uses UserTransaction when necessary. Have a look here for more details: http://books.google.com/books?id=j84hdeHH2PYC&lpg=PA56&pg=PA55#v=onepage&q&f=false

may be similar to issue 185682

I see there are implementations of InjectionTargetQueryImplementation registred via lookup for Servlet (WebInjectiontargetImplementation), WebService and WebServiceProvider (WSInjectiontargetQueryImplementation), for JSF, for EJB etc.

This one issue may be 3 separate issues and isn't pure persistence issue, it's likely @ManagedBean is a problem of JSFInjectionTargetQueryImplementation realization (if proper ManagedBean is used), @Path may be a problem in WSInjectiontargetQueryImplementation and cdi @Named injection targets may not be handled by ide at all.
David, do you have any ideas?

regarding usage of @ManagedBean, for javax.faces.bean.ManagedBean persistencecontext is used.

also org.netbeans.modules.j2ee.common.queries.api.InjectionTargetQuery::isInjectionTarget
is used not only in persistence, 
as example: affect Send JMS Message generation, got jndi lokup in case of unmanaged(unhandled) classes(for example @Named).

Moved to CDI component for additional evaluation.

InjectionTargetQueryImplementation interface has no relation to this bug.
This interface is used to get answer on question : is it possible to generate
injection ( no matter what type of injection : via complicated jndi access or 
via CDI ).
You are right about absence implementation of InjectionTargetQueryImplementation 
interface related to class annotated with @Named.
But this is absolutely separated bug ( if it is really bug ).

This bug is about WRONG source code generation strategy which is used for
EntityManager .
InjectionTargetQueryImplementation  interface is not used when such strategy 
is chosen. The question in this bug is exactly generation strategy.

To fix this bug : implement correct generation strategy .
File new bug for CDI @Named object related to InjectionTargetQueryImplementation
if it exists after fixing strategy.

Can you also comment?
"also
org.netbeans.modules.j2ee.common.queries.api.InjectionTargetQuery::isInjectionTarget
is used not only in persistence, 
as example: affect Send JMS Message generation, got jndi lokup in case of
unmanaged(unhandled) classes(for example @Named).
"

The issue is only dependent on wrong return value from org.netbeans.modules.j2ee.common.queries.api.InjectionTargetQuery::isInjectionTarg and have no other dependencies.
There is two generation strategies, use annotations or jndi and both are implemented, the issue isn't about new strategy implementation but about wrong one usage.

in real more then two, but wonder what one more "correct generation strategy" should be created for the case which wrongly reported as not injectable but is injectable :)

I would agree that we should first fix the implementation of InjectionTargetQuery and see what happens and whether it fixes this.

Sergey, 'Insert Code -> Use Entity Manager' action must distinguish three different situations:

#1) class is an EJB

#2) class is a container managed object but does not fit category #1 (ie. it is managed bean, named bean, servlet, ...)

#3) class does not fit previous two categories (ie. it is POJO)

Code generated in these situations will differ:

re #1) - EntityManager is injected and code generated assumes that transactions are managed by container (ie. UserTransaction is not injected and used)

re #2) - EntityManager and UserTransaction are injected and code generated must use UserTransaction to start and commit transaction if persisting some entities.

re #3) - similar as #2 but JNDI lookup must be used instead of injection of EntityManager and UserTransaction

If this works on your side could you please test it on different managed and non-managed classes and summarize for which it works and for which it does not. The failed ones will be result of missing or incorrectly implemented InjectionTargetQueryImplementation and they likely will have to be resolved by somebody else then you. I had a quick look at JSFInjectionTargetQueryImplementation and its impl seems OK.

(Please double check that what I'm saying make sense - I have not looked into the code and I'm just saying how I think it should work in theory. Reality is always little bit trickier. Thx!)

ok, initially isue state @Named is different from EJB, Servlet, SOAP web service,
if something different should be generated for case '2' it looks like another issue for me.  But anyway '2' should be properly reposted as injection target first.

also why 1 and 2 should be different? 
and one more, i'm not sure  there is api to separate ejb injectable target from others injectable targets bt I'm not aware.

> also why 1 and 2 should be different?

Because EJB does transaction management for you, so every method is automatically treated as a transaction. For non-EJB cases, you have do do explicit transaction management in the method body.

Servlet falls into #2, and it is true that in this case, injection is correctly used to declare the EM, but no transaction code is generated - looks like another problem.

> and one more, i'm not sure  there is api to separate ejb injectable target from
> others injectable targets bt I'm not aware.

I am not sure either.

So there are two issues - injectable case(wrong false) and no transaction for Servlets etc in my opinion last one should be filed as separate issue.

http://netbeans.org/bugzilla/show_bug.cgi?id=189559 for transaction code missed

missed next
>JSFInjectionTargetQueryImplementation and its impl seems OK.
As I understand it's ManagedBean only related, I wasn't able to reproduce the issue with managed bean also.

(In reply to comment #14)
> So there are two issues - injectable case(wrong false) and no transaction for
> Servlets etc in my opinion last one should be filed as separate issue.

OK, for injectable case could you please file test sine scenarios and file separate issues for different modules as well? And make them blocking this issue? Thanks. This issue could be then closed as WORKSFORME or RESOLVED.

Your other question about EJBs detection I answered directly in issue 189559.

sorry for typos. I meant to say "...could you please test different scenarios and file separate issues..."

For list of classes supporting injection have a look at Java EE 6 spec Table EE.5-1 on page 67.

I'm able to reproduce with managed bean in ejb module and can't reproduce in web module, this case is likely proper generation strategy selection issue rather then injectable InjectionTargetQueryImplementation issue. will fix it under this issue, will file separate one for @Named, need  to test Path also.

issue  189579 is for @Named

For @Path there is the same as for @ManagedBean, wrong strategy in ejb module and correct one in web module, will address in this issue. Please correct me if the issue is reproducible in web also. Finally only @Named seems to be out of persistence scope :) sorry for mixing

What about other objects? EE spec mentions Servlet Filters, Event Listeners, etc. Looking at WebInjectionTargetQueryImplementation it seems to handle only Servlets. It is not high priority issue but it would be good to do this right.

Integrated into 'main-golden', will be available in build *201008180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/2f4abda5a75e
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: fix #188821 api from available library is used only if library is added

It may be good to file issues or add some more requests to '@Named' issue for other elements. But 'named' may be more important as it's created if I create jsf managed bean with nb wizard.

Now I'm not sure how @Path and @ManagedBean was created in ejb module, as there is no REST from entity for ejb, but all works for me in web module, ad what to do if these targets are manually created. May need more investigation.
Petr, Can you verify?
I see initial report is with web project 'Create a Java EE 6 web project with CDI and JSF enabled', can you reproduce the issue?

(In reply to comment #25)
> It may be good to file issues 

Just file a new issue for anything you find.

> or add some more requests to '@Named' issue for
> other elements. But 'named' may be more important as it's created if I create
> jsf managed bean with nb wizard.

@Named is more important than other cases.

(In reply to comment #26)
> Now I'm not sure how @Path and @ManagedBean was created in ejb module

@ManagedBean does not make any sense in EJB module. Sounds like copy&paste to me.

Or perhaps Alexandr could help testing different scenarios and file issues. But as I said it P3- and almost P4 so give it lower priority guys. Thx.

Petr, can you conform if ou can reproduce any of initial issues?
I see no jndi for 
- CDI @Named object, or
- @ManagedBean object
- REST service annotated with @Path
in javaee6 ant web project with cdi support on.

Created attachment 101700 [details]
Project which reproduces this for @Path

Works better now for me. I can no longer reproduce this for:

- @javax.inject.Named
- @javax.faces.bean.ManagedBean

But I can still reproduce for:
- @javax.annotation.ManagedBean;
- @javax.ws.rs.Path

I am attaching a project which reproduces this for @Path.

> http://download.oracle.com/javaee/6/api/javax/annotation/ManagedBean.html

@javax.annotation.ManagedBean is something else then @javax.faces.bean.ManagedBean. @javax.annotation.ManagedBean is a way how to mark any POJO in EE 6 app as managed without the dependency on JSF. Consequently it supports only subset of JSF's ManagedBean behaviours - for example scopes (session, request, ...) are not supported because scopes make sense only in Web App context. I think it is just confusing in the end. Not to mention that CDI adds yet another way to mark POJO as managed.

@Path should work but that depends on whether WS support implemented properly InjectionTargetQueryImplementation.

I have a problem with attached web project.
Neither persistence code nor editor don't see javax.persistence package after resolve missing server action, I have to restart nb first. But it's separate issue.
Not sure what is javax.annotation.ManagedBean, Petr, have you tried if manually created persistence code with annotations will work nice withing @javax.annotation.ManagedBean?

regarding @Path, in this case InjectionTargetQuery.isInjectionTarget() return false and persistence code is generated accordingly. As I see with empty web project if injection is enabled there is beans.xml and if not there is no beans.xml. 
Should @Path be injectable in this case?

missed in comment above: there is no beans.xml in attached sample.

With a bit more investigation. cdi is recognized for @Path services generated from entities because of @Stateless. Simple @Path is not recognixed and I wonder if it should be reconized, found next thread for @Path: http://forums.java.net/jive/message.jspa?messageID=382037

(In reply to comment #35)
> With a bit more investigation. cdi is recognized for @Path services generated
> from entities because of @Stateless. Simple @Path is not recognixed and I
> wonder if it should be reconized, found next thread for @Path:
> http://forums.java.net/jive/message.jspa?messageID=382037

I'm not sure I understand your concerns Sergey, but I would expect that any class annotated by @Path is managed. At least that's how EE spec specifies it. Whether injection model of class annotated by @Path annotation is managed by CDI or by Jersey is implementation detail I would say. CCing Milan.

> Simple @Path is not recognixed and I
> wonder if it should be reconized, found next thread for @Path:
> http://forums.java.net/jive/message.jspa?messageID=382037

Right,
The simple @javax.ws.rs.Path (with no another annotations, like @Stateless) is not managed. So you cannot inject EJB or EntityManager object.

I'll check REST guys what are the plans for next.

thanks, so the only remaining issue is javax.annotation.ManagedBean if it's an issue(haven't tried to create application manually yet), but I'm not sure who is responsible for corresponding area, is it javaee/cdi issue?

This is the answer from Paul Sandoz, Jersey REST archirect :

===============================
A root resource class needs to be annotated with an EE 6 annotation to become a managed bean and therefore have injection of EE artifacts.

Such an annotation can be @ManagedBean, @Stateless or @Singleton for EJBs or @RequestScoped for CDI.

  https://jsr311.dev.java.net/nonav/releases/1.1/spec/spec3.html#x3-630006.2

Each has consequences on on the life-cycle and injection support.


> Are there any plans to support injections on simple root resources for the future ?
>
> See also the discussion in :
> http://netbeans.org/bugzilla/show_bug.cgi?id=188821
>

The use of @ManagedBean probably gets close to this. The EE 6 container constructs and Jersey managed the life-cycle, but the restriction here is that constructor injection of JAX-RS artifacts are not supported

There are different restrictions when one uses CDI because the JAX-RS model and CDI model are slightly different.

It can be summarized as thus: JAX-RS specifies a programming model and if by default components were considered managed beans would break code. Developers need to opt in.

Paul.
=============================

Milan, thanks for clarification. 

(In reply to comment #38)
> the only remaining issue is javax.annotation.ManagedBean if it's an
> issue(haven't tried to create application manually yet), but I'm not sure who
> is responsible for corresponding area, is it javaee/cdi issue?

it's not CDI issue. We do not really have a corresponding module/owner for it. What about j2ee.common module?  If nobody disagree on j2ee.common then could you Sergey imlement InjectionTargetQuery for javax.annotation.ManagedBean there please?

ok, it shouldn't be hard if know it should be in j2ee.common

http://hg.netbeans.org/web-main/rev/ef341b64ddbd
javax.annotation.ManagedBean is cnsidered as injection target in ee6 web/ejb environment now.

David, have you tried to use javax.annotation.ManagedBean?
I tried to replace faced managed bean with javax.annotation.ManagedBean and got nothing good, so not sure I understand where it can be used, should it be used in full ee6 profile only?

jsr250 for common annotations  http://jcp.org/aboutJava/communityprocess/mrel/jsr250/index.html

(In reply to comment #42)
> http://hg.netbeans.org/web-main/rev/ef341b64ddbd
> javax.annotation.ManagedBean is cnsidered as injection target in ee6 web/ejb
> environment now.
> 
> David, have you tried to use javax.annotation.ManagedBean?


Works fine for me:

@javax.annotation.ManagedBean(value="moje")
public class DoSomething {

    @PersistenceUnit
    private EntityManagerFactory fact;

    public String hey() {
        return new AddressJpaController(fact).findAddressEntities().toString();
    }
}

and for example in servlet ask container to create instance of DoSomething by 

((DoSomething)new InitialContext().lookup("java:module/moje")).hey();

I also filed issue 190051 for separate subproblem (Use EntityManager generates wrong JNDI code)

Integrated into 'main-golden', will be available in build *201009010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/ef341b64ddbd
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: fix #188821 - javax.annotation.ManagedBean is injection target now for ee6

thanks for the sample, in my opinion this one issue can be closed now.