The service works if you
1. Comment out the resource-ref element in the web.xml DD
<resource-ref>
<res-ref-name>UserTransaction</res-ref-name>
<res-type>javax.transaction.UserTransaction</res-type>
<res-auth>Container</res-auth>
</resource-ref>

2. Change the PersistenceService class so that it explicitly calls javax.transaction.UserTransaction. In other words, replace 
   this.utx = (UserTransaction) new  
           InitialContext().lookup("java:comp/UserTransaction");
with
   this.utx = (UserTransaction) new 
           InitialContext().lookup("javax.transaction.UserTransaction");

The workaround for this issue triggers an analogous exception when the service is deployed to GF 3.1 On GF 3.1, testing a RESTful WS with the workaround throws:
java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'javax.transaction.UserTransaction' in SerialContext  [Root exception is javax.naming.NameNotFoundException: javax.transaction.UserTransaction not found]

-> P2.

EE specification (from version 5 at least) mandates "java:comp/UserTransaction", for example see "EE.6.7" in EE 5 spec ("Java Transaction API (JTA) 1.1 Requirements"):

"JTA defines the UserTransaction interface that is used by applications to start, and commit or abort transactions. Application components get a UserTransaction object through a JNDI lookup using the name java:comp/UserTransaction or by requesting injection of a UserTransaction object."

