[JBoss-user] building from cvs failing
Hi there, For several weeks I’ve been getting the latest version of Jboss4.0.0alpha from CVS and attempting to build by executing “ant all” from the jboss-head/build directory, but it has been failing consistently for one reason or another. Does anyone have time to fix the build? The error I’m getting now is that some jars are missing from the classpath. First commons-logging.jar was missing and now I get this error: java.lang.NoClassDefFoundError: org/apache/commons/collections/Predicate at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:49) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) at org.jboss.tools.buildmagic.task.module.ExecuteModules$1.run(ExecuteModules.java:329) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:342) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:217) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) for which I cannot find a jar to remedy. Your help is appreciated, Emily
RE: [JBoss-user] Connection handle is not currently associated with a ManagedConnection
Sounds like it would work in general, but in my specific case I'm afraid it doesn't. This is a limitation of the PreparedStatement's implementation, however... Since I am using DB transactions, I always have different connections (transactions) executing the same statements. This means that using a PreparedStatement associated with any old connection won't work. Why is it that PreparedStatements need to be associated with a particular connection anyway? Emily -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 26, 2002 7:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Connection handle is not currently associated with a ManagedConnection On 2002.12.26 21:22:13 -0500 Rick LaBanca wrote: > Sounds like a case for some kind of statement pooling if there is such a > thing. I haven't used j2ee for any of this stuff at this level, but my > jdbc > experience has shown me that reusing prepared statements can be the > biggest > optimization in many cases (with oracle it was especially so). > So much for what various "experts" told me about "most" databases and Oracle in particular. I'd think it would be fairly easy to write, except for the bad experiences with the previous version. I'm thinking of a hashmap from sql to object that has PreparedStatement and timestamp, and a thread that periodically removes overaged objects. This would be turned off by default :-) Does that seem like it would work? Thanks david jencks > rick > > > - Original Message - > From: "Emily Short" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, December 26, 2002 8:08 PM > Subject: RE: [JBoss-user] Connection handle is not currently associated > with > a ManagedConnection > > > Hi David, > > Thanks so much for your quick response. > > Does this mean I should not use PreparedStatements at all, unless doing > a batch of queries from a single method? I was hoping that I was > increasing efficiency by using the precompiled sql statements over > multiple method calls. Is there any way to still take advantage of > PreparedStatements in this way? > > Thanks again, > Emily > > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 26, 2002 4:44 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Connection handle is not currently associated > with a ManagedConnection > > You can't keep connections in static variables (possibly unless you > configure the use of the datasource as an unshared resource). I > recommend > not keeping connections open across method calls: it either makes the > caching system work harder (if you use non-static instance variables) or > produces wrong results (if you don't). You also can't keep statements > open > across method calss (again, possibly it will work if the use is marked > as > an unhasred resource). > > Here's why: > > The jca spec includes support for container managed security, which > includes the ability for the container to supply different security info > (user/pw) every time you get to the ejb that is using the connection. > Unfortunately, the spec also includes support for holding connection > handles over method calls. This means that for every call into your > ejb, > the jca framework has to associate whatever connection handles you left > open with physical connections that are logged in as the correct user. > This means that > > (1) holding a connection in a static variable won't work, the container > has > no idea what object you expect it to be associated with, and can't > supply a > physical connection for it. > > (2) holding a statement open won't work because the connection handle is > apt to be associated with a different physical connection the next time > you > try to use it. > > The connection pooling framework basically makes trying to hold onto a > connection irrelvant and unnecessary. If a static variable worked, it > would also defeat connection pooling by holding onto a connection even > when > it was possibly not being used. > > david jencks > > > > On 2002.12.26 19:21:06 -0500 Emily Short wrote: > > Hello all, > > > > I am getting this exception when I declare the following class > > variables: > > > > private static Connection connection = null; > > private static PreparedStatement queryProductSummary = null; > > > > and then try to execute this code within that class twice in a row (a > > message driven bean calls this code): > > > > public static Document getProductS
RE: [JBoss-user] Connection handle is not currently associated with a ManagedConnection
Hi David,
Thanks so much for your quick response.
Does this mean I should not use PreparedStatements at all, unless doing
a batch of queries from a single method? I was hoping that I was
increasing efficiency by using the precompiled sql statements over
multiple method calls. Is there any way to still take advantage of
PreparedStatements in this way?
Thanks again,
Emily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 26, 2002 4:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Connection handle is not currently associated
with a ManagedConnection
You can't keep connections in static variables (possibly unless you
configure the use of the datasource as an unshared resource). I
recommend
not keeping connections open across method calls: it either makes the
caching system work harder (if you use non-static instance variables) or
produces wrong results (if you don't). You also can't keep statements
open
across method calss (again, possibly it will work if the use is marked
as
an unhasred resource).
Here's why:
The jca spec includes support for container managed security, which
includes the ability for the container to supply different security info
(user/pw) every time you get to the ejb that is using the connection.
Unfortunately, the spec also includes support for holding connection
handles over method calls. This means that for every call into your
ejb,
the jca framework has to associate whatever connection handles you left
open with physical connections that are logged in as the correct user.
This means that
(1) holding a connection in a static variable won't work, the container
has
no idea what object you expect it to be associated with, and can't
supply a
physical connection for it.
(2) holding a statement open won't work because the connection handle is
apt to be associated with a different physical connection the next time
you
try to use it.
The connection pooling framework basically makes trying to hold onto a
connection irrelvant and unnecessary. If a static variable worked, it
would also defeat connection pooling by holding onto a connection even
when
it was possibly not being used.
david jencks
On 2002.12.26 19:21:06 -0500 Emily Short wrote:
> Hello all,
>
> I am getting this exception when I declare the following class
> variables:
>
> private static Connection connection = null;
> private static PreparedStatement queryProductSummary = null;
>
> and then try to execute this code within that class twice in a row (a
> message driven bean calls this code):
>
> public static Document getProductSummary(String participantID, int
> productID) throws Exception{
> Document result = null;
>
> prepareConnection();
> if(queryProductSummary == null){
> log.info("preparing statement");
> queryProductSummary = connection.prepareStatement("SELECT
> product_summary_xml " +
> " FROM product_summary_xml " +
> " WHERE participant_id = ? " +
> " AND product_id = ? ");
> }
>
> queryProductSummary.clearParameters();
> queryProductSummary.setString(1, participantID);
> queryProductSummary.setInt(2, productID);
>
> ResultSet rs = queryProductSummary.executeQuery();
>
> ...
>
> return result;
> }
>
> public static void prepareConnection() throws SQLException{
> if(connection == null || connection.isClosed())
> connection = OracleDataSource.getConnection();
> }
>
> I realize it is good practice to close statements and connections, but
> in this case I wanted to keep them open across multiple calls.
>
> I have been reading in the forums that this seems to be a JBoss issue,
> but I want to make sure I am not doing anything blatantly incorrect.
I
> am using JBoss4.0alpha.
>
> Here is the exception:
>
> 16:18:19,047 ERROR [STDERR] java.sql.SQLException: Connection handle
is
> not currently associated with a ManagedConnection
> 16:18:19,047 ERROR [STDERR] at
>
org.jboss.resource.adapter.jdbc.WrappedConnection.checkStatus(WrappedCon
> nection.java:774)
> 16:18:19,047 ERROR [STDERR] at
>
org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(Wrapp
> edConnection.java:755)
> 16:18:19,047 ERROR [STDERR] at
>
org.jboss.resource.adapter.jdbc.WrappedStatement.checkTransaction(Wrappe
> dStatement.java:771)
> 16:18:19,047 ERROR [STDERR] at
>
org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(Wr
> appedPreparedStatement.java:286)
> 16:18:19,047 ERROR [STDERR] at
>
[JBoss-user] Connection handle is not currently associated with a ManagedConnection
Hello all,
I am getting this exception when I declare the following class
variables:
private static Connection connection = null;
private static PreparedStatement queryProductSummary = null;
and then try to execute this code within that class twice in a row (a
message driven bean calls this code):
public static Document getProductSummary(String participantID, int
productID) throws Exception{
Document result = null;
prepareConnection();
if(queryProductSummary == null){
log.info("preparing statement");
queryProductSummary = connection.prepareStatement("SELECT
product_summary_xml " +
" FROM product_summary_xml " +
" WHERE participant_id = ? " +
" AND product_id = ? ");
}
queryProductSummary.clearParameters();
queryProductSummary.setString(1, participantID);
queryProductSummary.setInt(2, productID);
ResultSet rs = queryProductSummary.executeQuery();
...
return result;
}
public static void prepareConnection() throws SQLException{
if(connection == null || connection.isClosed())
connection = OracleDataSource.getConnection();
}
I realize it is good practice to close statements and connections, but
in this case I wanted to keep them open across multiple calls.
I have been reading in the forums that this seems to be a JBoss issue,
but I want to make sure I am not doing anything blatantly incorrect. I
am using JBoss4.0alpha.
Here is the exception:
16:18:19,047 ERROR [STDERR] java.sql.SQLException: Connection handle is
not currently associated with a ManagedConnection
16:18:19,047 ERROR [STDERR] at
org.jboss.resource.adapter.jdbc.WrappedConnection.checkStatus(WrappedCon
nection.java:774)
16:18:19,047 ERROR [STDERR] at
org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(Wrapp
edConnection.java:755)
16:18:19,047 ERROR [STDERR] at
org.jboss.resource.adapter.jdbc.WrappedStatement.checkTransaction(Wrappe
dStatement.java:771)
16:18:19,047 ERROR [STDERR] at
org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(Wr
appedPreparedStatement.java:286)
16:18:19,047 ERROR [STDERR] at
com.scilearn.db.ProductSummary.getProductSummary(ProductSummary.java:204
)
16:18:19,047 ERROR [STDERR] at
com.scilearn.db.ProductSummary.getExerciseSummaries(ProductSummary.java:
184)
16:18:19,047 ERROR [STDERR] at
com.scilearn.beans.UploadQueueListener.onMessage(UploadQueueListener.jav
a:119)
16:18:19,047 ERROR [STDERR] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:18:19,047 ERROR [STDERR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
16:18:19,047 ERROR [STDERR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
16:18:19,047 ERROR [STDERR] at
java.lang.reflect.Method.invoke(Method.java:324)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(Message
DrivenContainer.java:405)
16:18:19,057 ERROR [STDERR] at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(
CachedConnectionInterceptor.java:187)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterce
ptor.java:108)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInte
rceptorBMT.java:144)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.MessageDrivenTxInterceptorBMT.invoke(MessageDriven
TxInterceptorBMT.java:33)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDri
venInstanceInterceptor.java:88)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInter
ceptor.java:100)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryF
inderInterceptor.java:154)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:
312)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker
.java:697)
16:18:19,057 ERROR [STDERR] at
org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMess
age(JMSContainerInvoker.java:763)
16:18:19,057 ERROR [STDERR] at
org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241)
16:18:19,057 ERROR [STDERR] at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessage
Consumer.java:643)
16:18:19,057 ERROR [STDERR] at
org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:457)
16:18:19,057 ERROR [STDERR] at
org.jboss.mq.SpySession.run(SpySession.java:309)
16:18:19,057 ERROR
RE: [JBoss-user] security_check
Figured it out: jboss-web.xml was not in the right place -Original Message- From: Emily Short Sent: Wednesday, October 09, 2002 1:36 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-user] security_check More info about this problem: I am using JBoss 3.0.3/Jetty and can’t see java:/jaas/testAppSecurity in my JNDIView. I must be missing an obvious step somewhere. Emily -Original Message- From: Emily Short Sent: Wednesday, October 09, 2002 12:20 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] security_check I am trying to get j_security_check working but for some reason I am allowed to login no matter what bogus username and password I enter (or if I enter none at all). I want to use the DefaultDB (Hypersonic) in order to authenticate, but I haven’t modified the DB at all yet so it seems to me that any attempt to login should fail. I do not see any activity on the server when I log in. Your help is appreciated login-config.xml: java:/DefaultDS SELECT passwd FROM Users WHERE username=? SELECT user_roles from UserRoles where username=? web.xml: Secure Content An example security config that only allows users with the role AuthorizedUser to access restricted content /restricted/* AuthorizedUser FORM testAppSecurity /login.jsp /login-error.html Role required to access restricted content AuthorizedUser jboss-web.xml java:/jaas/testAppSecurity / login.jsp snippet: Username: Password:
RE: [JBoss-user] security_check
More info about this problem: I am using JBoss 3.0.3/Jetty and can’t see java:/jaas/testAppSecurity in my JNDIView. I must be missing an obvious step somewhere. Emily -Original Message- From: Emily Short Sent: Wednesday, October 09, 2002 12:20 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] security_check I am trying to get j_security_check working but for some reason I am allowed to login no matter what bogus username and password I enter (or if I enter none at all). I want to use the DefaultDB (Hypersonic) in order to authenticate, but I haven’t modified the DB at all yet so it seems to me that any attempt to login should fail. I do not see any activity on the server when I log in. Your help is appreciated login-config.xml: java:/DefaultDS SELECT passwd FROM Users WHERE username=? SELECT user_roles from UserRoles where username=? web.xml: Secure Content An example security config that only allows users with the role AuthorizedUser to access restricted content /restricted/* AuthorizedUser FORM testAppSecurity /login.jsp /login-error.html Role required to access restricted content AuthorizedUser jboss-web.xml java:/jaas/testAppSecurity / login.jsp snippet: Username: Password:
[JBoss-user] security_check
I am trying to get j_security_check working but for some reason I am allowed to login no matter what bogus username and password I enter (or if I enter none at all). I want to use the DefaultDB (Hypersonic) in order to authenticate, but I haven’t modified the DB at all yet so it seems to me that any attempt to login should fail. I do not see any activity on the server when I log in. Your help is appreciated login-config.xml: java:/DefaultDS SELECT passwd FROM Users WHERE username=? SELECT user_roles from UserRoles where username=? web.xml: Secure Content An example security config that only allows users with the role AuthorizedUser to access restricted content /restricted/* AuthorizedUser FORM testAppSecurity /login.jsp /login-error.html Role required to access restricted content AuthorizedUser jboss-web.xml java:/jaas/testAppSecurity / login.jsp snippet: Username: Password:
[JBoss-user] RE: weird deployment issue...help!
So sorry. My fault, nevermind. Don’t you hate that? -Original Message- From: Emily Short [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:16 PM To: '[EMAIL PROTECTED]' Subject: weird deployment issue...help! I am trying to deploy a war, and it seems to be working when I war my files using the command line. However, when I make the war file using ant, the deployment looks different. I have unpacked both wars and their contents are identical, I PROMISE, save for the Manifest file, where the Created-By fields are different. Here are the deployment logs: It looks like Axis’ Admin servlet is being deployed in the first case and not in the second? Why on earth would how the war is created make a difference? Command line version of glue.war deployed: 11:48:02,380 INFO [MainDeployer] Starting deployment of package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/deploy/glue.war 11:48:02,570 INFO [EmbeddedCatalinaServiceSX] deploy, ctxPath=/glue, warUrl=file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/tmp/deploy/server/all/deploy/glue.war/101.glue.war 11:48:02,580 INFO [Engine] WebappLoader[/glue]: Deploying class repositories to work directory C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue 11:48:02,590 INFO [Engine] WebappLoader[/glue]: Deploy JAR /WEB-INF/lib/slc-server.jar to C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\lib\slc-server.jar 11:48:02,600 INFO [Engine] StandardManager[/glue]: Seeding random number generator class java.security.SecureRandom 11:48:02,600 INFO [Engine] StandardManager[/glue]: Seeding of random number generator has been completed 11:48:02,781 INFO [Engine] ContextConfig[/glue]: Added certificates -> request attribute Valve 11:48:02,941 INFO [EmbeddedCatalinaServiceSX] Using Java2 parent classloader delegation: true 11:48:02,941 INFO [Engine] StandardWrapper[/glue:default]: Loading container servlet default 11:48:02,951 INFO [Engine] default: init 11:48:02,951 INFO [Engine] StandardWrapper[/glue:invoker]: Loading container servlet invoker 11:48:02,961 INFO [Engine] invoker: init 11:48:02,961 INFO [Engine] jsp: init 11:48:03,041 INFO [Engine] AdminServlet: init 11:48:03,041 INFO [MainDeployer] Deployed package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/deploy/glue.war ant’s version of glue.war deployed: 11:47:18,280 INFO [MainDeployer] Starting deployment of package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/deploy/glue.war 11:47:18,450 INFO [EmbeddedCatalinaServiceSX] deploy, ctxPath=/glue, warUrl=file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/tmp/deploy/server/all/deploy/glue.war/97.glue.war 11:47:18,460 INFO [Engine] WebappLoader[/glue]: Deploying class repositories to work directory C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue 11:47:18,470 INFO [Engine] WebappLoader[/glue]: Deploy class files /WEB-INF/classes to C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\classes 11:47:18,470 INFO [Engine] WebappLoader[/glue]: Deploy JAR /WEB-INF/lib/GLUE-STD.jar to C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\lib\GLUE-STD.jar 11:47:18,520 INFO [Engine] WebappLoader[/glue]: Deploy JAR /WEB-INF/lib/slc-server.jar to C:\brain\Projects\System3\src \server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\lib\slc-server.jar 11:47:18,530 INFO [Engine] StandardManager[/glue]: Seeding random number generator class java.security.SecureRandom 11:47:18,530 INFO [Engine] StandardManager[/glue]: Seeding of random number generator has been completed 11:47:18,681 INFO [Engine] ContextConfig[/glue]: Added certificates -> request attribute Valve 11:47:19,021 INFO [EmbeddedCatalinaServiceSX] Using Java2 parent classloader delegation: true 11:47:19,021 INFO [Engine] StandardWrapper[/glue:default]: Loading container servlet default 11:47:19,021 INFO [Engine] default: init 11:47:19,071 INFO [Engine] glue: init 11:47:20,784 INFO [STDOUT] [STARTUP] GLUE standard 3.2.1 (c) 2001-2002 The Mind Electric 11:47:20,834 INFO [STDOUT] [DEPLOYMENT] : publishing web service on path 'system/application' 11:47:20,854 INFO [STDOUT] [DEPLOYMENT] : publishing web service on path 'UploadManager' 11:47:21,034 INFO [Engine] StandardWrapper[/glue:invoker]: Loading container servlet invoker 11:47:21,034 INFO [Engine] invoker: init 11:47:21,034 INFO [Engine] jsp: init 11:47:21,084 INFO [MainDeployer] Deployed package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/serv er/all/deploy/glue.war
[JBoss-user] weird deployment issue...help!
I am trying to deploy a war, and it seems to be working when I war my files using the command line. However, when I make the war file using ant, the deployment looks different. I have unpacked both wars and their contents are identical, I PROMISE, save for the Manifest file, where the Created-By fields are different. Here are the deployment logs: It looks like Axis’ Admin servlet is being deployed in the first case and not in the second? Why on earth would how the war is created make a difference? Command line version of glue.war deployed: 11:48:02,380 INFO [MainDeployer] Starting deployment of package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/deploy/glue.war 11:48:02,570 INFO [EmbeddedCatalinaServiceSX] deploy, ctxPath=/glue, warUrl=file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/tmp/deploy/server/all/deploy/glue.war/101.glue.war 11:48:02,580 INFO [Engine] WebappLoader[/glue]: Deploying class repositories to work directory C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue 11:48:02,590 INFO [Engine] WebappLoader[/glue]: Deploy JAR /WEB-INF/lib/slc-server.jar to C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\lib\slc-server.jar 11:48:02,600 INFO [Engine] StandardManager[/glue]: Seeding random number generator class java.security.SecureRandom 11:48:02,600 INFO [Engine] StandardManager[/glue]: Seeding of random number generator has been completed 11:48:02,781 INFO [Engine] ContextConfig[/glue]: Added certificates -> request attribute Valve 11:48:02,941 INFO [EmbeddedCatalinaServiceSX] Using Java2 parent classloader delegation: true 11:48:02,941 INFO [Engine] StandardWrapper[/glue:default]: Loading container servlet default 11:48:02,951 INFO [Engine] default: init 11:48:02,951 INFO [Engine] StandardWrapper[/glue:invoker]: Loading container servlet invoker 11:48:02,961 INFO [Engine] invoker: init 11:48:02,961 INFO [Engine] jsp: init 11:48:03,041 INFO [Engine] AdminServlet: init 11:48:03,041 INFO [MainDeployer] Deployed package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/deploy/glue.war ant’s version of glue.war deployed: 11:47:18,280 INFO [MainDeployer] Starting deployment of package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/deploy/glue.war 11:47:18,450 INFO [EmbeddedCatalinaServiceSX] deploy, ctxPath=/glue, warUrl=file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/server/all/tmp/deploy/server/all/deploy/glue.war/97.glue.war 11:47:18,460 INFO [Engine] WebappLoader[/glue]: Deploying class repositories to work directory C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue 11:47:18,470 INFO [Engine] WebappLoader[/glue]: Deploy class files /WEB-INF/classes to C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\classes 11:47:18,470 INFO [Engine] WebappLoader[/glue]: Deploy JAR /WEB-INF/lib/GLUE-STD.jar to C:\brain\Projects\System3\src\server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\lib\GLUE-STD.jar 11:47:18,520 INFO [Engine] WebappLoader[/glue]: Deploy JAR /WEB-INF/lib/slc-server.jar to C:\brain\Projects\System3\src \server-env\jboss-4.0.0alpha\catalina\work\MainEngine\localhost\glue\WEB-INF\lib\slc-server.jar 11:47:18,530 INFO [Engine] StandardManager[/glue]: Seeding random number generator class java.security.SecureRandom 11:47:18,530 INFO [Engine] StandardManager[/glue]: Seeding of random number generator has been completed 11:47:18,681 INFO [Engine] ContextConfig[/glue]: Added certificates -> request attribute Valve 11:47:19,021 INFO [EmbeddedCatalinaServiceSX] Using Java2 parent classloader delegation: true 11:47:19,021 INFO [Engine] StandardWrapper[/glue:default]: Loading container servlet default 11:47:19,021 INFO [Engine] default: init 11:47:19,071 INFO [Engine] glue: init 11:47:20,784 INFO [STDOUT] [STARTUP] GLUE standard 3.2.1 (c) 2001-2002 The Mind Electric 11:47:20,834 INFO [STDOUT] [DEPLOYMENT] : publishing web service on path 'system/application' 11:47:20,854 INFO [STDOUT] [DEPLOYMENT] : publishing web service on path 'UploadManager' 11:47:21,034 INFO [Engine] StandardWrapper[/glue:invoker]: Loading container servlet invoker 11:47:21,034 INFO [Engine] invoker: init 11:47:21,034 INFO [Engine] jsp: init 11:47:21,084 INFO [MainDeployer] Deployed package: file:/C:/brain/Projects/System3/src/server-env/jboss-4.0.0alpha/serv er/all/deploy/glue.war
[JBoss-user] glue and jboss?
Has anyone successfully deployed GLUE in Jboss? I was using Axis but my client needs to be jdk1.1.8 compatible (!!!) so I need to switch to GLUE. I am a little lost about how to deploy GLUE. I’ve made a glue.war file and deployed it, but there’s not much in it right now. Anyone with a configuration I can take a look at? Thanks, Emily
[JBoss-user] wsdl generation
I am using JBoss4.0.0alpha with axis beta2. Is there a way to generate and expose wsdl files for my web services? I think I have read about this before but can’t find it in the documentation. Thanks, Emily
[JBoss-user] building new jboss-net.sar
Hi all, I’d like to deploy Axis with tomcat on jboss4.0.0alpha now that Axis RC1 is integrating. I’m trying to rebuild the jboss-net.sar to use Catalina, but having difficulty because it seems like things have changed since Bruce posted this http://www.csd.abdn.ac.uk/~bscharla/soap.html. Could someone please post the steps required to build jboss-net.sar so that AxisRC1 is integrated and so that it uses Tomcat? Thanks, Emily
[JBoss-user] build error jboss 4.0.0alpha
I got the build.xml fixes from cvs, but now when I build (with jdk1.4.0)
I get this error:
docs-todo:
[mkdir] Created dir: C:\jboss-src\jboss-all\jmx\output\todo
[execmodules] Running
[execmodules] Create info lists for todo tags
[execmodules] (TemplateEngine.invokeMethod 515 ) Invoking method
failed: xdoclet.tagshandler.ClassTagsHandler.fo
rAllClasses, line=15 of template file:
jar:file:C:\jboss-src\jboss-all\thirdparty\xdoclet\xdoclet\lib\xdoclet-x
doclet-mo
dule.jar!/xdoclet/modules/doc/info/resources/all-classes.xdt
[execmodules] java.lang.reflect.InvocationTargetException
[execmodules] null
[execmodules] at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod)ParameterImpl
instances: 20
[execmodules] MethodImpl instances: 2719
[execmodules] ConstructorImpl instances: 404
[execmodules] SimpleNode instances: 0
[execmodules] SourceClass instances: 450
[execmodules] XDoc instances:0
[execmodules] DefaultXTag instances: 0
[execmodules] BinaryClass instances: 88
[execmodules] UnknownClass instances:49
[execmodules] Total memory:63
[execmodules] Free memory:0
[execmodules] Try to increase heap size. Can be done by defining
ANT_OPTS=-Xmx640m
[execmodules] See the JDK tooldocs.
BUILD FAILED
file:C:/jboss-src/jboss-all/jmx/../tools/etc/buildfragments/documentatio
n.ent:73: null
I tried defining ANT_OPTS as it suggested but that didn't seem to help.
Any advice?
Emily
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Emily Short
Sent: Monday, September 09, 2002 2:38 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] build error jboss 4.0.0alpha
Thanks so much David! When should I check back for the fixes?
Emily
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of David
Jencks
Sent: Monday, September 09, 2002 1:09 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] build error jboss 4.0.0alpha
You are ok, I'll fix the build scripts. I didn't try build-all when I
updated xdoclet and missed these targets.
thanks
david jencks
On 2002.09.09 15:30:46 -0400 Emily Short wrote:
> Hi,
>
>
>
> I'm using ant 1.4.1 and have used it to build jboss 4.0.0alpha before,
> so I don't know what happened since then. Now, however, when I run
> "build all" from the jboss-all/build it fails whenever it hits
something
> like this
>
>
>
>
>
>
> depends="docs-todo-check"
>
> unless="docs-todo.disable">
>
>
>
>
> destdir="${build.todo}"
>
> classpathref="xdoclet.task.classpath">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> giving the error:
>
>
>
> BUILD FAILED
>
> file:C:/jboss-src/jboss-all/common/build.xml:346: The 'sourcepath'
> attribute can not be used anymore. Use to define the files
to
> parse
>
>
>
> I'd rather not go through all the build files and change sourcepath
> attributes to nested fileset tags. Is there something I'm doing
wrong?
>
>
>
> Thanks,
> Emily
>
>
>
>
>
>
>
>
>
>
>
> <!--
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> {margin:0in;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman";}
> a:link, span.MsoHyperlink
> {color:blue;
> text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> {color:purple;
> text-decoration:underline;}
> span.EmailStyle17
> {font-family:Arial;
> color:windowtext;}
> @page Section1
> {size:8.5in 11.0in;
> margin:1.0in 1.25in 1.0in 1.25in;}
> div.Section1
> {page:Section1;}
> -->
>
>
>
>
>
>
>
>
> Hi,
>
>
>
> I’m using ant 1.4.1 and have used it to build
> jboss
> 4.0.0alpha before, so I don’t know what happened since
then.
> Now,
> however, when I run “build all” from the jboss-all/build
it
> fails
> whenever it hits something like this
>
>
>
> <!-- Generate TODO list from @todo tags
> -->
>
> <target name="docs-todo"
>
>
>
;
>
> depends="docs-todo-check"
>
>
;
>
> unless="docs-todo.disable">
>
>
>
> <todo
> sourcepath="${source.java}"
>
>
;
> destdir="${build.todo}"
>
>
;
> classpathref=&quo
RE: [JBoss-user] build error jboss 4.0.0alpha
Thanks so much David! When should I check back for the fixes?
Emily
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of David
Jencks
Sent: Monday, September 09, 2002 1:09 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] build error jboss 4.0.0alpha
You are ok, I'll fix the build scripts. I didn't try build-all when I
updated xdoclet and missed these targets.
thanks
david jencks
On 2002.09.09 15:30:46 -0400 Emily Short wrote:
> Hi,
>
>
>
> I'm using ant 1.4.1 and have used it to build jboss 4.0.0alpha before,
> so I don't know what happened since then. Now, however, when I run
> "build all" from the jboss-all/build it fails whenever it hits
something
> like this
>
>
>
>
>
>
> depends="docs-todo-check"
>
> unless="docs-todo.disable">
>
>
>
>
> destdir="${build.todo}"
>
> classpathref="xdoclet.task.classpath">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> giving the error:
>
>
>
> BUILD FAILED
>
> file:C:/jboss-src/jboss-all/common/build.xml:346: The 'sourcepath'
> attribute can not be used anymore. Use to define the files
to
> parse
>
>
>
> I'd rather not go through all the build files and change sourcepath
> attributes to nested fileset tags. Is there something I'm doing
wrong?
>
>
>
> Thanks,
> Emily
>
>
>
>
>
>
>
>
>
>
>
> <!--
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> {margin:0in;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman";}
> a:link, span.MsoHyperlink
> {color:blue;
> text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> {color:purple;
> text-decoration:underline;}
> span.EmailStyle17
> {font-family:Arial;
> color:windowtext;}
> @page Section1
> {size:8.5in 11.0in;
> margin:1.0in 1.25in 1.0in 1.25in;}
> div.Section1
> {page:Section1;}
> -->
>
>
>
>
>
>
>
>
> Hi,
>
>
>
> I’m using ant 1.4.1 and have used it to build
> jboss
> 4.0.0alpha before, so I don’t know what happened since
then.
> Now,
> however, when I run “build all” from the jboss-all/build
it
> fails
> whenever it hits something like this
>
>
>
> <!-- Generate TODO list from @todo tags
> -->
>
> <target name="docs-todo"
>
>
>
;
>
> depends="docs-todo-check"
>
>
;
>
> unless="docs-todo.disable">
>
>
>
> <todo
> sourcepath="${source.java}"
>
>
;
> destdir="${build.todo}"
>
>
;
> classpathref="xdoclet.task.classpath">
>
>
>
> <fileset
> dir="${source.java}">
>
>
<include
> name="**/*.java"/>
>
>
> </fileset>
>
>
>
>
> <info/>
>
> </todo>
>
> </target>
>
>
>
>
>
> giving the error:
>
>
>
> BUILD FAILED
>
> file:C:/jboss-src/jboss-all/common/build.xml:346:
The
> 'sourcepath'
> attribute can not be used anymore. Use <fileset> to define
> the
> files to parse
>
>
>
> I’d rather not go through all the build files
> and
> change sourcepath attributes to nested fileset tags. Is there
> something I’m
> doing wrong?
>
>
>
> Thanks,
> Emily
>
>
>
>
>
>
>
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] build error jboss 4.0.0alpha
Nevermind, when I downloaded the nightly
snapshot I was able to build.
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Emily Short
Sent: Monday, September 09, 2002
12:31 PM
To:
[EMAIL PROTECTED]
Subject: [JBoss-user] build error
jboss 4.0.0alpha
Hi,
I’m using ant 1.4.1 and have
used it to build jboss 4.0.0alpha before, so I don’t know what happened
since then. Now, however, when I run “build all” from the
jboss-all/build it fails whenever it hits something like this
depends="docs-todo-check"
unless="docs-todo.disable">
destdir="${build.todo}"
classpathref="xdoclet.task.classpath">
giving the error:
BUILD FAILED
file:C:/jboss-src/jboss-all/common/build.xml:346:
The 'sourcepath' attribute can not be used anymore. Use
to define the files to parse
I’d rather not go through all
the build files and change sourcepath attributes to nested fileset tags.
Is there something I’m doing wrong?
Thanks,
Emily
[JBoss-user] build error jboss 4.0.0alpha
Hi,
I’m using ant 1.4.1 and have used it to build jboss
4.0.0alpha before, so I don’t know what happened since then. Now,
however, when I run “build all” from the jboss-all/build it fails
whenever it hits something like this
depends="docs-todo-check"
unless="docs-todo.disable">
destdir="${build.todo}"
classpathref="xdoclet.task.classpath">
giving the error:
BUILD FAILED
file:C:/jboss-src/jboss-all/common/build.xml:346: The 'sourcepath'
attribute can not be used anymore. Use to define the
files to parse
I’d rather not go through all the build files and
change sourcepath attributes to nested fileset tags. Is there something I’m
doing wrong?
Thanks,
Emily
[JBoss-user] server log warning
I get this warning in my boot log: WARN [org.jboss.resource.connectionmanager.XATxConnectionManager] WARNING: UPDATE YOUR SecurityDomainJndiName! REMOVE java:/jaas/ What does this mean? I have played around with the tomcat4-service.xml and the securityDomainName there because I have SSL set up. Thanks, Emily
RE: [JBoss-user] JBoss-3.0.2 released
When will Axis beta 3 be integrated? I built jboss 4.0.0alpha and beta3 is not yet integrated. I heard this would be done by the end of the summer? Thanks, Emily -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Tuesday, August 27, 2002 12:45 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [JBoss-user] JBoss-3.0.2 released The JBoss-3.0.2 release is available. This includes bug fixes as well as enhancements to security with SSL support for JMS, clustered EJBs, and extensions to the SRP authentication protocol. In addition there is now support for JNDI/HTTP and RMI/HTTP. The release may be obtained from SourceForge: http://sourceforge.net/project/showfiles.php?group_id=22866 The release notes may be viewed here: http://sourceforge.net/project/shownotes.php?release_id=107455 Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] JMS-attempt to pop empty stack warnings/commit exceptions
I have some code that adds messages to a
JMS queue and my listener seems to be receiving them ok. However, when I look
at the server log I am getting some warnings and exceptions:
09:53:37,864
WARN [TCLStack] Attempt to pop empty stack ingored
java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:79)
at java.util.Stack.pop(Stack.java:61)
at org.jboss.util.TCLStack.pop(TCLStack.java:96)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:696)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:980)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:238)
at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:561)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:377)
at org.jboss.mq.SpySession.run(SpySession.java:252)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:642)
at java.lang.Thread.run(Thread.java:536)
09:53:37,874
ERROR [StdServerSession] failed to commit/rollback
javax.transaction.xa.XAException
at org.jboss.mq.SpyXAResource.commit(SpyXAResource.java:105)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:289)
at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:561)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:377)
at org.jboss.mq.SpySession.run(SpySession.java:252)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:642)
at java.lang.Thread.run(Thread.java:536)
Any ideas why I am getting this? When I restart the server the messages are
still in the queue and onMessage is called again for each of them, which means
the messages are not being removed from the queue I assume. I am using JBoss
3.0.0 and here are the relevant snippets of code:
//add message to queue
MapMessage msg = qSess.createMapMessage();
msg.setJMSCorrelationID("UploadManager");
qSender.send(msg, javax.jms.DeliveryMode.PERSISTENT, javax.jms.Message.DEFAULT_PRIORITY,
0 );
AND
//get message off of the queue
public void onMessage(Message message) {
if(! (message instanceof MapMessage)){
System.err.println("wrong type of message
received");
return;
}
MapMessage msg = (MapMessage)message;
System.err.println("Got Message: " + msg.toString());
try{
message.acknowledge();
//message processing that seems to work
}catch(JMSException e){
e.printStackTrace(System.err);
}
}
Your help is greatly appreciated,
Emily
