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 64010 - Under Server Resource node, delete JDBC resource fail to unregister the resource
Summary: Under Server Resource node, delete JDBC resource fail to unregister the resource
Status: RESOLVED INVALID
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 8 (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@serverplugins
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-09 21:53 UTC by judytang
Modified: 2005-09-12 08:02 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description judytang 2005-09-09 21:53:28 UTC 
I am using NetBeans 5 (9/7) build, and Appserver 8.1 PE UR2 for testing.

(1) Create a project
(2) At EJB module node, click on Server Resources node -> New -> File ->
Sun Resources - > JDBC Resources
(3) Create JDBC resources select create new JDBC connection pool option,
it creats JDBC resource and pool. 
(4) click on JDBC resource -> register -> to register the jdbc resource 
(5) go to runtime tab, refresh, saw the jdbc resource got registed
(6) click on JDBC resource -> delete -> deletes the resource
(7) go to runtime tab, refresh, still saw the jdbc resource, should the 
resource be unregisted through the delete function ?
Comment 1 Vince Kraemer 2005-09-10 14:39:58 UTC 
no. the resource definition is just that; a definition.

If a project has a resource definition at deployment time, the resource is
registered.  If the user registers the resource the resource is created, on the
server, based on that definition.  The user is free to delete the resource
definition from the file system.

The parallel case is a jar file.  The user is free to delete a jar file, that
has been deployed without fear of disabling the deployed EJB contained in it...