(In reply to comment #1)
> The service works if you
> 1. Comment out the resource-ref element in the web.xml DD
> <resource-ref>
> <res-ref-name>UserTransaction</res-ref-name>
> <res-type>javax.transaction.UserTransaction</res-type>
> <res-auth>Container</res-auth>
> </resource-ref>

I would believe that this should not be needed in any case - even in EE 5 apps. If UserTransaction can be injected then it can be also found in JNDI without any entry in web.xml.

> 2. Change the PersistenceService class so that it explicitly calls
> javax.transaction.UserTransaction. In other words, replace 
>    this.utx = (UserTransaction) new  
>            InitialContext().lookup("java:comp/UserTransaction");
> with
>    this.utx = (UserTransaction) new 
>            InitialContext().lookup("javax.transaction.UserTransaction");

"javax.transaction.UserTransaction" sounds like implementation specific name used by Weblogic. Do not use it.

If this does not really work then we should consult Weblogic team.

There is no information from WebLogic about this problem.
According to David's comment JNDI name in the generated source code conform with 
Java EE specification.

But WebLogic wants another JNDI name. So the option could be different JNDI names
respectively target J2EE server. But it is bad approach because user could 
change target J2EE server after code is already generated. 

So we still need to consult with WL developers about this issue. Probably this 
is the problem of WL runtime.

> According to David's comment JNDI name in the generated source code conform
> with Java EE specification.

I think JNDI names were standardized in Java EE 6; prior to that, they were server-specific.

> So the option could be different JNDI names
> respectively target J2EE server. But it is bad approach because user could 
> change target J2EE server after code is already generated. 

Yes, changing the server will break the code, but switching the server does not work very reliably anyway - I don't think this is a big issue, we can just say this is unsupported.

> Probably this is the problem of WL runtime.

I would not call this a problem - just different conventions.

(In reply to comment #6)
> > According to David's comment JNDI name in the generated source code conform
> > with Java EE specification.
> 
> I think JNDI names were standardized in Java EE 6; prior to that, they were
> server-specific.

See my comment #4 - it is mandated since EE 5.

I'm able to reproduce this issue with WL both 10.3.3 and 10.3.4 versions.

I'm able to deploy war after commenting out UserTransaction "resource-ref" 
element in web.xml 

But access to webservice lead to runtime exception ( see attached stacktrace ).
I have no idea what is the reason.

Created attachment 102904 [details]
stacktrace

Please note that Exception has been thrown on lines :
      utx.begin();
  --->em.joinTransaction();

em.joinTransaction() is on line 70 of PersistenceService :
at service.PersistenceService.beginTx(PersistenceService.java:70)

It means that utx which is instance of UserTransaction is no null and was 
successfully found in the context via lookup.

So the problem of exception in my case is entity manager and it relates 
to jdbc drivers and datasurce problems.

How about if you change the default persistence provider to TopLink in WebLogic's admin console? Will it help?

I changed the WL default persistence provider to TopLink before even I first tried this out and reported the bug.

Last exception says about missed properties for openjpa, it may be an issue with pu creation if this property is required.

The same thing with TopLink provider.
Other exception with datasource jndi name resolution problem on the line 70.
Again user transaction access has no problem .

Jeff, could you please confirm/disclaim that commenting out of "resource-ref"
element for UserTransaction doesn't solve the problem?
Is it really necessarily to change jndi name to get working project on WL ?

It could be possible that the problem is only "resource-ref" element in web.xml
file which is really not needed by David's comment.

If there is still an error could you please describe this error with more details.
This error shouldn't at deployment time because I'm able to deploy 
project on WL without any problem without ""resource-ref" element.

I can't check it by myself because any JPA provider generates error on 
entity manager access ( as mentioned in my previous comments ).

Commenting out resource-ref works, in so far as it allows the application to be deployed.
The NB RESTful service tester does not produce results for the deployed service. I do not know what the problem is or whether the tester should work. WebLogic takes up all the memory of my computer and it is very difficult for me to experiment very much with the deployed service.

Created attachment 103016 [details]
Error in the server log on service access

I am getting the attached error in the server log after:
- changing JPA provider to EclipseLink
- commenting out the resource-ref element in web.xml
- deploying (deployment itself succeeds)
- accessing the resource from the Web service test UI

Looks related to JPA 2.0? Why is it looking for the JPA canonical metamodel, which is not available in JPA 1.0?

I remember the issue with accessing canonical metamodel but itt was fixed. It may be another use-case. Also this exception looks different from all above.

It was http://netbeans.org/bugzilla/show_bug.cgi?id=189626 if I remember right.

I am looking at that issue, and now I am thinking - could this be related to deploy on save? I was able to make the whole scenario work using the following steps:

1. Create Java EE web project with WebLogic target
2. Turn off deploy on save on this project
3. Create entity classes
4. Create RESTful web service from entity classes
5. Remove the <resource-ref> element generated in web.xml
6. Apply workaround for bug 192126 by manually editing setup/datasource-1-jdbc.xml
7. Deploy the application
8. Use Test RESTful Web Services action
9. When you get the data, it works well

Thank you very much Petr!

Probably you have found the issue why I haven't been able to deploy datasource 
to WL.

So resolution for this issue :
do not add "<resource-ref>" for UserTransaction into deployment descriptor.
( this is not required by Java EE specification either ).

All other problems with project deployment which are discovered here :
1) issue #192126 
2) probably deploy on save feature ( which could a consequence of first item ).
And they doesn't relate to WS functionality.

changeset:   182682:e6370ad30971
user:        Denis Anisimov <ads@netbeans.org>
date:        Fri Nov 19 12:08:38 2010 +0300
summary:     Fix for BZ#190237 -  RESTful WS from entity classes do not deploy on WebLogic

So do we also need a separate bug for the Deploy on Save problem?

>So do we also need a separate bug for the Deploy on Save problem?
I suppose so. If it really exist. 
I just want to say that switch off of deploy on save is required for 
datasource file correction as I understand.
Probably originally correct datasource xml file will allows to work 
deploy on save correctly.
I think Petr Hejl is owner of this functionality. May be mention of the problem 
with deploy on save could be just added into issue #192126 ( with reference to
current bug ).

Integrated into 'main-golden', will be available in build *201011200001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e6370ad30971
User: Denis Anisimov <ads@netbeans.org>
Log: Fix for BZ#190237 -  RESTful WS from entity classes do not deploy on WebLogic

I filed a separate bug 192285 for the Deploy on Save (internal parsing infrastructure) problem.

Sorry, fixed ages ago

Now you can solve here for your latest unscrambler scrabble word finder    https://scrabblewordfinder.me . This is main thing where we can find the simple ways for the clear lots fo concepts.