Checking data source definitions for missing JDBC drivers

[jon martin solaas]

Run NB 6.0.1 on Ubuntu Gutsy and java 1.6.0_4, using postgresql 8.2 and
JBOSS 4.2.2 in a simple JPA project. I've defined a datasource and had
Netbeans create an EJB3.0 entity bean for a simple table. Build jar goes
OK, but on running the project or Undeploy and Deploy the entire process
hangs checking data source definitions:

init:
deps-jar:
compile:
library-inclusion-in-archive:
dist:
pre-run-deploy:
Checking data source definitions for missing JDBC drivers...

After this nothing happens.

Also occurs on v. 6.0.
Any ideas would be appreciated.

--
Best Regards,
Jon Martin Solaas

[cowwoc]

I too see this 100% of the time. Can someone from the Netbeans team work with us to fix this?

Gili

jon martin solaas wrote:

Run NB 6.0.1 on Ubuntu Gutsy and java 1.6.0_4, using postgresql 8.2 and
JBOSS 4.2.2 in a simple JPA project. I've defined a datasource and had
Netbeans create an EJB3.0 entity bean for a simple table. Build jar goes
OK, but on running the project or Undeploy and Deploy the entire process
hangs checking data source definitions:

init:
deps-jar:
compile:
library-inclusion-in-archive:
dist:
pre-run-deploy:
Checking data source definitions for missing JDBC drivers...

After this nothing happens.

Also occurs on v. 6.0.
Any ideas would be appreciated.

--
Best Regards,
Jon Martin Solaas

[Wouter van Reeven]

Just to be sure, you DID copy the postgresql jars to the JBoss app server lib
directory, right?


Wouter

On Mon, Jun 16, 2008 at 09:12:06AM -0700, cowwoc wrote:

>
> I too see this 100% of the time. Can someone from the Netbeans team work with
> us to fix this?
>
> Gili
>
>
> jon martin solaas wrote:
> >
> > Run NB 6.0.1 on Ubuntu Gutsy and java 1.6.0_4, using postgresql 8.2 and
> > JBOSS 4.2.2 in a simple JPA project. I've defined a datasource and had
> > Netbeans create an EJB3.0 entity bean for a simple table. Build jar goes
> > OK, but on running the project or Undeploy and Deploy the entire process
> > hangs checking data source definitions:
> >
> > init:
> > deps-jar:
> > compile:
> > library-inclusion-in-archive:
> > dist:
> > pre-run-deploy:
> > Checking data source definitions for missing JDBC drivers...
> >
> > After this nothing happens.
> >
> > Also occurs on v. 6.0.
> > Any ideas would be appreciated.
> >
> > --
> > Best Regards,
> > Jon Martin Solaas
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Checking-data-source-definitions-for-missing-JDBC-drivers-tp15371243p17867894.html
> Sent from the Netbeans - J2EE mailing list archive at Nabble.com.
>

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[cowwoc]

To be clear, I am not using PostgrelSQL or JBoss at all. I am using MySQL and JPA under Tomcat but I see the exact same behavior.

Gili

Wouter van Reeven wrote:

Just to be sure, you DID copy the postgresql jars to the JBoss app server lib
directory, right?


Wouter

On Mon, Jun 16, 2008 at 09:12:06AM -0700, cowwoc wrote:
>
> I too see this 100% of the time. Can someone from the Netbeans team work with
> us to fix this?
>
> Gili
>
>
> jon martin solaas wrote:
> >
> > Run NB 6.0.1 on Ubuntu Gutsy and java 1.6.0_4, using postgresql 8.2 and
> > JBOSS 4.2.2 in a simple JPA project. I've defined a datasource and had
> > Netbeans create an EJB3.0 entity bean for a simple table. Build jar goes
> > OK, but on running the project or Undeploy and Deploy the entire process
> > hangs checking data source definitions:
> >
> > init:
> > deps-jar:
> > compile:
> > library-inclusion-in-archive:
> > dist:
> > pre-run-deploy:
> > Checking data source definitions for missing JDBC drivers...
> >
> > After this nothing happens.
> >
> > Also occurs on v. 6.0.
> > Any ideas would be appreciated.
> >
> > --
> > Best Regards,
> > Jon Martin Solaas
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Checking-data-source-definitions-for-missing-JDBC-drivers-tp15371243p17867894.html
> Sent from the Netbeans - J2EE mailing list archive at Nabble.com.
>
--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[Wouter van Reeven]

