RE: [JBoss-user] Problem with jbossweb-tomcat50.sar in 3.2.2
Thanks for the help. That appeared to fix it. So for future reference if anyone else is experiencing the same problem. It appears it's not good enough to have commons-logging.jar in the server/lib or in the jbossweb-tomcat50.sar. For some reason it needs to be appended onto the classpath of the server itself. Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Remy Maucherat Sent: Saturday, October 25, 2003 8:29 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Problem with jbossweb-tomcat50.sar in 3.2.2 [EMAIL PROTECTED] wrote: I dont know if jbossweb-tomcat50.sar is officially supported yet but Ill notify you of the problem Im having anyway. I have a .war in an .ear that uses container managed FORM security. I was originally developing in 3.2.2RC3 + jbossweb-tomcat50.sar instead of jbossweb-tomcat41.sar. Everything worked great in 3.2.2RC3. However, when I attempt to deploy my application in 3.2.2 I get the exception below. It appears to be something wrong with the logging configuration but I really have no idea what. It also appears to be localized to the new jbossweb-tomcat50.sar because if I deploy the jbossweb-tomcat50.sar from 3.2.2RC3 in 3.2.2 everything works fine. In addition if I convert my web-app to a 2.3 web-app and deploy it in 3.2.2s jbossweb-tomcat41.sar then it deploys fine. Any ideas? This happened earlier with TC standalone and Struts webapps. Basically, the fix for all cases is to put commons-logging in the main classpath. However, it is very likley that TC 5 will end up using (like 4.1) a JB provided loader for the webapp repositories. This would also solve the problem. -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Problems with JMX Invoke Ant Task 3.2.2
Thanks for your help. For the record I changed my task to look like this: jmx adapterName=jmx/invoker/RMIAdaptor ... /jmx Now it works great again. Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Thursday, October 23, 2003 4:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Problems with JMX Invoke Ant Task 3.2.2 The jbossjmx ant task is making an assumption about the location of the RMIAdaptor that is out of date due to the removal of the rmi-adaptor.sar. This is an obsolete JNDI look that stupidly included the hostname of the JNDI server you are doing the lookup against. The binding that has been in place since 3.2.1 is jmx/invoker/RMIAdaptor. Also, one appears to be supporting this task. -- Scott Stark Chief Technology Officer JBoss Group, LLC Mike Youngstrom wrote: Hello, I just upgraded to 3.2.2 from 3.2.2RC3 and now my ant target that deploys my app using the JMX/Invoke task in jbossjmx-ant.jar fails. The exact same target worked perfectly in 3.2.2RC3. Any ideas? See the exception I'm getting below. My target is a very vanilla deploy based off of the example in varia\src\main\org\jboss\ant\package.html The host youngm is the name of my machine and it does resolve correctly. Mike [jmx] javax.naming.NameNotFoundException: jmx:youngm:rmi not bound [jmx] at org.jnp.server.NamingServer.getBinding(NamingServer.java:495) [jmx] at org.jnp.server.NamingServer.getBinding(NamingServer.java:503) [jmx] at org.jnp.server.NamingServer.getObject(NamingServer.java:509) [jmx] at org.jnp.server.NamingServer.lookup(NamingServer.java:282) [jmx] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [jmx] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) [jmx] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) [jmx] at java.lang.reflect.Method.invoke(Method.java:324) [jmx] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) [jmx] at sun.rmi.transport.Transport$1.run(Transport.java:148) [jmx] at java.security.AccessController.doPrivileged(Native Method) [jmx] at sun.rmi.transport.Transport.serviceCall(Transport.java:144) [jmx] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) [jmx] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:7 01) [jmx] at java.lang.Thread.run(Thread.java:534) [jmx] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteC all.java:247) [jmx] at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) [jmx] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) [jmx] at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) [jmx] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:528) [jmx] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) [jmx] at javax.naming.InitialContext.lookup(InitialContext.java:347) [jmx] at org.jboss.ant.JMX.execute(JMX.java:209) [jmx] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:193) [jmx] at org.apache.tools.ant.Task.perform(Task.java:341) [jmx] at org.apache.tools.ant.Target.execute(Target.java:309) [jmx] at org.apache.tools.ant.Target.performTasks(Target.java:336) [jmx] at org.apache.tools.ant.Project.executeTarget(Project.java:1339) [jmx] at org.apache.tools.ant.Project.executeTargets(Project.java:1255) [jmx] at org.apache.tools.ant.Main.runBuild(Main.java:609) [jmx] at org.apache.tools.ant.Main.start(Main.java:196) [jmx] at org.apache.tools.ant.Main.main(Main.java:235) --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ JBoss-user mailing list [EMAIL
[JBoss-user] Problems with JMX Invoke Ant Task 3.2.2
Hello, I just upgraded to 3.2.2 from 3.2.2RC3 and now my ant target that deploys my app using the JMX/Invoke task in jbossjmx-ant.jar fails. The exact same target worked perfectly in 3.2.2RC3. Any ideas? See the exception Im getting below. My target is a very vanilla deploy based off of the example in varia\src\main\org\jboss\ant\package.html The host youngm is the name of my machine and it does resolve correctly. Mike [jmx] javax.naming.NameNotFoundException: jmx:youngm:rmi not bound [jmx] at org.jnp.server.NamingServer.getBinding(NamingServer.java:495) [jmx] at org.jnp.server.NamingServer.getBinding(NamingServer.java:503) [jmx] at org.jnp.server.NamingServer.getObject(NamingServer.java:509) [jmx] at org.jnp.server.NamingServer.lookup(NamingServer.java:282) [jmx] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [jmx] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [jmx] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [jmx] at java.lang.reflect.Method.invoke(Method.java:324) [jmx] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) [jmx] at sun.rmi.transport.Transport$1.run(Transport.java:148) [jmx] at java.security.AccessController.doPrivileged(Native Method) [jmx] at sun.rmi.transport.Transport.serviceCall(Transport.java:144) [jmx] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) [jmx] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) [jmx] at java.lang.Thread.run(Thread.java:534) [jmx] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) [jmx] at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) [jmx] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) [jmx] at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) [jmx] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:528) [jmx] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) [jmx] at javax.naming.InitialContext.lookup(InitialContext.java:347) [jmx] at org.jboss.ant.JMX.execute(JMX.java:209) [jmx] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:193) [jmx] at org.apache.tools.ant.Task.perform(Task.java:341) [jmx] at org.apache.tools.ant.Target.execute(Target.java:309) [jmx] at org.apache.tools.ant.Target.performTasks(Target.java:336) [jmx] at org.apache.tools.ant.Project.executeTarget(Project.java:1339) [jmx] at org.apache.tools.ant.Project.executeTargets(Project.java:1255) [jmx] at org.apache.tools.ant.Main.runBuild(Main.java:609) [jmx] at org.apache.tools.ant.Main.start(Main.java:196) [jmx] at org.apache.tools.ant.Main.main(Main.java:235)
[JBoss-user] Problems with JMX Invoke Ant Task 3.2.2 (Try 2)
(Sorry for the possible duplicate post I originally sent this 24 hours ago and never saw in on the List) Hello, I just upgraded to 3.2.2 from 3.2.2RC3 and now my ant target that deploys my app using the JMX/Invoke task in jbossjmx-ant.jar fails. The exact same target worked perfectly in 3.2.2RC3. Any ideas? See the exception Im getting below. My target is a very vanilla deploy based off of the example in varia\src\main\org\jboss\ant\package.html The host youngm is the name of my machine and it does resolve correctly. Mike [jmx] javax.naming.NameNotFoundException: jmx:youngm:rmi not bound [jmx] at org.jnp.server.NamingServer.getBinding(NamingServer.java:495) [jmx] at org.jnp.server.NamingServer.getBinding(NamingServer.java:503) [jmx] at org.jnp.server.NamingServer.getObject(NamingServer.java:509) [jmx] at org.jnp.server.NamingServer.lookup(NamingServer.java:282) [jmx] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [jmx] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [jmx] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [jmx] at java.lang.reflect.Method.invoke(Method.java:324) [jmx] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) [jmx] at sun.rmi.transport.Transport$1.run(Transport.java:148) [jmx] at java.security.AccessController.doPrivileged(Native Method) [jmx] at sun.rmi.transport.Transport.serviceCall(Transport.java:144) [jmx] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) [jmx] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) [jmx] at java.lang.Thread.run(Thread.java:534) [jmx] at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) [jmx] at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) [jmx] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) [jmx] at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) [jmx] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:528) [jmx] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) [jmx] at javax.naming.InitialContext.lookup(InitialContext.java:347) [jmx] at org.jboss.ant.JMX.execute(JMX.java:209) [jmx] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:193) [jmx] at org.apache.tools.ant.Task.perform(Task.java:341) [jmx] at org.apache.tools.ant.Target.execute(Target.java:309) [jmx] at org.apache.tools.ant.Target.performTasks(Target.java:336) [jmx] at org.apache.tools.ant.Project.executeTarget(Project.java:1339) [jmx] at org.apache.tools.ant.Project.executeTargets(Project.java:1255) [jmx] at org.apache.tools.ant.Main.runBuild(Main.java:609) [jmx] at org.apache.tools.ant.Main.start(Main.java:196) [jmx] at org.apache.tools.ant.Main.main(Main.java:235)
RE: [JBoss-user] Quick JDBC question.
Title: Message
Thanks for the tip. I rewrote the
code like you suggested and Im still getting the warning. Any more
ideas?
Mike
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rod Macpherson
Sent: Thursday, October 09, 2003
7:12 PM
To:
[EMAIL PROTECTED]
Subject: RE: [JBoss-user] Quick
JDBC question.
I would structure this as
follows to make sure the ResultSet is always closed and also so that you do not
get a null pointer if the prepare statement throws:
blah blah blah...
finally
{
try
{
if(result != null) result.close();
if(statement != null) statement.close();
if(connection != null) connection.close();
}
catch(SQLException e)
{
logger.error(whaddup?);
}
}
-Original
Message-
From: Mike Youngstrom
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 09, 2003
5:35 PM
To:
[EMAIL PROTECTED]
Subject: RE: [JBoss-user] Quick
JDBC question.
Let me add a little more
information.
Version: JBoss 3.2.2 RC3
DBServer Mysql 4.0.15
Windows
JDBCDriver: Connector/J
3.0.8
Mike
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Youngstrom
Sent: Thursday, October 09, 2003
10:38 AM
To:
[EMAIL PROTECTED]
Subject: [JBoss-user] Quick JDBC
question.
Im
fairly new to JDBC development and JBoss. I have the following code in a
stateless session bean.
try
{
boolean
exists;
prepStmt = conn.prepareStatement(USERNAME_EXISTS);
prepStmt.setString(1, username);
ResultSet result = prepStmt.executeQuery();
exists = result.next();
result.close();
return
exists;
} catch
(EJBException e) {
log.error(Error checking if username
exists: ,
e);
throw
new
EJBException(e);
} finally
{
try
{
prepStmt.close();
} catch
(Exception e) {/* Do Nothing */}
try
{
conn.close();
} catch
(Exception e) {/* Do Nothing */}
}
Every time I execute the above method I get the
following log entry:
WARN [WrappedConnection] Closing a statement
you left open, please do your own housekeeping
Any idea what Im doing to warrant that warning? When I
step through the code with a debugger prepStmt.close() is executed with no
exception and when conn.close() is executed that warning pops up.
prepStmt is the only statement Im creating with that connection.
Anyone have any ideas?
Mike
RE: [JBoss-user] Quick JDBC question.
I'm not closing the ResultSet? I thought I wasgranted I'm doing it in a strange
place.
I changed the code to look like how Rod described and I'm still getting the warning.
Is anyone else experiencing anything like this? Should I post a bug?
Mike
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, October 10, 2003 3:03 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Quick JDBC question.
You haven't closed your resultset...
Harm.
Mike Youngstrom [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/09/2003 06:37 PM
Please respond to
[EMAIL PROTECTED]
To
[EMAIL PROTECTED]
cc
Subject
[JBoss-user] Quick JDBC question.
Im fairly new to JDBC development and JBoss. I have the following code
in a stateless session bean.
try {
boolean exists;
prepStmt = conn.prepareStatement(USERNAME_EXISTS);
prepStmt.setString(1, username);
ResultSet result = prepStmt.executeQuery();
exists = result.next();
result.close();
return exists;
} catch (EJBException e) {
log.error(Error checking if username exists: , e);
throw new EJBException(e);
} finally {
try {
prepStmt.close();
} catch (Exception e) {/* Do Nothing */}
try {
conn.close();
} catch (Exception e) {/* Do Nothing */}
}
Every time I execute the above method I get the following log entry:
WARN [WrappedConnection] Closing a statement you left open, please do
your own housekeeping
Any idea what Im doing to warrant that warning? When I step through the
code with a debugger prepStmt.close() is executed with no exception and
when conn.close() is executed that warning pops up. prepStmt is the only
statement Im creating with that connection. Anyone have any ideas?
Mike
NHYXuw+mxZ zM x 'z{ B5z ')rHq
z $f)+$X~zw q
z X)
---
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Quick JDBC question.
Im
fairly new to JDBC development and JBoss. I have the following code in a
stateless session bean.
try
{
boolean
exists;
prepStmt = conn.prepareStatement(USERNAME_EXISTS);
prepStmt.setString(1, username);
ResultSet result = prepStmt.executeQuery();
exists = result.next();
result.close();
return
exists;
} catch (EJBException e) {
log.error(Error checking if username
exists: ,
e);
throw
new
EJBException(e);
} finally {
try
{
prepStmt.close();
} catch (Exception e) {/* Do Nothing */}
try
{
conn.close();
} catch (Exception e) {/* Do Nothing */}
}
Every
time I execute the above method I get the following log entry:
WARN
[WrappedConnection] Closing a statement you left open, please do your own
housekeeping
Any idea what Im
doing to warrant that warning? When I step through the code with a
debugger prepStmt.close() is executed with no exception and when conn.close() is
executed that warning pops up. prepStmt is the only statement Im
creating with that connection. Anyone have any ideas?
Mike
RE: [JBoss-user] Quick JDBC question.
Let me add a little more information.
Version: JBoss 3.2.2 RC3
DBServer Mysql 4.0.15 Windows
JDBCDriver: Connector/J 3.0.8
Mike
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Youngstrom
Sent: Thursday, October 09, 2003
10:38 AM
To:
[EMAIL PROTECTED]
Subject: [JBoss-user] Quick JDBC
question.
Im fairly new to JDBC development and JBoss. I
have the following code in a stateless session bean.
try
{
boolean
exists;
prepStmt = conn.prepareStatement(USERNAME_EXISTS);
prepStmt.setString(1, username);
ResultSet result = prepStmt.executeQuery();
exists = result.next();
result.close();
return
exists;
} catch
(EJBException e) {
log.error(Error checking if username
exists: ,
e);
throw
new
EJBException(e);
} finally
{
try
{
prepStmt.close();
} catch
(Exception e) {/* Do Nothing */}
try
{
conn.close();
} catch
(Exception e) {/* Do Nothing */}
}
Every time I execute the above method I get the
following log entry:
WARN [WrappedConnection] Closing a statement
you left open, please do your own housekeeping
Any idea what Im doing to warrant that warning? When I
step through the code with a debugger prepStmt.close() is executed with no
exception and when conn.close() is executed that warning pops up.
prepStmt is the only statement Im creating with that connection.
Anyone have any ideas?
Mike
