This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 96777

Summary: Provide a way to create a new persistence unit in J2SE project
Product: javaee Reporter: Jan Stola <jstola>
Component: PersistenceAssignee: Erno Mononen <emononen>
Status: RESOLVED FIXED    
Severity: blocker CC: abadea, arseniy, pjiricka
Priority: P1    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: TASK Exception Reporter:
Bug Depends on:    
Bug Blocks: 89495, 91757    

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).