On Mon, Jun 16, 2008 at 02:27:15PM -0700, cowwoc wrote:
>
> To be clear, I am not using PostgrelSQL or JBoss at all. I am using MySQL and
> JPA under Tomcat but I see the exact same behavior.

And there are MySQL drivers in the JBoss lib dir? Again, just checking...


Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[cowwoc]

You mean Tomcat dir right (since I am not using JBoss)? Yes, I have mysql-connector-java-5.1.5-bin.jar in Tomcat/lib (global JARs directory)

Gili

Wouter van Reeven wrote:

On Mon, Jun 16, 2008 at 02:27:15PM -0700, cowwoc wrote:
>
> To be clear, I am not using PostgrelSQL or JBoss at all. I am using MySQL and
> JPA under Tomcat but I see the exact same behavior.

And there are MySQL drivers in the JBoss lib dir? Again, just checking...


Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[Wouter van Reeven]

On Mon, Jun 16, 2008 at 02:29:07PM -0700, cowwoc wrote:
> You mean Tomcat dir right (since I am not using JBoss)? Yes, I have
> mysql-connector-java-5.1.5-bin.jar in Tomcat/lib (global JARs directory)

Sorry, that's what I meant yes. Thanks for confirming. Are you using EJB3 as
well? I assume with application managed persistence? Or do you have a data
sourcei/realm defined defined in your server.xml? In either case, is the correct
driver used in either persisntence.xml or server.xml? Just checking again, of
course.


Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[cowwoc]

I am using JPA with application-managed persistence.

Turns out I had the wrong persistence unit defined (Toplink instead of Hibernate). Here is a funny question: how the heck does Netbeans know that when I define a new persistence unit with the hibernate JARs that the persistence unit should be called Hibernate? That is, I define a new persistence unit called "hibernatePersistenceUnit" but when I hit OK it gets renamed to "Hibernate" like magic ;)

Fixing the persistence unit did not make the problem go away. In a nutshell the bug is that if a webapp fails to deply, all subsequent deployments will fail on "Checking data source definitions for missing JDBC drivers..." I filed this bug report: http://www.netbeans.org/issues/show_bug.cgi?id=137340

Gili

Wouter van Reeven wrote:

On Mon, Jun 16, 2008 at 02:29:07PM -0700, cowwoc wrote:
> You mean Tomcat dir right (since I am not using JBoss)? Yes, I have
> mysql-connector-java-5.1.5-bin.jar in Tomcat/lib (global JARs directory)

Sorry, that's what I meant yes. Thanks for confirming. Are you using EJB3 as
well? I assume with application managed persistence? Or do you have a data
sourcei/realm defined defined in your server.xml? In either case, is the correct
driver used in either persisntence.xml or server.xml? Just checking again, of
course.

[Wouter van Reeven]

On Mon, Jun 16, 2008 at 02:59:46PM -0700, cowwoc wrote:
> Fixing the persistence unit did not make the problem go away. In a nutshell
> the bug is that if a webapp fails to deply, all subsequent deployments will
> fail on "Checking data source definitions for missing JDBC drivers..." I
> filed this bug report: http://www.netbeans.org/issues/show_bug.cgi?id=137340

Did you ever remove the faulty web app war from the tomcat dir? It should be
under .netbeans/6.1/apache-tomcat-xxxx or something (sorry, I don't have tomcat
installed in my NetBeans install) in your home dir (something like /home/gili
under Linux or C:\Documents and Settings\gili under Windows). That should
definately fix your problem.

I do agree that NetBeans should be able to detect a faulty deployment like the
one you describe in the bug report. Perhaps you could attach your project to the
bug report so it can be used to verify your bug report?


Greets, Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[cowwoc]

Doing what you said definitely has an effect, unfortunately it does not fix the problem. My webapp has a bug which causes deployment to fail (the servlet or filter throws an exception on startup). It seems that this (or anything else that causes deployment to fail) is enough to trigger this bug.

Hopefully the Netbeans guys will make this process more robust as you mentioned.

Gili

