Re: [JBoss-dev] Why does www.jboss.org need to be up and workingto boot JBoss?
It seems that you have an xml file which references its document type as an external entity on jboss.org. Judging from the dtd's name it is probabely a file like jbosscmp-jdbc.xml in on of your EJB's deployment descriptors. You could modify that file so thats its doctype references a local file, or simply has a doctype like !DOCTYPE jbosscmp-jdbc as it sould be done in standardjbosscmp-jdbc.xml in your servers config dir. (...or disable validation in the crimson parser.) Michael Bartmann Jason Dillon wrote: I am getting exceptions like the follwing because for some reason www.jboss.org is down. Sup with that? --jason 22:36:58,880 ERROR [XmlFileLoader] External entity not found: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd.:-1:4 java.net.ConnectException: Connection timed out at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:2 796) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1155) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.ja va:185) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:86) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:257) at org.jboss.metadata.XmlFileLoader.getDocumentFromURL(XmlFileLoader.java:2 26) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:211) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoader.load(JDBCXmlFi leLoader.java:74) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDBCEntityMetaData(J DBCStoreManager.java:677) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.initStoreManager(JDBCSto reManager.java:389) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.j ava:339) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager. java:198) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:376) at org.jboss.ejb.Container.invoke(Container.java:764) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController .java:976) at $Proxy7.start(Unknown Source) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is XAResource thread-safe?
Hi, As the subject says -- is XAResource thread-safe or we need to serialize access to it when accessing the same XAResource instance from multiple threads? I could not find explicit answer to that question in the docs, but did find that oracle xa implementation is *not* thread safe and SF #614116 is cause by simultaneous calls to xares.end or xares.start and xares.rollback from two different threads. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is XAResource thread-safe?
Its clear that is is allowed by the JTA spec: jta-1_0_1 3.4.3 Thread of Control The X/OpenXAinterface specifies that the transaction association related xa calls must be invoked from the same thread context. This thread-of-control requirement is not Java Transaction API applicable to the object-oriented component-based application run-time environment, in which application threads are dispatched dynamically at method invocation time. Different Java threads may be using the same connection resource to access the resource manager if the connection spans multiple method invocation. Depending on the implementation of the application server, different Java threads may be involved with the same XAResource object. The resource context and the transaction context may be operated independent of thread context. This means, for example, that it's possible for different threads to be invoking the XAResource.start and XAResource.end methods. If the application server allows multiple threads to use a single XAResource object and the associated connection to the resource manager, it is the responsibility of the application server to ensure that there is only one transaction context associated with the resource at any point of time. Thus the XAResource interface specified in this document requires that the resource managers be able to support the two-phase commit protocol from any thread context. /jta-1_0_1 Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 28, 2002 6:46 AM Subject: [JBoss-dev] Is XAResource thread-safe? Hi, As the subject says -- is XAResource thread-safe or we need to serialize access to it when accessing the same XAResource instance from multiple threads? I could not find explicit answer to that question in the docs, but did find that oracle xa implementation is *not* thread safe and SF #614116 is cause by simultaneous calls to xares.end or xares.start and xares.rollback from two different threads. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is XAResource thread-safe?
Scott,
I read this and agree that it sounds like XAResources are required to be
thread safe however this requirement is not explicitly stated. Note that
with oracle you can access XAResource instance from as many threads as
you wish as long as you do synchronized(xares) { xares.(); }.
Anyways, to fix 614116 I am planning to change XAOracleManagedConnection
on HEAD to have synchronized for all XAResource calls and will provide
external XAResource wrapper with similar behaviour for 3.0 and 3.2.
Scott M Stark wrote:
Its clear that is is allowed by the JTA spec:
jta-1_0_1
3.4.3 Thread of Control
The X/OpenXAinterface specifies that the transaction association related xa calls
must
be invoked from the same thread context. This thread-of-control requirement is not
Java Transaction API applicable to the object-oriented component-based application
run-time environment, in which application threads are dispatched dynamically at
method invocation time.
Different Java threads may be using the same connection resource to access the
resource manager if the connection spans multiple method invocation. Depending on
the implementation of the application server, different Java threads may be involved
with the same XAResource object. The resource context and the transaction context
may be operated independent of thread context. This means, for example, that it's
possible for different threads to be invoking the XAResource.start and
XAResource.end methods.
If the application server allows multiple threads to use a single XAResource object
and
the associated connection to the resource manager, it is the responsibility of the
application server to ensure that there is only one transaction context associated
with
the resource at any point of time.
Thus the XAResource interface specified in this document requires that the resource
managers be able to support the two-phase commit protocol from any thread context.
/jta-1_0_1
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Igor Fedorenko [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, September 28, 2002 6:46 AM
Subject: [JBoss-dev] Is XAResource thread-safe?
Hi,
As the subject says -- is XAResource thread-safe or we need to serialize
access to it when accessing the same XAResource instance from multiple
threads?
I could not find explicit answer to that question in the docs, but did
find that oracle xa implementation is *not* thread safe and SF #614116
is cause by simultaneous calls to xares.end or xares.start and
xares.rollback from two different threads.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is XAResource thread-safe?
Is it really thread safety or is this bug caused by a version of jboss that attempts to restart a suspended xid before committing/rollback while the connection/xaresource is in the middle of a second tx? We used to call start(noflags) end(suspend) //release back to pool, so another tx could get the cx start(resume)//whether or not there was a tx associated!! commit/rollback I'm not sure which jboss versions this is fixed in. thanks david jencks On 2002.09.28 09:46:13 -0400 Igor Fedorenko wrote: Hi, As the subject says -- is XAResource thread-safe or we need to serialize access to it when accessing the same XAResource instance from multiple threads? I could not find explicit answer to that question in the docs, but did find that oracle xa implementation is *not* thread safe and SF #614116 is cause by simultaneous calls to xares.end or xares.start and xares.rollback from two different threads. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss?
can we stop this XCHML crazyness? this is dumb and un-user friendly. XML is bullshit. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michael Bartmann Sent: Saturday, September 28, 2002 2:56 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss? It seems that you have an xml file which references its document type as an external entity on jboss.org. Judging from the dtd's name it is probabely a file like jbosscmp-jdbc.xml in on of your EJB's deployment descriptors. You could modify that file so thats its doctype references a local file, or simply has a doctype like !DOCTYPE jbosscmp-jdbc as it sould be done in standardjbosscmp-jdbc.xml in your servers config dir. (...or disable validation in the crimson parser.) Michael Bartmann Jason Dillon wrote: I am getting exceptions like the follwing because for some reason www.jboss.org is down. Sup with that? --jason 22:36:58,880 ERROR [XmlFileLoader] External entity not found: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd.:-1:4 java.net.ConnectException: Connection timed out at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java :2 796) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1155) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuil derImpl.ja va:185) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:86) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:257) at org.jboss.metadata.XmlFileLoader.getDocumentFromURL(XmlFileLoa der.java:2 26) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:211) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoader.load (JDBCXmlFi leLoader.java:74) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDBCEntity MetaData(J DBCStoreManager.java:677) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.initStoreManag er(JDBCSto reManager.java:389) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStor eManager.j ava:339) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersisten ceManager. java:198) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:376) at org.jboss.ejb.Container.invoke(Container.java:764) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(Service Controller .java:976) at $Proxy7.start(Unknown Source) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Gosling has Web Services right...
Web services, web schmervices marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of danch Sent: Friday, September 27, 2002 8:03 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Gosling has Web Services right... Yup! 'Web Services' is just RPC running on an inefficient transport protocol running on an inefficient link protocol, with no mechanism for credential or transaction propogation, and 'best effort' levels of QOS. Oh, by the way - Web Services also exposes a lot of the detail of the protocol to the programmer, just to really piss off the people who though writing then compiling IDL was a pain in the ass. Now, of course, you get to choose between compiling or generating the IDL, which is so chock full of fun little XML quirks as to be unreadable by normal humans anyway. Bah! The more that things change, the more they get worse. -danch Bill Burke wrote: What I've been saying all along... People have been building Web services under different names for 20 or 30 years, he explains. We've been building distributed systems for years out using CORBA and RMI and all of that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-609902 ] java.lang.LinkageError: loader ...
Bugs item #609902, was opened at 2002-09-16 05:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=609902group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: Later Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Scott M Stark (starksm) Summary: java.lang.LinkageError: loader ... Initial Comment: Assume some application (client) deployed into jboss uses EJBs deployed in another application (server). If client's interfaces declared as throwing some custom exception (in this case this exception has to be present in both client and server jars/wars/ears) a java.lang.LinkageError may occur when trying to invoke inside client methods of server's interface those throwing that custom exception: java.lang.LinkageError: loader constraints violated when linking xxx/xxx/Clazz class In my case the exception occurs after I re-deploy the client application. Only by restarting jboss it is possible to restore the normal functionality once the error is occured. I suppose this is because the custom exception class isn't loaded by a common classloader as all interface classes, return type classes etc. are. This problem doesn't appear in jboss 2.4.x. EJB spec allows custom exceptions so I think this is a bug, not a feature. -- Comment By: Scott M Stark (starksm) Date: 2002-09-28 13:08 Message: Logged In: YES user_id=175228 In 3.0 this is just a packaging issue. 2.4 would automatically downgrade communcation to marshall call between incompatible class loading contexts. 3.0 does not do this so you simply need to place the shared classes into a common jar and drop it in the lib directory. 3.2 will try to resolve these conflicts and create scoped class loading contexts as neccessary. -- Comment By: Alexei Yudichev (sflexus) Date: 2002-09-17 06:55 Message: Logged In: YES user_id=345880 Allright I found that this is a feature of a classloaders architecture which counts on there're no duplicate classes across deployed applications. But could the error be handled somehow? -- Comment By: Alexei Yudichev (sflexus) Date: 2002-09-16 09:28 Message: Logged In: YES user_id=345880 I have changed my custom exception to JavaMail's AddressException and the problem still persists. Then I've removed application exceptions entirely and at last everything started to work well. So the problem doesn't depend on whether declared in bean interface exceptions are packaged with application or they are standard exceptions loaded from jbosshome/server/name/lib jars. -- Comment By: Alexei Yudichev (sflexus) Date: 2002-09-16 08:52 Message: Logged In: YES user_id=345880 I have changed my custom exception to JavaMail's AddressException and the problem still persists. Then I've removed application exceptions entirely and at last everything started to work well. So the problem doesn't depend on whether declared in bean interface exceptions are packaged with application or they are standard exceptions loaded from jbosshome/server/name/lib jars. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=609902group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 28-September-2002
Number of tests run: 937
Successful tests: 925
Errors:10
Failures: 2
[time of test: 28 September 2002 13:11 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 28-September-2002
Number of tests run: 946
Successful tests: 942
Errors:2
Failures: 2
[time of test: 28 September 2002 15:17 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss?
marc f XML is bullshit. What? - Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss?
Based on the XmlFileLoader.getDocument(XmlFileLoader.java:257) line number this is the current 3.0 source and this does have a local entity resolver for jbosscmp-jdbc_3_0.dtd provided you are using the correct public entity name: !DOCTYPE jbosscmp-jdbc PUBLIC -//JBoss//DTD JBOSSCMP-JDBC 3.0//EN http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd; Does your jbosscmp-jdbc.xml DOCTYPE look this this? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 27, 2002 10:40 PM Subject: [JBoss-dev] Why does www.jboss.org need to be up and working to boot JBoss? I am getting exceptions like the follwing because for some reason www.jboss.org is down. Sup with that? --jason 22:36:58,880 ERROR [XmlFileLoader] External entity not found: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd.:-1:4 java.net.ConnectException: Connection timed out at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:2 796) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1155) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.ja va:185) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:86) at org.jboss.metadata.XmlFileLoader.getDocument(XmlFileLoader.java:257) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(HEAD Matrix2) Testsuite Results: 29-September-2002
Number of tests run: 962 Successful tests: 936 Errors:22 Failures: 4 [time of test: 29 September 2002 2:9 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-34] Useful resources: - http://lubega.com/testarchive/sun_jdk131_03 for the junit report of this test. - http://lubega.com/testarchive/sun_jdk131_03/logs/ for the logs for this test. - http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 28-September-2002
Number of tests run: 946
Successful tests: 942
Errors:2
Failures: 2
[time of test: 28 September 2002 18:38 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608837 ] Can't deploy default-package MBean
Bugs item #608837, was opened at 2002-09-13 03:41
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=608837group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alasdair MacLeod (macleoa)
Assigned to: Scott M Stark (starksm)
Summary: Can't deploy default-package MBean
Initial Comment:
Windows2000 Professional
java -version
java version 1.4.0
Java(TM) 2 Runtime Environment, Standard Edition
(build 1.4.0-b92
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed
mode)
Jboss3_0_2 pulled from CVS.
Couldn't get console traces but include server.log
instead.
Log messages with AML are my additions.
It seems you can't deploy (via user-service.xml) an
MBean if it's package is the default package. The
org.jboss.system.ServiceCreator reports it cannot find
the class even though it seems to have found the jar ok.
E.g. public class Ali implements AliMBean {...} cannot
be deployed but will deploy once moved to
package a.b.c;
I include the user-service.xml and log files for each
scenario. It looks like the classloader is throwing an
exception when loadClass() is called. Haven't had time
to pursue it further but will try if someone points me in
the right direction (I don't know anything about the
JBoss classloader framework).
--
Comment By: Scott M Stark (starksm)
Date: 2002-09-28 19:25
Message:
Logged In: YES
user_id=175228
Fixed for the 3.0.3 release
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=608837group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608790 ] [3.0.2]Hot deploy of unpackaged SAR bug?
Bugs item #608790, was opened at 2002-09-13 00:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=608790group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 4 Submitted By: Chris Kimpton (kimptoc) Assigned to: Nobody/Anonymous (nobody) Summary: [3.0.2]Hot deploy of unpackaged SAR bug? Initial Comment: Hi, I was deploying my sar in the unpackaged form, like the jbossweb.sar directory. Deployment works fine. The problem I hit with re-deployment (that is deleting the directory and copying it over again) is that messages appear in the jboss log, so you think it is doing a redployment, but it restarts the old code, not a new version. I was changing the log messages from the code and the old ones kept being displayed. But it works fine if I deploy as a packaged sar file. Is this a known problem? Regards, Chris -- Comment By: Scott M Stark (starksm) Date: 2002-09-28 19:29 Message: Logged In: YES user_id=175228 On what operating system? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=608790group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-613882 ] Another Jetty reploy issue
Bugs item #613882, was opened at 2002-09-24 08:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613882group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Another Jetty reploy issue Initial Comment: The testBadWarRedeploy unit test of the org.jboss.test.web.test.WebIntegrationUnitTestCase is failing to see the redeployed war. The steps performed by this testcase are equivalent to these manual steps done from the jboss-all/testsuite directory: testsuite 232cp output/lib/bad- web.war ../build/output/jboss- 3.2.0beta2/server/default/deploy/ testsuite 233rm ../build/output/jboss- 3.2.0beta2/server/default/deploy/bad-web.war rm: remove `../build/output/jboss- 3.2.0beta2/server/default/deploy/bad-web.war'? y testsuite 234cp output/lib/good- web.war ../build/output/jboss- 3.2.0beta2/server/default/deploy/ testsuite 235wget http://localhost:8080/redeploy/index.html --08:28:52-- http://localhost:8080/redeploy/index.html = `index.html' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 Not Found 08:28:52 ERROR 404: Not Found. The output from the server console on the deployment of the good-web.war file is: 08:28:14,950 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0beta2/server/default/deploy/good-web.w ar 08:28:15,071 WARN [jbossweb] A WebApplication is already deployed in context '/ redeploy' - proceed at your own risk. 08:28:15,131 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=4,context=/redeploy 08:28:15,161 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0beta2/server/default/tmp/deploy/server/default/deplo y/good-web .war/69.good-web.war!/ to C:\WINDOWS\TEMP\Jetty_0_0_0_0_8080__redeploy\w ebapp 08:28:15,832 INFO [jbossweb] Started WebApplicationContext[/redeploy,jar:file:/ C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0beta2/server/default/tmp/deplo y/server/default/deploy/good-web.war/69.good-web.war!/] 08:28:15,832 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0beta2/server/default/tmp/deploy/server/default/deplo y/good-web.war/69.good-web.war to /redeploy 08:28:15,832 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0beta2/server/default/deploy/good-web.war So although the contaner says the that /redeploy context has been updated with the new good-web.war contents, the index.html page is seen to be inaccessible. -- Comment By: Scott M Stark (starksm) Date: 2002-09-28 19:54 Message: Logged In: YES user_id=175228 Fixed for the 3.0.3 release, 3.2 branch and soon head. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613882group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-594563 ] Include of JSP jumps to top of page
Bugs item #594563, was opened at 2002-08-13 05:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594563group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jeff Miner (jeff_miner)
Assigned to: Scott M Stark (starksm)
Summary: Include of JSP jumps to top of page
Initial Comment:
OS: Win98
JDK: 1.4
I have some code that manually does a JSP include
by getting a RequestDispatcher. The code worked
under Weblogic 5.1 and 6. In Jboss/Catalina,
although there are no errors thrown, the output from
the included JSP gets put at the top of the containing
page rather than in the middle where it was called.
This is puzzling because it ought to be exactly the
same as a jsp:include ... tag (and I assume those
work!)
**Containing Page***
tabletrtd
%= myObject.getOutput(request, response) %
/td/tr/table...
*** Object
public String getOutput(HttpServletRequest request,
HttpServletResponse response) {
RequestDispatcher dispatch =
context.getRequestDispatcher(someJSP.jsp);
try {
dispatch.include(request, response);
} catch(Exception e){}
return ;
*
The output from someJSP.jsp should go inside the
table, but instead it goes at the top of the containing
page.
--
Comment By: Scott M Stark (starksm)
Date: 2002-09-28 20:12
Message:
Logged In: YES
user_id=175228
This was a jasper issue that has been fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=594563group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-603412 ] Cocoon2 deployment JNDI error
Bugs item #603412, was opened at 2002-09-02 02:55
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=603412group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Thomas Sandor (tsandor)
Assigned to: Scott M Stark (starksm)
Summary: Cocoon2 deployment JNDI error
Initial Comment:
Cocoon2 deploys, but cannot start because of a JNDI
error in all of the packages of JBoss having Catalina.
Operating System: RedHat Linux 7.2
JDK Version: Sun Java 1.3.1_03
Server trace: attached, also the error output page
Steps to reproduce:
1) start jboss3.0.1-tomcat4.0.4
2) copy cocoon.war to
${jboss.home}/server/default/deploy/
3) navigate to http://localhost:8080/cocoon/ with a
browser client
--
Comment By: Scott M Stark (starksm)
Date: 2002-09-28 20:12
Message:
Logged In: YES
user_id=175228
A mapping of the jndi: url protocol will be included in the
jboss-3.0.3/tomcat-4.0.5 release so recheck against that.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=603412group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-604085 ] Jetty is not deploying packed wars
Bugs item #604085, was opened at 2002-09-03 10:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604085group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty is not deploying packed wars Initial Comment: I am seeing a problem with Jetty not deploying wars from the deploy directory in the current 3.0 and 3.2 branches. If you take the default/deploy/jmx-console.war and repack this: deploy 414ls -l jmx-console.war -rw-r--r--1 starksm None58165 Sep 3 13:17 jmx-console.war deploy 415jar -tf jmx-console.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/jmx/ WEB-INF/classes/org/jboss/jmx/adaptor/ WEB-INF/classes/org/jboss/jmx/adaptor/control/ WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResultInfo. class WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.class WEB-INF/classes/org/jboss/jmx/adaptor/html/ WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptorServ let.class WEB-INF/classes/org/jboss/jmx/adaptor/model/ WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData.cl ass WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData.cl ass WEB-INF/classes/roles.properties WEB-INF/classes/users.properties WEB-INF/web.xml displayMBeans.jsp displayOpResult.jsp images/ images/head_blue.gif index.jsp inspectMBean.jsp style_master.css Startup the default config and although Jetty says the war was deployed: 13:18:20,769 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/deploy/jmx-console. war 13:18:21,340 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=0,context=/jmx-console 13:18:21,390 INFO [jbossweb] Checking Resource aliases 13:18:21,490 INFO [jbossweb] Extract jar:file:/C:/usr/JBoss3.2/jboss-all/build/ output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-consol e.war/61.jmx-console.war!/ to C:\DOCUME~1 \starksm\LOCALS~1\Temp\Jetty_0_0_0_0_80 80__jmx-console\webapp 13:18:22,312 INFO [jbossweb] Started WebApplicationContext[/jmx-console,jar:fil e:/C:/usr/JBoss3.2/jboss-all/build/output/jboss- 3.2.0RC1/server/default/tmp/depl oy/server/default/deploy/jmx-console.war/61.jmx- console.war!/] 13:18:22,392 INFO [jbossweb] successfully deployed file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss- 3.2.0RC1/server/default/tmp/deploy/server/default/deploy/ jmx-console.war/61.jmx-console.war to /jmx-console 13:18:22,392 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- all/build/output/jboss-3.2.0RC1/server/default/deploy/jmx- console.war 13:18:22,402 INFO [URLDeploymentScanner] Started It is in fact not accessible: security 409wget http://localhost:8080/jmx-console --13:21:08-- http://localhost:8080/jmx-console = `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:21:08-- http://localhost:8080/jmx-console/ = `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 404 /jmx- console/ Not Found 13:21:08 ERROR 404: /jmx-console/ Not Found. If the jmx-console.war is unpacked then the content is accessible: security 410wget http://localhost:8080/jmx-console --13:25:25-- http://localhost:8080/jmx-console = `jmx-console' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/jmx-console/ [following] --13:25:25-- http://localhost:8080/jmx-console/ = `index.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] [ = ] 46,675 735.18K/s 13:25:30 (735.18 KB/s) - `index.html' saved [46675] These messages are for the current 3.2 build. The 3.0 build actually displays an info message with a Internal Error... msg during deployment of the war: 12:57:23,161 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/S akonnet/jboss-3.0.3RC1/server/default/deploy/jmx- console.war 12:57:23,442 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationCo ntext=1,context=/jmx-console 12:57:23,472 INFO [jbossweb] Extract jar:file:/C:/usr/Sakonnet/jboss-3.0.3RC1/s erver/default/tmp/deploy/server/default/deploy/jmx- console.war/61.jmx-console.wa r!/ to C:\DOCUME~1\starksm\LOCALS~1 \Temp\Jetty_0_0_0_0_8080__jmx-console\webapp 12:57:23,942 INFO [jbossweb] Started
[JBoss-dev] [ jboss-Bugs-593319 ] JBuilder WAR in WinXP/Win2K
Bugs item #593319, was opened at 2002-08-09 17:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593319group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jeff Miner (jeff_miner) Assigned to: Nobody/Anonymous (nobody) Summary: JBuilder WAR in WinXP/Win2K Initial Comment: I created a WAR file in JBuilder6E using jdk1.4 and deployed to Jboss 3.0.0 with no problems. The app uses JSPs and Java beans, but no EJBs. Passed the WAR file to two colleagues, one running WinXP and the other Win2K. In both cases they could deploy the WAR and access any JSPs that did not use classes from within the WAR, but on trying to run any JSP that used classes from inside the WAR, they would get an 'Unable to find package' error (naming the first imported package from the WAR). We double-checked that, in fact, the classes are actually in the WAR file and indeed they are. Both were running JBoss 3.0.0 with jdk1.3, but both changed to jdk1.4 and experienced the identical error. We were struck by the fact that the same pathnames inside the WAR sometimes appeared in uppercase and sometimes in lowercase when opened in WinZip, but could not determine if this was an issue. Notably the 'web.xml' file was in 'web-inf' while nearly all others showed as 'WEB-INF' - nonetheless, the WAR deployed and JSPs within it could be accessed, so I doubt this is the issue. -- Comment By: Scott M Stark (starksm) Date: 2002-08-09 17:42 Message: Logged In: YES user_id=175228 Provide an example war. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=593319group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 28-September-2002
Number of tests run: 932
Successful tests: 929
Errors:3
Failures: 0
[time of test: 28 September 2002 20:57 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-601097 ] Race cond in QueuedPessimisticEJBLock
Bugs item #601097, was opened at 2002-08-27 19:45
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=601097group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Race cond in QueuedPessimisticEJBLock
Initial Comment:
I believe that I have uncovered a race condition in
QueuedPessimisticEJBLock that
causes the deadlock detector to misfire.
We have an entity bean with interface:
public interface Designation
extends javax.ejb.EJBObject
{
public java.lang.String getCode( ) throws
java.rmi.RemoteException;
public java.lang.String getDisplay( ) throws
java.rmi.RemoteException;
}
The bean is configured with commit option A and the get*
methods are read-only.
Two threads A and B each begin a new trx and begin iterating over
a collection of
these beans, calling getCode and getDisplay on each one. Thread
A is running
slightly ahead of thread B. (we are building a popup menu in a
JSP).
At some point, thread A is delayed slightly while it loads data
during its invoke
of getCode and thread B catches up with it. Thread B blocks in
QueuedPessimisticEJBLock.waitForTx because thread A has the
lock. Prior to
blocking it adds an entry to the BeanLockSupport.waiting
HashMap.
Thread A completes its invokation of getCode and the following
methods of
QueuedPessimisticEJBLock get called:
1. endInvocation
2. endTransaction
3. nextTransaction
Amongst other things, nextTransaction sets the lock's tx to that of
thread B
and wakes up thread B.
This is where the race begins.
Thread A subsequently calls getDisplay on the same bean and
enters waitForTx.
It's mi tx is now different to the lock's tx, so it enters the wait loop
and adds an entry to the BeanLockSupport.waiting HashMap.
Thread B has not yet run to the end of waitForTx, so it's entry is
still
sitting in the BeanLockSupport.waiting HashMap.
Thread A runs BeanLockSupport.deadlockDetection and it finds
thread B's
entry that says it's waiting on thread A's lock, because thread B
has not
got around to removing it yet.
BeanLockSupport.deadlockDetection throws
ApplicationDeadlockException, even
though there is no real deadlock present.
I'm going to try and fix it, but I know this is a sensitive area and
you guys
will probably have your own ideas on the best way.
I'm running MacOS 10.1.5 and the corresponding Apple 1.3.1
JRE, for what it's worth.
--
Comment By: Scott M Stark (starksm)
Date: 2002-09-28 21:32
Message:
Logged In: YES
user_id=175228
Fix is incorporated into the 3.0.3 release.
--
Comment By: Stephen Coy (scoy)
Date: 2002-08-28 00:55
Message:
Logged In: YES
user_id=463096
This little patch seems to fix it for us.
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/
QueuedPessimisticEJBLock.java,v
retrieving revision 1.9.2.2
diff -r1.9.2.2 QueuedPessimisticEJBLock.java
417c417,421
this.tx = thelock.tx;
---
synchronized (waiting)
{
waiting.remove(thelock.tx);
this.tx = thelock.tx;
}
It goes into the nextTransaction method, but it should be reviewed by
the person who added the comment:
// The new transaction is the next one, important to set it up to avoid
race with
// new incoming calls
I could previously generate the problem at will, but it no longer seems to
happen with this change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=601097group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-573798 ] URLStreamHandlerFactory conflict
Bugs item #573798, was opened at 2002-06-25 13:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=573798group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jonathan Leech (jonathan_leech) Assigned to: Scott M Stark (starksm) Summary: URLStreamHandlerFactory conflict Initial Comment: org.jboss.net.protocol.URLStreamHandlerFactory conflicts with org.apache.naming.resources.DirContextURLStreamHan dlerFactory, as both jboss and tomcat want to install theirs with URL.setURLStreamHandlerFactory(). Since jboss calls it first, it wins. This makes Tomcat unhappy resolving URLs when files are nested. The only example I have found is that of nested XSL; e.g. I have an XSLT filter which reads the xsl file using servletContext.getResource(). The xsl file uses xsl:include to include another xsl file. Deep down in the bowels of xalan, it tries to read the nested file, but cannot because Tomcat's DirContextURLStreamHandlerFactory was never successfully set. My workaround for this problem is to create org.jboss.web.catalina.jndi.Handler, which simply extends org.apache.naming.resources.DirContextURLStreamHan dler. Then in EmbeddedCatalinaServiceSX.initCatalina, I put code to set the java.protocol.handler.pkgs System property to have org.jboss.web.catalina in it. Finally, I changed catalina's build.xml to have catalina's common/lib/naming-resources.jar in the classpath. This works because the DirContextURLStreamHandlerFactory itself isn't necessary -- all it does is create instances of DirContextURLStreamHandlers. If Tomcat had named the former simply 'Handler' and put it in a package called 'jndi', all the would have been necessary is to set that package in the java.protocol.handler.pkgs System property. Since they didn't, I extended their class... See the javadocs for java.net.URL and JBosss' URLStreamHandlerFactory for more background information. -- Comment By: Scott M Stark (starksm) Date: 2002-09-28 21:33 Message: Logged In: YES user_id=175228 A mapping to incorporate the jndi protocol handler has been added for the jboss-3.0.3/tomcat-4.0.5 release -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=573798group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-580594 ] Encoded URLs are not handled correctly
Bugs item #580594, was opened at 2002-07-12 07:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=580594group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: Encoded URLs are not handled correctly Initial Comment: Run with JDK 1.4 in a directory with spaces and the resulting encoded URLs cause the startup to fail. bin 635run.bat == = . JBoss Bootstrap Environment . JBOSS_HOME: g:\JBossReleases\Space Here\jboss-3.0.0\bin\.. . JAVA: D:/usr/local/Java/j2sdk1.4.0\bin\java . JAVA_OPTS: -Dprogram.name=run.bat . CLASSPATH: ;D:/usr/local/Java/j2sdk1.4.0 \lib\tools.jar;g:\JBossReleases\Space Here\jboss-3.0.0\bin\run.jar . == = . 07:23:06,781 INFO [Server] JBoss Release: JBoss- 3.0.0 CVSTag=JBoss_3_0_0 07:23:06,828 INFO [Server] Home Dir: G:\JBossReleases\Space%20Here\jboss-3.0.0 07:23:06,828 INFO [Server] Home URL: file:/G:/JBossReleases/Space%20Here/jboss- 3.0.0/ 07:23:06,828 INFO [Server] Library URL: file:/G:/JBossReleases/Space%20Here/jbo ss-3.0.0/lib/ 07:23:06,828 INFO [Server] Patch URL: null 07:23:06,828 INFO [Server] Server Name: default 07:23:06,828 INFO [Server] Server Home Dir: G:\JBossReleases\Space%20Here\jboss -3.0.0\server\default 07:23:06,828 INFO [Server] Server Home URL: file:/G:/JBossReleases/Space%20Here /jboss-3.0.0/server/default/ 07:23:06,843 INFO [Server] Server Data Dir: G:\JBossReleases\Space%20Here\jboss -3.0.0\server\default\db 07:23:06,843 INFO [Server] Server Temp Dir: G:\JBossReleases\Space%20Here\jboss -3.0.0\server\default\tmp 07:23:06,843 INFO [Server] Server Config URL: file:/G:/JBossReleases/Space%20He re/jboss-3.0.0/server/default/conf/ 07:23:06,843 INFO [Server] Server Library URL: file:/G:/JBossReleases/Space%20H ere/jboss-3.0.0/server/default/lib/ 07:23:06,859 INFO [Server] Root Deployemnt Filename: jboss-service.xml 07:23:06,859 INFO [Server] Starting General Purpose Architecture (GPA)... 07:23:07,406 INFO [ServerInfo] Java version: 1.4.0,Sun Microsystems Inc. 07:23:07,406 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.0-b92,Su n Microsystems Inc. 07:23:07,406 INFO [ServerInfo] OS-System: Windows 2000 5.0,x86 07:23:07,500 INFO [ServiceController] Controller MBean online 07:23:07,687 INFO [MainDeployer] Creating 07:23:07,750 INFO [MainDeployer] Created 07:23:07,750 INFO [MainDeployer] Starting 07:23:07,750 INFO [MainDeployer] Started 07:23:07,781 INFO [JARDeployer] Creating 07:23:07,796 INFO [JARDeployer] Created 07:23:07,796 INFO [JARDeployer] Starting 07:23:07,796 INFO [MainDeployer] Adding deployer: org.jboss.deployment.JARDeplo yer@fec107 07:23:07,796 INFO [JARDeployer] Started 07:23:07,828 INFO [SARDeployer] Creating 07:23:07,828 INFO [SARDeployer] Created 07:23:07,828 INFO [SARDeployer] Starting 07:23:07,828 INFO [MainDeployer] Adding deployer: org.jboss.deployment.SARDeplo yer@64f6cd 07:23:07,921 INFO [SARDeployer] Started 07:23:07,921 INFO [Server] Core system initialized 07:23:07,937 ERROR [Server] start failed org.jboss.deployment.DeploymentException: url file:/G:/JBossReleases/Space%20Her e/jboss-3.0.0/server/default/conf/jboss-service.xml could not be opened, does it exist? at org.jboss.deployment.DeploymentInfo.init (DeploymentInfo.java:172) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:480) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:465) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.inv oke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:314) at org.jboss.system.server.ServerImpl.start (ServerImpl.java:216) at org.jboss.Main.boot(Main.java:142) at org.jboss.Main$1.run(Main.java:375) at java.lang.Thread.run(Thread.java:536) org.jboss.deployment.DeploymentException: url file:/G:/JBossReleases/Space%20Her e/jboss-3.0.0/server/default/conf/jboss-service.xml could not be opened, does it exist? at org.jboss.deployment.DeploymentInfo.init (DeploymentInfo.java:172) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:480) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:465) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at
[JBoss-dev] [ jboss-Bugs-558434 ] Verifier does not allow ejbFindMETHOD
Bugs item #558434, was opened at 2002-05-20 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=558434group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ignacio Coloma (alu1344) Assigned to: Jay Walters (jwalters) Summary: Verifier does not allow ejbFindMETHOD Initial Comment: Right now the verifier claims that ejbFindMETHOD methods in CMP entity beans are against 10.6.2, but this point of the spec only says that the user may not provide the finder implementation, which is not the case. ejbFindMETHOD behaviour is specified on 10.7.3 -- Comment By: Jay Walters (jwalters) Date: 2002-05-20 13:55 Message: Logged In: YES user_id=183794 I will take a look at it. What version of V3.0 are you using? Latest CVS, RC2, RC1? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=558434group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-609932 ] Partition DefaultPartition hard coded
Bugs item #609932, was opened at 2002-09-16 06:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=609932group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: Thomas Peuss (tpeuss) Assigned to: Nobody/Anonymous (nobody) Summary: Partition DefaultPartition hard coded Initial Comment: The partitionname for the HTTPSession-Clustering is hard coded to DefaultPartition. So you get an exception when you want to run a cluster partition other than DefaultPartition. CU Thomas -- Comment By: Scott M Stark (starksm) Date: 2002-09-28 22:14 Message: Logged In: YES user_id=175228 Its not really hardcoded as it comes from the default settings for the httpsession.sar/ejb. Edit the ejb settings and you can define the cluster parition. Maybe this should be unpackaged to allow for easy access. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=609932group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-608412 ] VerifyError when loading class from War
Bugs item #608412, was opened at 2002-09-12 07:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=608412group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: Later Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Nobody/Anonymous (nobody) Summary: VerifyError when loading class from War Initial Comment: JBoss Release: JBoss-3.0.2 CVSTag=JBoss_3_0_2 Home Dir: D:\jb\server30\jboss Home URL: file:/D:/jb/server30/jboss/ Library URL: file:/D:/jb/server30/jboss/lib/ Patch URL: nul Root Deployemnt Filename: jboss-service.xml Starting General Purpose Architecture (GPA)... Java version: 1.3.1_01,Sun Microsystems Inc. Java VM: Java HotSpot(TM) Client VM 1.3.1_01,Sun Microsystems Inc. OS-System: Windows NT 4.0,x86l 09:41:59,181 INFO [Server] Root Deployemnt Filename: jboss-service.xml 09:41:59,197 INFO [Server] Starting General Purpose Architecture (GPA)... 09:41:59,885 INFO [ServerInfo] Java version: 1.3.1_01,Sun Microsystems Inc. 09:41:59,885 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.3.1_01,Sun Microsystems Inc. 09:41:59,900 INFO [ServerInfo] OS-System: Windows NT 4.0,x86 I have encountered the following error when running on Jboss 3.0. This error is related to the functionality of a web application based on the struts framework. The error occurs when the struts framework attempts to load a class that is in the classpath of the web application using the Class.forName(String) method. The following is the stack trace for the error. 09:37:53,431 WARN [jbossweb] WARNING: modelerweb: Error creating Action instance for path '/GetLoginInfo', class name 'com.metamatrix.modelerwe b.struts.action.login.GetLoginInfoAction' java.lang.VerifyError: (class: com/metamatrix/modelerweb/struts/action/login/ GetLoginInfoAction, method: perform signature: (Lorg/apache/struts/ action/ActionMapping;Lorg/apache/struts/action/A ctionForm;Ljavax/servlet/http/HttpServletRequest;L javax/servlet/http/HttpServletRespons -} at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at com.metamatrix.webtoolbox.struts.servlet.ActionSe rvlet.processActionCreate(ActionServlet.java:56) at org.apache.struts.action.ActionServlet.process (ActionServlet.java:1576) at org.apache.struts.action.ActionServlet.doGet (ActionServlet.java:491) at javax.servlet.http.HttpServlet.service (HttpServlet.java:740) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:344) at org.mortbay.jetty.servlet.WebApplicationHandler.dis patch(WebApplicationHandler.java:313) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:554) at org.mortbay.jetty.servlet.WebApplicationHandler.ha ndle(WebApplicationHandler.java:199) at org.mortbay.http.HttpContext.handle (HttpContext.java:1572) at org.mortbay.http.HttpContext.handle (HttpContext.java:1522) at org.mortbay.http.HttpServer.service (HttpServer.java:795) at org.jboss.jetty.Jetty.service(Jetty.java:531) at org.mortbay.http.HttpConnection.service (HttpConnection.java:784) at org.mortbay.http.HttpConnection.handleNext (HttpConnection.java:941) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:799) at org.mortbay.http.SocketListener.handleConnection (SocketListener.java:186) at org.mortbay.util.ThreadedServer.handle (ThreadedServer.java:322) at org.mortbay.util.ThreadPool$JobRunner.run (ThreadPool.java:716) at java.lang.Thread.run(Thread.java:484) 09:37:53,525 INFO [jbossweb] modelerweb: Error creating Action instance for path '/GetLoginInfo', class name 'com.metamatrix.modelerweb.struts. action.login.GetLoginInfoAction': java.lang.VerifyError: (class: com/metamatrix/modelerweb/struts/action/login/ GetLoginInfoAction, method: perfo rm signature: (Lorg/apache/struts/action/ActionMapping;Lorg/ap ache/struts/action/ActionForm;Ljavax/servlet/http /HttpServletRequest;Ljavax/servle t/http/HttpServletRespons -} Note the strange characters at the end of the error message. Almost like the class is not able to be read in for some reason. I have recompiled this class and all classes in the project several times and have experienced this error every time i re- deploy them in the Jboss environment. I was not having this problem with an early version of jboss (jboss-3.0.1RC1 I believe) It occured as soon as I upgraded. -- Comment By: Scott M Stark (starksm) Date: 2002-09-28 22:18 Message: Logged In: YES user_id=175228 Try to post a war that shows this problem as this info doesn't really help much. -- You can respond by visiting:
[JBoss-dev] [ jboss-Bugs-611044 ] JBoss+Jetty: redirect bug on welcomefile
Bugs item #611044, was opened at 2002-09-18 04:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=611044group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Pichler (mpichler) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss+Jetty: redirect bug on welcomefile Initial Comment: JSP sendRedirect into subdirectory broken from JSP welcome-file for JBoss 3.0.2 with Jetty. Take a webapplication (the attached hello.war) that defines a welcome-file Hello.jsp and page Hello.jsp does a redirect to a a relative URL: % response.sendRedirect (subdir/target.html); % This works with Jetty and Tomcat alone, and also with JBoss 3.0.2 with Tomcat 4.0.4, i.e. the redirect is performed relative to the actual location of Hello.jsp. (The difference is that tomcat uses a client redirect for the welcome page whereas jetty directly serves the welcome page under the original URL). When using JBoss 3.0.2 with Jetty 1.4 and accessing just the URL of the webapplication (http://hostname:8080/hello/), the redirect is done relative to a wrong base URL and the wepappliction part disappears from the forwarded URL. When accessing the welcome-file explicitly, it works in any case. See also http://www.jboss.org/forums/thread.jsp?forum=50thread=20933 --- JBoss+Jetty --- GET /hello/ HTTP/1.0 HTTP/1.1 302 Moved Temporarily Server: Jetty/RELEASE_MAJOR_MINOR (Linux 2.4.18-64GB-SMP i386) Servlet-Engine: Jetty/RELEASE_MAJOR_MINOR (Servlet 2.3; JSP 1.2; java 1.4.0) Location: http://192.168.x.y:8080/subdir/target.html ^--- web context /hello/ lost Server Info: codeJetty/RELEASE_MAJOR_MINOR/code BRRequest URI: code/hello/Hello.jsp/code BRFull URL: codehttp://192.168.x.y:8080/hello//code --- JBoss+Tomcat --- GET /hello/ HTTP/1.0 HTTP/1.1 302 Moved Temporarily Location: http://192.168.x.y:8080/hello/Hello.jsp (redirect to the host defined as defaultHost in tomcat4-service.xml) GET /hello/Hello.jsp HTTP/1.0 HTTP/1.1 302 Moved Temporarily Location: http://192.168.x.y:8080/hello/subdir/target.html ^--- OK (contents of Hello.jsp not served by tomcat) -- Comment By: Scott M Stark (starksm) Date: 2002-09-28 22:28 Message: Logged In: YES user_id=175228 This appears to be fixed in the Jetty version included for the jboss-3.0.3 release: system 112wget http://localhost:8080/hello/ --22:24:55-- http://localhost:8080/hello/ = `index.html' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://localhost:8080/hello/subdir/target.html [following] --22:24:55-- http://localhost:8080/hello/subdir/target.html = `target.html' Connecting to localhost[127.0.0.1]:8080... connected. HTTP request sent, awaiting response... 200 OK Length: 153 [text/html] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=611044group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.test.ejbconf.test.ReadOnlyUnitTestCase failing in 3.0
The org.jboss.test.ejbconf.test.ReadOnlyUnitTestCase started failing recently and there have been some changes around this code lately. If you have been in there take a look at why this test is failing and see if you can fix the problem. 22:40:01,694 INFO [MainDeployer] Starting deployment of package: file:/C:/usr/J Boss3.0/jboss-all/testsuite/output/lib/ejbconf-test.jar 22:40:01,884 INFO [EjbModule] Creating 22:40:01,894 INFO [EjbModule] Deploying ReadOnly 22:40:01,995 INFO [EjbModule] Deploying ReadOnlyHelper 22:40:02,035 INFO [EjbModule] Created 22:40:02,035 INFO [EjbModule] Starting 22:40:02,756 INFO [ReadOnly] Created table 'READONLY' successfully. 22:40:02,786 INFO [EjbModule] Started 22:40:02,786 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.0/jboss- all/testsuite/output/lib/ejbconf-test.jar 22:40:03,106 ERROR [LogInterceptor] EJBException: javax.ejb.EJBException: Could not load field value: value at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:60) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:156) at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:124) at org.jboss.proxy.compiler.Runtime.invoke(Runtime.java:59) at org.jboss.test.ejbconf.beans.ejb.ReadOnlyBean$Proxy.getValue(generated) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1194) at org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor.invoke(JDBCRelationInterceptor.java:95) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:308) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:90) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:152) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493) at org.jboss.ejb.Container.invoke(Container.java:712) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:381) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
