From a discussion with Pavel and Craig:

>>> it is not possible to create a web app using wizards that uses JPA in SE mode.
>>> Here are some comments that I have about using netbeans to code a web app
using JPA
>>> The wizard to generate "Entity classes from Database",  offers two choices.
>>>     a. Use a data source defined with the appserver
>>>     b. Use a captured dbschema
>>>     -I think  we should add a third option that allows to use a database
connection similar to what is allowed
>>>       in a normal java app
>>
>>
>>
>> Why would you want to use the SE approach in an EE module? The only reason I
can think of is if it was a 2.4 web app, but in that case we actually use the SE
approach.
>
>
> Here's what I got from him on this:
> You are correct. That is using SE approach in EE module. Some times it is very
convenient (though not best practice) for a developer to use persistence in se
mode even from within an ee application for following reasons:
> 1. The developer wants to use bunch of persistence classes and (associated
persistence.xml) across web and se app for testing purpose.

It is still possible to create a PU manually in XML editor for special
situations like this (if you want to create a special PU just for testing with a
main class). We do not guide the user to this style for 2 reasons. First, to
reduce complexity of UI. We have initially implemented UI which offered a choice
of either style of PU and we removed it because it was pretty complex and ugly.
Second - more important - to limit the number of choices the novice user has to
make. Persistence.xml is the only configuration file in an otherwise pretty user
friendly API (IMHO) and setup of persistence.xml should be as straightforward as
possible.

Still, if you create an SE style PU manually in xml tab of persistence.xml
editor everything will work. You will even see the new PU in the graphical
editor for persistence.xml. 

> 2. The developer wants to deploy on a non java ee container (tomcat)
Again, for tomcat or any other 2.4 web module (even for Glassfish when using
J2EE 1.4) we do actually generate the SE style of PU. AFAIK this is the only way
to do it in 2.4 web app. So I do not understand this argument.


> 3. It is much more intuitive to associate with use the live connection listed
in runtime tab (as allowed in a java se app) than a data source while developing
an app.
>

I do not know. This is for Bill Shannon or whoever designed the concept of data
sources in J2EE . Creator is aimed at beginner users and uses data sources,
AFAIK. I think NetBeans 5.5 is doing as much as we can to simplify working with
data sources. But I agree that it is an extra layer of indirection that the user
must be aware of and is not always needed.


I would add one more potential advantage to this list ... the EntityTransaction
API is nicer in two respects than the JTA-based use of UserTransaction:

* Unchecked versus checked exceptions.

* Availability of isActive() so you can tell in a finally block whether you need
to bother
 rolling back.  With UserTransaction you need to either use a boolean flag
variable or
 call rollback() anyway, hoping that it won't mess anything up if the commit
succeeded.

> Does it mean that you would generally recommend using entity transaction API
instead of JTA? Cannot you use non JTA transactions even if you define the PU
using a data source - select resource local transaction type instead of JTA?


It wasn't obvious from the tutorial, but this combination does indeed seem to
work.  I'm going to do some more experiments with it, but I'm thinking this will
be the default way that Creator encourages use of JPA for RAD type development
of webapps.