Wouter van Reeven wrote:

On Mon, Jun 16, 2008 at 02:59:46PM -0700, cowwoc wrote:
> Fixing the persistence unit did not make the problem go away. In a nutshell
> the bug is that if a webapp fails to deply, all subsequent deployments will
> fail on "Checking data source definitions for missing JDBC drivers..." I
> filed this bug report: http://www.netbeans.org/issues/show_bug.cgi?id=137340

Did you ever remove the faulty web app war from the tomcat dir? It should be
under .netbeans/6.1/apache-tomcat-xxxx or something (sorry, I don't have tomcat
installed in my NetBeans install) in your home dir (something like /home/gili
under Linux or C:\Documents and Settings\gili under Windows). That should
definately fix your problem.

I do agree that NetBeans should be able to detect a faulty deployment like the
one you describe in the bug report. Perhaps you could attach your project to the
bug report so it can be used to verify your bug report?


Greets, Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[Wouter van Reeven]

On Mon, Jun 16, 2008 at 03:15:22PM -0700, cowwoc wrote:
> Doing what you said definitely has an effect, unfortunately it does not fix
> the problem. My webapp has a bug which causes deployment to fail (the
> servlet or filter throws an exception on startup). It seems that this (or
> anything else that causes deployment to fail) is enough to trigger this bug.

One more "just checking" : did you restart Tomcat after removing the faulty web
app? Or just bring it down, remove the web app, and bring it back up? I find
that NullPointerExceptions (and OutOfMemoryErrors) usually need that.


HTH, Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[cowwoc]

If I restart Tomcat then redeployment works, but (for obvious reasons) restarting Tomcat every time isn't an option. It's simply too slow. Here is the exception being thrown by the webapp:

com.google.inject.ConfigurationException: Error at desktopbeautifier.web.gallery.SmallImageResourceFactory.<init>(SmallImageResourceFactory.java:65) Could not find a suitable constructor in desktopbeautifier.web.gallery.SmallImageResourceFactory. Classes must have either one (and only one) constructor annotated with @Inject or a zero-argument constructor.
        at com.google.inject.BinderImpl$RuntimeErrorHandler.handle(BinderImpl.java:426)
        at com.google.inject.AbstractErrorHandler.handle(AbstractErrorHandler.java:30)
        at com.google.inject.ConstructorInjector.findConstructorIn(ConstructorInjector.java:105)
        at com.google.inject.ConstructorInjector.<init>(ConstructorInjector.java:37)
        at com.google.inject.InjectorImpl$7.create(InjectorImpl.java:601)
        at com.google.inject.InjectorImpl$7.create(InjectorImpl.java:594)
        at com.google.inject.util.ReferenceCache.create(ReferenceCache.java:53)
        at com.google.inject.util.AbstractReferenceCache.internalCreate(AbstractReferenceCache.java:59)
        at com.google.inject.util.AbstractReferenceCache.get(AbstractReferenceCache.java:116)
        at com.google.inject.InjectorImpl.getConstructor(InjectorImpl.java:765)
        at com.google.inject.InjectorImpl.getImplicitBinding(InjectorImpl.java:973)
        at com.google.inject.InjectorImpl.getInternalFactory(InjectorImpl.java:308)
        at com.google.inject.InjectorImpl.getProvider(InjectorImpl.java:693)
        at com.google.inject.InjectorImpl.getProvider(InjectorImpl.java:689)
        at com.google.inject.InjectorImpl.getInstance(InjectorImpl.java:728)
        at desktopbeautifier.web.Application$Initializer.init(Application.java:65)
        at org.apache.wicket.Application.callInitializers(Application.java:788)
        at org.apache.wicket.Application.initializeComponents(Application.java:625)
        at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:532)
        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
        at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
        at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:108)
        at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:4356)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
        at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
        at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
        at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
        at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147)
        at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
        at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
        at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
        at org.apache.catalina.core.StandardService.start(StandardService.java:516)
        at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

As you can see, it's not such a fatal exception. The webapp should fail to deploy but it shouldn't bring down all of Tomcat and Netbeans with it.

Gili

Wouter van Reeven wrote:

On Mon, Jun 16, 2008 at 03:15:22PM -0700, cowwoc wrote:
> Doing what you said definitely has an effect, unfortunately it does not fix
> the problem. My webapp has a bug which causes deployment to fail (the
> servlet or filter throws an exception on startup). It seems that this (or
> anything else that causes deployment to fail) is enough to trigger this bug.

One more "just checking" : did you restart Tomcat after removing the faulty web
app? Or just bring it down, remove the web app, and bring it back up? I find
that NullPointerExceptions (and OutOfMemoryErrors) usually need that.


HTH, Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[Wouter van Reeven]

On Mon, Jun 16, 2008 at 03:34:02PM -0700, cowwoc wrote:
> If I restart Tomcat then redeployment works, but (for obvious reasons)
> restarting Tomcat every time isn't an option. It's simply too slow. Here is

Of course. But at least you can carry on :-)

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[Wim Verreycken]

Hi,

Just an idea for a workaround :
Have you tried adding the JDBC driver as a server library in netbeans,
adding it to your project, and then deploying the project?

Wim

-----Original Message-----
From: cowwoc [mailto:cowwoc@...]
Sent: dinsdag 17 juni 2008 0:15
To: nbj2ee@...
Subject: Re: [nbj2ee] Checking data source definitions for missing JDBC
drivers



Doing what you said definitely has an effect, unfortunately it does not fix
the problem. My webapp has a bug which causes deployment to fail (the
servlet or filter throws an exception on startup). It seems that this (or
anything else that causes deployment to fail) is enough to trigger this bug.

Hopefully the Netbeans guys will make this process more robust as you
mentioned.

Gili


Wouter van Reeven wrote:

>
> On Mon, Jun 16, 2008 at 02:59:46PM -0700, cowwoc wrote:
>> Fixing the persistence unit did not make the problem go away. In a
>> nutshell
>> the bug is that if a webapp fails to deply, all subsequent deployments
>> will
>> fail on "Checking data source definitions for missing JDBC drivers..." I
>> filed this bug report:
>> http://www.netbeans.org/issues/show_bug.cgi?id=137340
>
> Did you ever remove the faulty web app war from the tomcat dir? It should
> be
> under .netbeans/6.1/apache-tomcat-xxxx or something (sorry, I don't have
> tomcat
> installed in my NetBeans install) in your home dir (something like
> /home/gili
> under Linux or C:\Documents and Settings\gili under Windows). That should
> definately fix your problem.
>
> I do agree that NetBeans should be able to detect a faulty deployment like
> the
> one you describe in the bug report. Perhaps you could attach your project
> to the
> bug report so it can be used to verify your bug report?
>
>
> Greets, Wouter
>
> --
>
> People: "If she weighs the same as a Duck, she's made of wood!"
> Sir Bedevere: "And therefore...?"
>
>

--
View this message in context:
http://www.nabble.com/Checking-data-source-definitions-for-missing-JDBC-driv
ers-tp15371243p17874397.html
Sent from the Netbeans - J2EE mailing list archive at Nabble.com.

[cowwoc]

Sorry, I'm not sure what you mean. Can you give more precise steps for doing this?

Thanks,
Gili

Wim V-2 wrote:

Hi,

Just an idea for a workaround :
Have you tried adding the JDBC driver as a server library in netbeans,
adding it to your project, and then deploying the project?

Wim

-----Original Message-----
From: cowwoc [mailto:[e-mail]]
Sent: dinsdag 17 juni 2008 0:15
To: [e-mail]
Subject: Re: [nbj2ee] Checking data source definitions for missing JDBC
drivers



Doing what you said definitely has an effect, unfortunately it does not fix
the problem. My webapp has a bug which causes deployment to fail (the
servlet or filter throws an exception on startup). It seems that this (or
anything else that causes deployment to fail) is enough to trigger this bug.

Hopefully the Netbeans guys will make this process more robust as you
mentioned.

Gili


