Bug 56861

Created attachment 21059 [details]
stack trace

It is weird that the IDE attempts to update the config files during deployment.
These files should be created much sooner than that, not during deployment.
Assigning to Stepan.

The current deployment activity would need to have ConfigurationStorage to
either write deployment plan (jsr-88 deploy) or to get WebContext value or get
the DeployableObject for incrementall deployment calls.  This we why the config
graph is get built.

The stack trace seems to tell that while loading the config bean graph, the
plugin implementation of ensureResourceDefined is called.  This should not try
to create the resource because it should have been already created during 'Use
Database' action in the previous IDE session.  IMO, this is plugin issue: 
plugin should not try to acquire the connection during ensureResourceDefined(). 

Side issue: it is also interesting to know why the dbexplorer using context
class loader could not see class in its own modules.

This is really a P1.  Users could not deploy ejbjar with CMP's after restart the
IDE.  Per my previous assessment, assign to Ludo for further assessment for a
fix in plugin.

The ClassNotFoundException is part of the filtering of Ant execution classpath
to be free of IDE classloaders.

Rajeshwar, start the evaluation.

The CNF might be because the AS plugin depends on dbschema module, but not on
dbexplorer module.
We might need to add:
org.netbeans.modules.db/1 = 1.1

in our manifest for dependant modules...
Rajeshwar, please try.

Too bad, we already have this dependancy...

Nam,
can you explain this code in db explorer?
It seems that Studio is defining a class name via a bundle, and the defautl nb
impls is nop, but where is the studio real impl there?

I will remove this hack for now. We need to go to ARC review for customization
this, as this trick is not defined anywhere.

removing the hack will fix the bug which is a must fix P3 fior 4.1.
I could create a default impl of this interface in case of CNF error.

But: 
Now it will not fix hidden requirements for the JSE team.

OpenConnection is a mechanism for JSE to do extra work when open and close a
connection. When merge back into trunk, I don't like this hack of defining
service through Bundle.properties.  This practice mainly used for branding
practice, and I guess the usage here for the Sun JDBC drivers is justified by
saying this is also "kind of" branding.  
The CNFE I guess is because the restriction of Ant execution classloader.  So we
have options:
(1) avoid getting db connection if resource already defined in this test case.
(2) redefine the mechanism using service lookup pattern for OpenConnection.
Options #2 is the right fix, but isnt' it too late for API change.  Or, could we
say this dbexplorer dependency is implementation, so it is not API yet at this time.

I am not sure how this would work with the new nb4.1 and buzz...
So you gona brand the db explorer module?
Classloader between modules changed a lot between 3.6 and 4.1

Yes.  We currently have org/netbeans/modules/db/resources/Bundle_jse.properties:
CLASS_open_connection=com.sun.tools.dbdrivers.JseOpenConnection

This has been done and tested to work by the SPD team.  The classloader changed,
so we had to change to use context classloader instead of current classloader.

so this way of adressing the issue does not work...as depending on nb3.6 or nb4.1
you need a different classloader....
or can you try again in nb4.1 with the current classloader isntead of contextcl?

I am sure trying current classloader after CNFE from context classloader will
work for NB4.1 but still not work for JSE.  I will try the service lookup
pattern for OpenConnection tonight.  

On the other hand, we also need to make sure ensureResourceDefined is not
creating new resource definition when one already defined as indicated by this
issue test case and stack trace.

I could not reproduce this anyway so far.
Nam, can you? 

I can see the exception but with binary from build 3/17.  The test case last
step should read "open ide, deploy the ejbmodule project. Will see exception". 
Could not work on latest code because of issue 56968

I can aslo see the exception and I do not see issue 56968

What is the plan of action? service lookup? Could we temporaly remove the
exception by choosing the correct classloader, or can you have a fix by tonight?

I am working on this tonight.  I will try the current classloader if the context
classloader failed.  I will test against JSE.  If not work, I will try service
lookup. 

Temporary work-around.  Still need to fix for JSE to work.

Checking in DatabaseConnection.java;
/cvs/db/src/org/netbeans/modules/db/explorer/DatabaseConnection.java,v  <-- 
DatabaseConnection.java
new revision: 1.33; previous revision: 1.32

Created attachment 21128 [details]
Fix using service lookup

The attached patch replace "branding open connection service" with service
lookup.  This patch work for this test case in both NB4.1 and JSE.  I am doing a
full clean build and will check in by tomorrow morning PST.

Checking in src/org/netbeans/modules/db/explorer/OpenConnectionInterface.java;
/cvs/db/src/org/netbeans/modules/db/explorer/OpenConnectionInterface.java,v  <--
 OpenConnectionInterface.java
new revision: 1.3; previous revision: 1.2
done
Checking in src/org/netbeans/modules/db/explorer/OpenConnection.java;
/cvs/db/src/org/netbeans/modules/db/explorer/OpenConnection.java,v  <-- 
OpenConnection.java
new revision: 1.3; previous revision: 1.2
done
Checking in src/org/netbeans/modules/db/explorer/DatabaseConnection.java;
/cvs/db/src/org/netbeans/modules/db/explorer/DatabaseConnection.java,v  <-- 
DatabaseConnection.java
new revision: 1.34; previous revision: 1.33
done

I can't reproduce the issue in the latest daily build.