Bug 90207 - Provide a method for locating DatabaseConnection's for a Datasource
Provide a method for locating DatabaseConnection's for a Datasource
Status: NEW
Product: serverplugins
Classification: Unclassified
Component: Infrastructure
6.x
All All
: P2 (vote)
: TBD
Assigned To: Andrei Badea
issues@serverplugins
http://wiki.netbeans.org/wiki/view/VW...
: API
Depends on:
Blocks: 98376
  Show dependency treegraph
 
Reported: 2006-11-28 17:03 UTC by Andrei Badea
Modified: 2007-09-17 20:31 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
diff file of proposed changes to j2ee utilities projext.xml (929 bytes, application/octet-stream)
2007-02-16 08:22 UTC, John Baker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Badea 2006-11-28 17:03:54 UTC
As described in 

http://wiki.netbeans.org/wiki/view/VWPDataSourceIntegration

there should be a method in j2eeserver allowing a client to locate
DatabaseConnection's for a given Datasource.
Comment 1 John Baker 2007-02-16 08:22:12 UTC
Created attachment 38596 [details]
diff file of proposed changes to j2ee utilities projext.xml
Comment 2 John Baker 2007-02-16 08:22:46 UTC
To access DatasourceHelper.findDatabaseConnections(...,...), I think making
visualweb's dataconnectivity packages as friends is sufficient.
I'm attaching a diff of project.xml 

Please let me know if this sounds ok.
Comment 3 Andrei Badea 2007-02-19 14:00:21 UTC
It can be done as a temporary solution for M8, but that method will need to be
moved to j2eeserver in 6.0. I don't think adding those dependencies needs an API
review, so unless anyone on CC disagrees you can just commit. Please don't close
the issue, as it still needs to be addressed properly later.
Comment 4 John Baker 2007-02-20 07:31:56 UTC
If no objection, I'll make the change for M8, as indicated by the attached diff.

After M8, please suggest which class to move findDatabaseConnections(...) to
Comment 5 John Baker 2007-03-28 21:40:47 UTC
Should DatasourceHelper still be moved to another package?
If so, where is a good place?
Comment 6 Andrei Badea 2007-03-28 22:54:49 UTC
Yes, I believe it should be moved somewhere else. j2eeserver is my best (well,
only) candidate.
Comment 7 Sherold Dev 2007-03-28 23:31:17 UTC
FYI, moving DatasourceHelper to j2eeserver is part of the API change which is
tracked by issue 89439. Setting the dependency...
Comment 8 John Baker 2007-04-28 07:24:43 UTC
89439 90209 are not dependencies, removing them from dependency list
Comment 9 John Baker 2007-05-02 00:33:45 UTC
Does the API still need to be moved to a new module and package ?
Comment 10 Andrei Badea 2007-05-02 09:53:21 UTC
Yes. It shouldn't stay in j2ee/utilities because I want to avoid adding many
dependencies to that module.
Comment 11 John Baker 2007-05-02 17:49:38 UTC
ok,  which package of j2eeserver is an appropriate place to move
DatasourceHelper, org.netbeans.modules.j2ee.deployment.common.api  ?


Comment 12 Sherold Dev 2007-05-03 08:55:46 UTC
No need to rush with this. The new location for this class will most likely be
the org.netbeans.modules.j2ee.deployment.common.api package, but the method
signature 
change, which was discussed in the issue 89439, needs to be done before or at
the same time when moving the class to j2eeserver.
Comment 13 Andrei Badea 2007-05-03 20:25:09 UTC
John, is this issue blocking you? Do you need the tryRegister parameter that was
discussed in issue 89439?
Comment 14 John Baker 2007-05-03 21:18:14 UTC
This is not blocking me.  I should remove my dependency, I have implemented a
similar way to find the connections, since I didn't want to wait for the
decision on where this api is to be moved.  So, I'm just following up since
issue 90207 hadn't been resolved.
Comment 15 Andrei Badea 2007-05-03 22:07:46 UTC
If that's the case then I gues you can just remove your dependency, but please
leave the issue opened. We need to improve this method, even if not sure if for
M10. No one has time to work on it now I think.
Comment 16 Jiri Prox 2007-09-17 20:31:04 UTC
Obsolete milestone, please reevaluate


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