Wouter van Reeven wrote:
>
> On Mon, Jun 16, 2008 at 02:59:46PM -0700, cowwoc wrote:
>> Fixing the persistence unit did not make the problem go away. In a
>> nutshell
>> the bug is that if a webapp fails to deply, all subsequent deployments
>> will
>> fail on "Checking data source definitions for missing JDBC drivers..." I
>> filed this bug report:
>> http://www.netbeans.org/issues/show_bug.cgi?id=137340
>
> Did you ever remove the faulty web app war from the tomcat dir? It should
> be
> under .netbeans/6.1/apache-tomcat-xxxx or something (sorry, I don't have
> tomcat
> installed in my NetBeans install) in your home dir (something like
> /home/gili
> under Linux or C:\Documents and Settings\gili under Windows). That should
> definately fix your problem.
>
> I do agree that NetBeans should be able to detect a faulty deployment like
> the
> one you describe in the bug report. Perhaps you could attach your project
> to the
> bug report so it can be used to verify your bug report?
>
>
> Greets, Wouter
>
> --
>
> People: "If she weighs the same as a Duck, she's made of wood!"
> Sir Bedevere: "And therefore...?"
>
>

--
View this message in context:
http://www.nabble.com/Checking-data-source-definitions-for-missing-JDBC-driv
ers-tp15371243p17874397.html
Sent from the Netbeans - J2EE mailing list archive at Nabble.com.

[Wouter van Reeven]

Goedemorgen Wim,

On Tue, Jun 17, 2008 at 01:22:42AM +0200, Wim V wrote:
> Just an idea for a workaround :
> Have you tried adding the JDBC driver as a server library in netbeans,
> adding it to your project, and then deploying the project?

As it turns out the error message is misleading. A NullPointerException that is
thrown when a faulty web application is deployed turns out to be the problem.


Greets, Wouter

--

People: "If she weighs the same as a Duck, she's made of wood!"
Sir Bedevere: "And therefore...?"

[cowwoc]

Ack! Nevermind, I figured it out. The problem turned out to be my NOD32 anti-virus. It has http monitoring which screws up Netbeans-Tomcat communication unless you disable it for java.exe. There is still a valid bug behind this story (Netbeans fails to redeploy an application when it should work) but at least now the hang is gone. Thanks for all your help Wouter. I'm sorry to have wasted your time. Hopefully this post will help other people who run across the same problem.

Gili




Sorry, I'm not sure what you mean. Can you give more precise steps for doing this?

Thanks,
Gili

Wim V-2 wrote:

Hi,

Just an idea for a workaround :
Have you tried adding the JDBC driver as a server library in netbeans,
adding it to your project, and then deploying the project?

Wim

-----Original Message-----
From: cowwoc [mailto:[e-mail]]
Sent: dinsdag 17 juni 2008 0:15
To: [e-mail]
Subject: Re: [nbj2ee] Checking data source definitions for missing JDBC
drivers



Doing what you said definitely has an effect, unfortunately it does not fix
the problem. My webapp has a bug which causes deployment to fail (the
servlet or filter throws an exception on startup). It seems that this (or
anything else that causes deployment to fail) is enough to trigger this bug.

Hopefully the Netbeans guys will make this process more robust as you
mentioned.

Gili


Wouter van Reeven wrote:
>
> On Mon, Jun 16, 2008 at 02:59:46PM -0700, cowwoc wrote:
>> Fixing the persistence unit did not make the problem go away. In a
>> nutshell
>> the bug is that if a webapp fails to deply, all subsequent deployments
>> will
>> fail on "Checking data source definitions for missing JDBC drivers..." I
>> filed this bug report:
>> http://www.netbeans.org/issues/show_bug.cgi?id=137340
>
> Did you ever remove the faulty web app war from the tomcat dir? It should
> be
> under .netbeans/6.1/apache-tomcat-xxxx or something (sorry, I don't have
> tomcat
> installed in my NetBeans install) in your home dir (something like
> /home/gili
> under Linux or C:\Documents and Settings\gili under Windows). That should
> definately fix your problem.
>
> I do agree that NetBeans should be able to detect a faulty deployment like
> the
> one you describe in the bug report. Perhaps you could attach your project
> to the
> bug report so it can be used to verify your bug report?
>
>
> Greets, Wouter
>
> --
>
> People: "If she weighs the same as a Duck, she's made of wood!"
> Sir Bedevere: "And therefore...?"
>
>

--
View this message in context:
http://www.nabble.com/Checking-data-source-definitions-for-missing-JDBC-driv
ers-tp15371243p17874397.html
Sent from the Netbeans - J2EE mailing list archive at Nabble.com.