Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 96777 - Provide a way to create a new persistence unit in J2SE project
Provide a way to create a new persistence unit in J2SE project
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: Persistence
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Erno Mononen
issues@javaee
:
Depends on:
Blocks: 89495 91757
  Show dependency treegraph
 
Reported: 2007-02-28 13:40 UTC by Jan Stola
Modified: 2007-03-16 13:53 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Stola 2007-02-28 13:40:06 UTC
Use case: user DnD DB table onto GUI form in order to display DB data in this 
form.

When there isn't a persistence unit corresponding to the DB connection of the 
dragged DB table then we have to create a new persistence unit for this 
connection. Please, provide us an API to achieve that.

So far, we were using ProviderUtil.buildPersistenceUnit() and 
ProviderUtil.addPersistenceUnit() for that purpose. If these APIs are going to 
survive in NB 6.0 then it is sufficient to add us 
(org.netbeans.modules.form.j2ee) as friends to j2ee\persistence module.
Comment 1 Andrei Badea 2007-03-01 12:15:00 UTC
Note that based on what I see in ProviderUtil.addPersistenceUnit() the
persistence.xml file is created if it doesn't exist. So do you need to explicity
request persistence.xml to be created if you just use this method?
Comment 2 Jan Stola 2007-03-01 13:27:49 UTC
The current implementation (e.g. the one that was in NB 5.5) of 
addPersistenceUnit() works for us. It is fine for us if it remains as it is.
Comment 3 Petr Jiricka 2007-03-05 11:16:02 UTC
I see that ProviderUtil.buildPersistenceUnit() and
ProviderUtil.addPersistenceUnit() still exist in the trunk, and Matisse is a
friend of the persistence module. So if there are no plans to change this, we
are done, right? Are there plans to do changes in this area in 6.0?
Comment 4 Erno Mononen 2007-03-05 12:48:44 UTC
I don't plan to remove those methods, but I'd like to make some clean up of the 
ProviderUtil as now it is a bit messy combination of various utility methods of 
which many shouldn't be exposed through the friend API. So I'd leave this one 
open still and close once that is done. I don't want to make any major changes 
though, just some minor refactorings.
Comment 5 Andrei Badea 2007-03-05 13:25:19 UTC
If you have the time, consider removing the assumption that there is a single
persistence.xml file per project (see ProviderUtil.getPUDataObject(Project) and
similar). I'm not comfortable with exposing this bug to clients outside the
enterprise cluster (even if they don't plan to use it right now). And I'm afraid
that VWP will want to do something with JPA soon and this will get even messier
and harder to fix. It is also needed for the JPA support in freeform projects.

In the ideal case the method should be

ProviderUtil.getPUDataObject(FileObject)

where the FileObject is a persistence client (e.g., a servlet in a web project).
Note you already have a method with this signature, where the FileObject has a
different meaning.

This could also require modifying PersistenceLocation to allow for a FileObject
parameter with similar semantics. That could be postponed if necessary, since it
affects mainly implementors, not clients.
Comment 6 Erno Mononen 2007-03-16 13:53:51 UTC
The methods required here are still present and the ProviderUtil class has been 
cleaned up, so I'm closing this. I filed a new defect for the case Andrei  
mentioned (issue 98085). 


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo