RE: [JBoss-dev] Proposal for changes to URL deployment to clean upnetboot
Scott Stark wrote:
Sounds ok, but let see some more details. Show how you propose to rewrite
SARDeployer.parseXMLClasspath using this helper framework.
I think bbtaining a URLLister should mirror the mechanism for obtain a URL
protocol handler in that one can install the class that obtains a
listing for a given
URL via package search paths.
I was thinking something like
public abstract class URLLister {
/**
* Obtain a lister appropriate for the supplied URL.
* @param baseUrl the URL to list; should end in / but need not
*/
public static URLLister getLister(URL baseUrl)
throws UnsupportedProtocolException // or something
{
}
/**
* Return the URLs of members matching the pattern.
* The pattern may contain multiple elements separated by ,
* Each element may be a wildcard e.g. *.jar
* @param pattern a pattern to filter members by
* @return a Collection of java.net.URL's containing every matching
member
*/
public abstract Collection listMembers(String pattern);
}
but a URLListerFactory with URLLister as an interface is probably better.
Either implementation would allow handlers to be plugged in.
Then the big block of code in SARDeployer.parseXMLClasspath beginning
// jason: This section needs to be rewritten to be non http file
//specific. Should probably try to convert to a URL early.
through the end of the for loop (lines 359 to 501)
would become something like:
// handle . special - is this necessary?
URL baseUrl;
if (..equals(codebase) || .equals(codebase)) {
// use the parent of the location I am deploying
baseUrl = new URL(di.url, ..);
} else {
// resolve codebase URL relative to SERVER_HOME
baseUrl = new URL(serverHomeUrl, codebase);
}
if (.equals(archives)) {
// no archives supplied so add the codebase itself
classpath.add(baseUrl);
} else {
// obtain a URLLister for this location
URLLister lister = URLLister.getLister(baseUrl);
classpath.addAll(lister.listMembers(archives));
}
The basic assumption here is that the baseUrl is a collection (as per
RFC2518 (WebDAV)) and hence its members can be listed. The implementation of
URLLister does this in whatever manner is appropriate for the protocol; e.g.
for file: scan the directory (as now) using a FilenameFilter to pattern
match.
For an http: based lister, the DAV implementation would issue a PROPFIND
request and filter the response using the search pattern; in the future this
could be extended to use DASL to filter server side. If the server supports
DAV natively, no additional support would be required; if it doesn't, a
servlet would be used to provide a trivial DAV implementation using either
the app context or by reading the server's configs (like the JBossWeb
helper).
The current http: approach, using a listing URL, could migrate to DAV or
could be a another implementation. However, the details are all hidden
behind URLLister.
This snippet is my thoughts for SARDeployer classpath but the changes to
URLDeploymentScanner would be similar. It would use a different method on
URLLister to return a collection of URLs with properties (e.g.
last-modified) similar to NetBootFile.
Examples of the special cases are:
* SARDeployer treats codebase=. as meaning the directory containing
the unit being deployed; but codebase=lib is resolved relative to
SERVER_HOME. This seems inconsistent, at least to me.
* SARDeployer makes several (6) checks for the file: protocol
* SARDeployer has to handle the special URL:* syntax used by NetBootHelper
* NetBootHelper relies on the jboss.netboot.listing.url system property
which means all netboot servers involved must use the same mechanism.
If this is not defined, it relies on the netboot location URL ending
in /files - see NetBootHelper.getDefaultListUrl()
* URLDeploymentScanner can't handle dynamic lists off the network -
HttpUrlDeploymentScanner must be used instead. This means
conf/jboss-service.xml must be modified for netboot (not a big deal
but it would be nice if configuring netboot was transparent)
And, in general, only file: and http: protocols are supported (not https:
even); adding others is not pluggable.
Jeremy
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: Jboss-Development [EMAIL PROTECTED]
Sent: Saturday, December 07, 2002 10:36 AM
Subject: [JBoss-dev] Proposal for changes to URL deployment to
clean up netboot
Wanted to get feedback before starting to implement...
The current support for loading deployment units has several
special cases
to deal with loading from the network e.g. in
SARDeployer.parseXMLClasspath(),
NetBootHelper.getDefaultListUrl() or even
HttpURLDeploymentScanner itself.
I would like to make changes to simplify this and at the same time offer
additional flexibility.
The main change would be to
[JBoss-dev] Re: Jboss-development digest, Vol 1 #4841 - 8 msgs
HI Please I need some support with Jboss-Jetty any of the new versions. I tried to link or bind Jetty-Jboss with Apache, the manuall I used is that from jetty home page but that was no too good support for me a new user, so would any kind person give me a detail manuall which support me with step by step to link Jetty-Jboss with Apache by mod_jk or mod_jk2 or any other method. All the best to you Haidar from Sweden - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 08, 2002 6:53 AM Subject: Jboss-development digest, Vol 1 #4841 - 8 msgs Send Jboss-development mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/jboss-development or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Jboss-development digest... Today's Topics: 1. Re: Proposal for changes to URL deployment to clean up netboot (Jason Dillon) 2. Re: Proposal for changes to URL deployment to clean up netboot (Scott M Stark) 3. RE: Coding-Style-page (marc fleury) 4. Automated JBoss(Branch_3_0) Testsuite Results: 7-December-2002 ([EMAIL PROTECTED]) 5. Automated JBoss(Branch_3_0) Testsuite Results: 7-December-2002 ([EMAIL PROTECTED]) 6. [ jboss-Bugs-609902 ] java.lang.LinkageError: loader ... ([EMAIL PROTECTED]) 7. [ jboss-Bugs-637168 ] Cannot start catalina service ([EMAIL PROTECTED]) 8. [ jboss-Bugs-641155 ] EAR file class scoping problem ([EMAIL PROTECTED]) --__--__-- Message: 1 Date: Sat, 7 Dec 2002 12:10:50 -0800 Subject: Re: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Wanted to get feedback before starting to implement... ;) The current support for loading deployment units has several special cases to deal with loading from the network e.g. in SARDeployer.parseXMLClasspath(), NetBootHelper.getDefaultListUrl() or even HttpURLDeploymentScanner itself. Specifically what are the special cases? It has been a while since I looked, refresh my memory. Some work still needs to be done to remove all of the http: specific bits are replace them with plain URLConnnection bits. I would like to make changes to simplify this and at the same time offer additional flexibility. The main change would be to factor out the URL listing functionality into helpers with a factory to create them based on the scheme. Examples would be: * file: using java.io.File as now * http(s): using DAV * http: using the current listing mechanisms (if still applicable) others could be added as needed (e.g ftp:) Explain some of the details here. The DAV client would allow JBoss to be netbooted from any web server supporting DAV, either directly (e.g. Tomcat 4.1, Apache+mod_dav or even IIS) or via a helper servlet (which could read either the content of its war or config of its host). I am all about more network proto support. Can this be abstracted into a URL Handler used with a URLConnection? This change would isolate the SARDeployer and the URLDeploymentScanner's from the different URL schemes and remove the special cases. Again, explain some details please. =] --jason --__--__-- Message: 2 From: Scott M Stark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot Date: Sat, 7 Dec 2002 12:31:13 -0800 Organization: JBoss Group, LLC Reply-To: [EMAIL PROTECTED] Sounds ok, but let see some more details. Show how you propose to rewrite SARDeployer.parseXMLClasspath using this helper framework. I think bbtaining a URLLister should mirror the mechanism for obtain a URL protocol handler in that one can install the class that obtains a listing for a given URL via package search paths. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: Jboss-Development [EMAIL PROTECTED] Sent: Saturday, December 07, 2002 10:36 AM Subject: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot Wanted to get feedback before starting to implement... The current support for loading deployment units has several special cases to deal with loading from the network e.g. in SARDeployer.parseXMLClasspath(), NetBootHelper.getDefaultListUrl() or even HttpURLDeploymentScanner itself. I would like to make changes to simplify this and at the same time offer additional flexibility. The main change would be to factor out the URL listing functionality into helpers with a factory to
[JBoss-dev] Automated JBoss(JBoss_3_2_0_beta2 WonderLand) Testsuite Results: 8-December-2002
JBoss daily test results SUMMARY Number of tests run: 1039 Successful tests: 1024 Errors:13 Failures: 2 [time of test: 2002-12-08.08-22 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2002-12-08.08-22 for the junit report of this test. 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: CircularityUnitTestCase Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.MBeanException Message: Exception in MBean operation 'testPackageProtected()' - Suite: RollBackUnitTestCase Test: testAsynchQueueReceiveBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchDurableTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: UnackedUnitTestCase Test:testUnackedTopic(org.jboss.test.jbossmq.test.UnackedUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: UnackedUnitTestCase Test:testUnackedDurableTopic(org.jboss.test.jbossmq.test.UnackedUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: ContextCLTestCase Test: testInvokeNeedingTCL(org.jboss.test.jbossmx.implementation.server.ContextCLTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: RuntimeException in MBean operation 'registerClassLoader(,org.jboss.mx.loading.UnifiedClassLoader)' - Suite: XAExceptionUnitTestCase Test: testXAExceptionToTransactionRolledbackLocalExceptionOnServer(org.jboss.test.jca.test.XAExceptionUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Unexpected exception: javax.ejb.EJBException: null; CausedByException is: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=lamia//11616, BranchQual=] status=STATUS_NO_TRANSACTION - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .)) - Suite: JarInSarJSR77UnitTestCase Test: testFakeParentCreatedAndRemoved(org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: fakeApp jsr-77 mbean is still present - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.)
[JBoss-dev] [ jboss-Bugs-650432 ] Does not load .JAR files during startup
Bugs item #650432, was opened at 2002-12-08 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=650432group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Alex Blewitt (asb1002) Assigned to: Nobody/Anonymous (nobody) Summary: Does not load .JAR files during startup Initial Comment: When starting, the '.jar' files in server's lib and JBoss' lib directories are loaded. Howevver, if the suffix is in different cases, such as '.JAR' then the file is /not/ loaded. I suspect that the ClassLoader just uses a textual comparison (rather than a case-insensitive comparison), which causes the JAR not to be loaded and therefore not being loaded in the class. This can easily be tested by creating a test case 'test.ClassName' and having a JSP %= class.forName(test.ClassName) %. Putting the test.ClassName in a test.jar file in the 'lib' directory will result in the class being loaded; renaming the file to TEST.JAR and restarting the server will result in the JSP failing to find the class. Tested against 3.0.4 on both Linux 2.4 (Debian) and Windows 2000 service pack 3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=650432group_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
Re: [JBoss-dev] Tyrex 2
Tyrex has a built in JNDI, therefore it packages its own jndi.properties inside the tyrex jar. REMOVE IT !!! Then Tyrex will pick up the jndi.properties from the JBoss classpath, not from inside of its own jar. This should solve your problem. Anatoly. Márcio Emílio Cruz Vono de Azevedo wrote: Hi all, I have changed the tyrex code to solve the problem with the log4j version. The server was started with no problem but now we have problems with naming. I've tried debugging with println's and I've found that Tyrex doesn't find any JNDI name. I need to solve my problem ASAP and because of it I'm here to ask you a big favour!!! If anybody has a version of Tyrex that works well with JBoss 3.0.4, could you please send me? I'd be very grateful! Thank you very much in advance! -- Márcio Emílio Cruz Vono de Azevedo System Specialist Inatel Competence Center http://www.inatel.br --- 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 -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- 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] Re: Jboss-development digest, Vol 1 #4841 - 8 msgs
Haydar, Please I need some support with Jboss-Jetty any of the new versions. This email should really have gone to one of the JBoss user forums, not this list as it is only for development issues with JBoss. Slap on the wrist having been administered, lets see if we can help... I tried to link or bind Jetty-Jboss with Apache, the manuall I used is that from jetty home page but that was no too good support for me a new user, so would any kind person give me a detail manuall which support me with step by step to link Jetty-Jboss with Apache by mod_jk or mod_jk2 or any other method. Just which part are you having trouble with - configuring Jetty-JBoss or Apache?? The most detailed instructions available are on the Jetty FAQ at http://jetty.mortbay.com/jetty/doc/index.html Jetty-JBoss automatically configures and starts an AJP13 listener for you on port 8009, so there is almost zero work for you to do there. If you really want to get into the configuration of it, then take a look at the Jetty-JBoss FAQ (available on the Jetty site on the Resources page at http://jetty.mortbay.com/jetty/resources.html). Scroll down to I want to change the port Jetty listens on for info on where and how to change the AJP13 port number (there are other settings for you to tweak in Jetty's jboss-service.xml file too). So, from the Jetty-JBoss side of things, there is almost nothing for you to do so I assume it is Apache you are having trouble with. If so, then you'll have to try mailing one of their lists or following the pointers from the Jetty FAQ to the Apache doco. cheers, Jan --- 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] Proposal for changes to URL deployment to clean up netboot
A factory + interface is the way to go, otherwise looks good.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 07, 2002 11:59 PM
Subject: RE: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot
Scott Stark wrote:
Sounds ok, but let see some more details. Show how you propose to rewrite
SARDeployer.parseXMLClasspath using this helper framework.
I think bbtaining a URLLister should mirror the mechanism for obtain a URL
protocol handler in that one can install the class that obtains a
listing for a given
URL via package search paths.
I was thinking something like
public abstract class URLLister {
/**
* Obtain a lister appropriate for the supplied URL.
* @param baseUrl the URL to list; should end in / but need not
*/
public static URLLister getLister(URL baseUrl)
throws UnsupportedProtocolException // or something
{
}
/**
* Return the URLs of members matching the pattern.
* The pattern may contain multiple elements separated by ,
* Each element may be a wildcard e.g. *.jar
* @param pattern a pattern to filter members by
* @return a Collection of java.net.URL's containing every matching
member
*/
public abstract Collection listMembers(String pattern);
}
but a URLListerFactory with URLLister as an interface is probably better.
Either implementation would allow handlers to be plugged in.
Then the big block of code in SARDeployer.parseXMLClasspath beginning
// jason: This section needs to be rewritten to be non http file
//specific. Should probably try to convert to a URL early.
through the end of the for loop (lines 359 to 501)
would become something like:
// handle . special - is this necessary?
URL baseUrl;
if (..equals(codebase) || .equals(codebase)) {
// use the parent of the location I am deploying
baseUrl = new URL(di.url, ..);
} else {
// resolve codebase URL relative to SERVER_HOME
baseUrl = new URL(serverHomeUrl, codebase);
}
if (.equals(archives)) {
// no archives supplied so add the codebase itself
classpath.add(baseUrl);
} else {
// obtain a URLLister for this location
URLLister lister = URLLister.getLister(baseUrl);
classpath.addAll(lister.listMembers(archives));
}
---
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: 8-December-2002
JBoss daily test results SUMMARY Number of tests run: 1001 Successful tests: 988 Errors:11 Failures: 2 [time of test: 2002-12-08.12-06 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.2] See http://users.jboss.org/~starksm/Branch_3_0/2002-12-08.12-06 for details of this test. 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: CircularityUnitTestCase Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.MBeanException Message: Exception in MBean operation 'testPackageProtected()' - Suite: RollBackUnitTestCase Test: testAsynchQueueReceiveBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: RollBackUnitTestCase Test: testAsynchDurableTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) Type:error Exception: java.lang.NoSuchMethodError Message: - Suite: BaseConnectionManagerUnitTestCase Test:testFillToMin(org.jboss.test.jca.test.BaseConnectionManagerUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Wrong number of connections counted: 1 - Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testHaInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: SimpleUnitTestCase Test:testHaParitionName(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.CommunicationException Message: Receive timed out - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: ContextCLTestCase Test: testInvokeNeedingTCL(org.jboss.test.jbossmx.implementation.server.ContextCLTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: RuntimeException in MBean operation 'registerClassLoader(,org.jboss.mx.loading.UnifiedClassLoader)' - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___
[JBoss-dev] [ jboss-Bugs-633800 ] Cannot call setProperty() after clear()
Bugs item #633800, was opened at 2002-11-05 05:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=633800group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: Daniel Sieroka (sieroka) Assigned to: Nathan W. Phelps (nphelps) Summary: Cannot call setProperty() after clear() Initial Comment: The JMS spec says that you can set properties on incoming JMS messages: lObjectMessage.clearBody(); lObjectMessage.setStringProperty( PROPERTY, lProperty ); With JBoss 3.0.3 I get the following error: javax.jms.MessageNotWriteableException: Properties are read-only at org.jboss.mq.SpyMessage.setStringProperty (SpyMessage.java:423) at com.platespin.oss.apps.masterwatch.ejb.MhwDetailedSt atsMessageBean.onMessage (MhwDetailedStatsMessageBean.java:173) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.MessageDrivenContainer$ContainerIntercep tor.invoke(MessageDrivenContainer.java:391) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.i nvoke(MessageDrivenInstanceInterceptor.java:88) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke (RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.MessageDrivenContainer.invoke (MessageDrivenContainer.java:302) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke (JMSContainerInvoker.java:962) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$Message ListenerImpl.onMessage(JMSContainerInvoker.java:1038) at org.jboss.jms.asf.StdServerSession.onMessage (StdServerSession.java:238) at org.jboss.mq.SpyMessageConsumer.sessionConsumer ProcessMessage(SpyMessageConsumer.java:603) at org.jboss.mq.SpyMessageConsumer.addMessage (SpyMessageConsumer.java:417) at org.jboss.mq.SpySession.run(SpySession.java:259) at org.jboss.jms.asf.StdServerSession.run (StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Work er.run(PooledExecutor.java:642) at java.lang.Thread.run(Thread.java:479) -- Comment By: Nathan W. Phelps (nphelps) Date: 2002-11-27 07:44 Message: Logged In: YES user_id=130188 You are incorrect. The JMS Specification section 3.10 says: When a message is received, its header field values can be changed; however, its property entries and its body are read- only, as specified in this chapter. The rationale for the read-only restriction is that it gives JMS providers more freedom in how they implement the management of received messages. For instance, they may return a message object that references property entries and body values that reside in an internal message buffer rather than being forced to make a copy. A consumer can modify a received message after calling either the clearBody or clearProperties method to make the body or properties writable. If the consumer modifies a received message, and the message is subsequently redelivered, the redelivered message must be the original, unmodified message (except for headers and properties modified by the JMS provider as a result of the redelivery, such as the JMSRedelivered header and the JMSXDeliveryCount property). In other words, the properties in question are read only until you call clearProperties. Your call to clearBody only clears the body and sets it to read/write. JBossMQ is therefore, in compliance with the specification in this case. You need to change your code to call clearProperties instead of clearBody and then you will be able to successfully set properties. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=633800group_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-636920 ] JSP INCLUDE
Bugs item #636920, was opened at 2002-11-11 18:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=636920group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Jeff Miner (jeff_miner) Assigned to: Nobody/Anonymous (nobody) Summary: JSP INCLUDE Initial Comment: v 3.0.4 See my previous #594563 which starksm closed. Inclusion of JSP using RequestDispatcher causes included content to jump to top of page. He claims this was fixed, yet the latest, greatest download (v 3.0.4) exhibits the same behavior. Do I need to upgrade Jetty separately? One can flush the out buffer in the JSP before including, but I need to do this in the object, not in the JSP. Why doesn't the RequestDispatcher know how to do this? -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 14:35 Message: Logged In: YES user_id=592596 Aha! Looks like the clean way to do this is with PageContext.include() Thus, pass the PageContext, but not necessarily the Request and Response, and call PageContext.include() without a Dispatcher. Seems to work and is cleaner (though the Dispatcher still OUGHT to work) -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 02:58 Message: Logged In: YES user_id=592596 OK - Sorry I got hot under the collar - I'm having roughly the same discussion with Macromedia over JRun and they out and out said it is not a bug, this is according to spec which is just foolish. I guess I can sort of envision how the problem arises from not integrating the JSPs into the ServletEngine, but I still don't understand how the servlet can do ANY include properly if this doesn't work - that is, if the JSP servlet is up to spec, because any servlet's output would have to be properly inserted in the buffer. Why should the JSP servlet be different? I can use the workarounds, but it means an extensive rewrite. The reason things need to be done this way (in brief) is that the getOutput() method exists on many objects polymorphically and may not do an include at all, so I don't want to mess with buffers etc. and would rather not have to add params to all my method calls. FYI - This is actually a small part of a nested MVC design -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-11-14 02:27 Message: Logged In: YES user_id=44062 Hey Jeff - keep it cool OK. We are not ignoring your problem. We have analyzed it and given you some suggestions. Pretty good service for free! I agree - that it the include SHOULD work the same either way. It works for weblogic, because their JSP engine is integrated into their servlet engine. But many containers such as Jetty and Tomcat implement JSPs simply as a servlet within the container. It is not possible to simply resolve this problem with such an implementation of JSPs. The mood on the servlet JSR is that integrating JSPs with the servlet spec was a mistake and JSPs should no longer given special status within servlet containers. Why are JSPs favoured over webmacros, velocity, cocoon, etc. etc.? Hence future versions of the spec are moving away from tight integration of JSPs.If this was not the case, then I might be more inclined to jump hurdles to fix this problem. The root of the problem is a bad spec. It's not a bug, just poorly defined integration of several features. So the reality of the situation is that I think it VERY unlikey that this bug will be fixed by either the developers of jasper, tomcat or jetty. But, it is open source and you are free to give it a go yourself! PS. Servlets don't normally have to know about JSP buggering, etc. in order to include them properly. You are using servlet code within a JSP and that is not normal. There are plenty of things you can break in JSPs if you start playing with the full servlet API - these are not bugs, just dangers inherent in the design of JSPs. I strongly suggest that once you have invoked a JSP, that you use JSP techniques for include etc. If you want to do servlet stuff, then do it in a servlet - not via a JSP. Better yet, get a propper MVC design going, where the servlets do the Control and JSPs to the View. regards -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 02:01 Message: Logged In: YES user_id=592596 Mr. Wilkins, I don't want to get snippy here, but I do not think there is any problem with MY code. A RequestDispatcher that dispatches to a JSP should do exactly what the jsp:include tag does -- no more, no less. Servlets shouldn't have to know about JSP buffering, etc. in order to include them properly. Certainly I could pass the writer around, I can pass the
[JBoss-dev] [ jboss-Bugs-636920 ] JSP INCLUDE
Bugs item #636920, was opened at 2002-11-12 02:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=636920group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Jeff Miner (jeff_miner) Assigned to: Nobody/Anonymous (nobody) Summary: JSP INCLUDE Initial Comment: v 3.0.4 See my previous #594563 which starksm closed. Inclusion of JSP using RequestDispatcher causes included content to jump to top of page. He claims this was fixed, yet the latest, greatest download (v 3.0.4) exhibits the same behavior. Do I need to upgrade Jetty separately? One can flush the out buffer in the JSP before including, but I need to do this in the object, not in the JSP. Why doesn't the RequestDispatcher know how to do this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-12-08 22:58 Message: Logged In: YES user_id=44062 Thanks for feeding back this solution. we'll close this issue now (but will still think about making it work the way it OUGHT to :-) regards -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 22:35 Message: Logged In: YES user_id=592596 Aha! Looks like the clean way to do this is with PageContext.include() Thus, pass the PageContext, but not necessarily the Request and Response, and call PageContext.include() without a Dispatcher. Seems to work and is cleaner (though the Dispatcher still OUGHT to work) -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 10:58 Message: Logged In: YES user_id=592596 OK - Sorry I got hot under the collar - I'm having roughly the same discussion with Macromedia over JRun and they out and out said it is not a bug, this is according to spec which is just foolish. I guess I can sort of envision how the problem arises from not integrating the JSPs into the ServletEngine, but I still don't understand how the servlet can do ANY include properly if this doesn't work - that is, if the JSP servlet is up to spec, because any servlet's output would have to be properly inserted in the buffer. Why should the JSP servlet be different? I can use the workarounds, but it means an extensive rewrite. The reason things need to be done this way (in brief) is that the getOutput() method exists on many objects polymorphically and may not do an include at all, so I don't want to mess with buffers etc. and would rather not have to add params to all my method calls. FYI - This is actually a small part of a nested MVC design -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-11-14 10:27 Message: Logged In: YES user_id=44062 Hey Jeff - keep it cool OK. We are not ignoring your problem. We have analyzed it and given you some suggestions. Pretty good service for free! I agree - that it the include SHOULD work the same either way. It works for weblogic, because their JSP engine is integrated into their servlet engine. But many containers such as Jetty and Tomcat implement JSPs simply as a servlet within the container. It is not possible to simply resolve this problem with such an implementation of JSPs. The mood on the servlet JSR is that integrating JSPs with the servlet spec was a mistake and JSPs should no longer given special status within servlet containers. Why are JSPs favoured over webmacros, velocity, cocoon, etc. etc.? Hence future versions of the spec are moving away from tight integration of JSPs.If this was not the case, then I might be more inclined to jump hurdles to fix this problem. The root of the problem is a bad spec. It's not a bug, just poorly defined integration of several features. So the reality of the situation is that I think it VERY unlikey that this bug will be fixed by either the developers of jasper, tomcat or jetty. But, it is open source and you are free to give it a go yourself! PS. Servlets don't normally have to know about JSP buggering, etc. in order to include them properly. You are using servlet code within a JSP and that is not normal. There are plenty of things you can break in JSPs if you start playing with the full servlet API - these are not bugs, just dangers inherent in the design of JSPs. I strongly suggest that once you have invoked a JSP, that you use JSP techniques for include etc. If you want to do servlet stuff, then do it in a servlet - not via a JSP. Better yet, get a propper MVC design going, where the servlets do the Control and JSPs to the View. regards -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 10:01 Message: Logged In: YES user_id=592596 Mr. Wilkins, I don't want to get snippy here, but I do
[JBoss-dev] Invokers (jboss 4)
I've been studying the invokers while working on the xid-based transaction propagation and plan to do some refactoring if there are no strong objections. 1. I plan to make both the client (sending) and server (receiving) halves of the invokers layered with aspects or interceptors. This will enable reuse of everything except the transport layer across most invokers. 2. I have not yet tried performance tests on these, but have noticed that the principal structural difference between the pooled invoker and the trunk invoker is that the trunk invoker multiplexes simultaneous requests asynchronously over the same socket, whereas the pooled invoker ties up the socket for the entire duration of server-side request processing. I would expect this would translate into slightly better performance for the pooled invoker with a single threaded client, due to the lack of the synchronization and queueing between requests and responses, but enormously better performance for the trunk invoker with a multithreaded client (and perhaps multi-processor server). I may not understand all that is going on in the pooled invoker: my assumption is that each client obtains a single socket connection to the server, and it is reused for all requests from a single client, and that it is served by a single server thread. If I'm wrong I'd welcome correction. 3. In order to use the work import contracts, I plan to make all the invokers asynchronous, as the trunk invoker is today. The Work object will include both the code to call the mbean target (i.e. ejb) and the information necessary to return the result back through the transport mechanism. It's possible that separate inbound and outbound interceptor/aspect stacks may be desirable. 4. There has been some discussion about two way transport, as implemented in the trunk invoker. It seems to me that any way of calling an ejb has in it 2 communication channels, one in each direction. If these are based on accessible sockets, the channels can be used in the opposite direction and order, thus providing two way transport. I propose to provide this two way transport when the underlying transport supports these separable transport directions (for instance, my impression is that rmi does not). If there are problems with this approach I'd like to know about them. If you disagree with this approach please explain why the in and out streams from a socket should not be used in both directions for this purpose and explain in at least a little detail an alternative approach. Thanks david jencks --- 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] Red Hat start up script
Hi, Currently the Quick Start Guide contains a section on how to install JBoss as a Unix service. It contains instructions on how to do it. The jboss-3.0.4_tomcat-4.1.12 bundle also contains a jboss_init_redhat.sh that apparently does not agree with what's in the book. The one in the Quick Start Guide seems to make more sense. Can the scripts mentioned in the book (instead of the jboss_init_redhat.sh) be bundled with the binary distribution? -- Weiqi Gao [EMAIL PROTECTED] --- 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-645670 ] Client cannot find ResourceException
Bugs item #645670, was opened at 2002-11-29 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=645670group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Korenev (vkorenev) Assigned to: David Jencks (d_jencks) Summary: Client cannot find ResourceException Initial Comment: JBoss 3.0.4 Sun JDK 1.4.1_01 Win2000 File jbossall-client.jar does not contain all necessary files for standalone client. I have got an exception: java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.resource.ResourceException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) . . . Maybe some other exceptions are to be included in client libraries. -- Comment By: David Jencks (d_jencks) Date: 2002-12-09 05:37 Message: Logged In: YES user_id=60525 Can you supply any more information about when this occurs? My first idea is that this exception should not really be getting to a client. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=645670group_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-648344 ] open-cursors limit reached
Bugs item #648344, was opened at 2002-12-04 11:52
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=648344group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Barrow (bruce_b)
Assigned to: Nobody/Anonymous (nobody)
Summary: open-cursors limit reached
Initial Comment:
First 'bug', so bear with me. Some description follows
the trace.
OS: Windows NT 4.0
JDK: 1.4
10:13:49,671 INFO [Server] JBoss Release: JBoss-
3.0.3 CVSTag=JBoss_3_0_3
10:13:49,718 INFO [Server] Home Dir: F:\jboss\jboss-
3.0.3
10:13:49,718 INFO [Server] Home URL:
file:/F:/jboss/jboss-3.0.3/
10:13:49,718 INFO [Server] Library URL:
file:/F:/jboss/jboss-3.0.3/lib/
10:13:49,718 INFO [Server] Patch URL: null
10:13:49,718 INFO [Server] Server Name: efc
10:13:49,718 INFO [Server] Server Home Dir:
F:\jboss\jboss-3.0.3\server\efc
10:13:49,718 INFO [Server] Server Home URL:
file:/F:/jboss/jboss-3.0.3/server/efc/
10:13:49,718 INFO [Server] Server Data Dir:
F:\jboss\jboss-3.0.3\server\efc\db
10:13:49,718 INFO [Server] Server Temp Dir:
F:\jboss\jboss-3.0.3\server\efc\tmp
10:13:49,750 INFO [Server] Server Config URL:
file:/F:/jboss/jboss-3.0.3/server/efc/conf/
10:13:49,750 INFO [Server] Server Library URL:
file:/F:/jboss/jboss-3.0.3/server/efc/lib/
10:13:49,750 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
10:13:49,750 INFO [Server] Starting General Purpose
Architecture (GPA)...
10:13:50,218 INFO [ServerInfo] Java version:
1.4.0_02,Sun Microsystems Inc.
10:13:50,218 INFO [ServerInfo] Java VM: Java HotSpot
(TM) Client VM 1.4.0_02-b02,Sun Microsystems Inc.
10:13:50,218 INFO [ServerInfo] OS-System: Windows
NT 4.0,x86
10:13:50,312 INFO [ServiceController] Controller MBean
online
10:13:50,484 INFO [MainDeployer] Creating
10:13:50,546 INFO [MainDeployer] Created
10:13:50,546 INFO [MainDeployer] Starting
10:13:50,546 INFO [MainDeployer] Started
10:13:50,578 INFO [JARDeployer] Creating
10:13:50,578 INFO [JARDeployer] Created
10:13:50,578 INFO [JARDeployer] Starting
10:13:50,578 INFO [MainDeployer] Adding deployer:
org.jboss.deployment.JARDeployer@808199
10:13:50,578 INFO [JARDeployer] Started
10:13:50,609 INFO [SARDeployer] Creating
10:13:50,609 INFO [SARDeployer] Created
10:13:50,609 INFO [SARDeployer] Starting
10:13:50,609 INFO [MainDeployer] Adding deployer:
org.jboss.deployment.SARDeployer@66a22b
10:13:50,703 INFO [SARDeployer] Started
10:13:50,703 INFO [Server] Core system initialized
10:13:50,718 INFO [MainDeployer] Starting deployment
of package: file:/F:/jboss/jboss-
3.0.3/server/efc/conf/jboss-servi
ce.xml
[...]
10:14:04,562 INFO [jbossweb] Starting Jetty/4.1
10:14:04,593 INFO [jbossweb] Started
org.mortbay.http.NCSARequestLog@8a8ce2
[...]
10:14:31,437 INFO [EjbModule] Started
10:14:31,437 INFO [EjbModule] Starting
10:14:31,484 INFO [EjbModule] Started
10:14:31,484 INFO [MainDeployer] Deployed package:
file:/F:/jboss/jboss-3.0.3/server/efc/deploy/efc.ear
10:14:31,484 INFO [URLDeploymentScanner] Started
10:14:31,500 INFO [MainDeployer] Deployed package:
file:/F:/jboss/jboss-3.0.3/server/efc/conf/jboss-service.xml
10:14:31,500 INFO [Server] JBoss (MX MicroKernel)
[3.0.3 Date:200209301503] Started in 0m:41s:750ms
10:42:25,890 INFO [STDOUT]
CPCBean.registerUserSession
10:42:25,906 INFO [STDOUT]
CPCBean.registerUserSession: Registering
userSession, key=edgar_j:Product Tester [-38522377
2]
[...]
11:08:20,468 ERROR [STDERR]
{className=WorkspaceDAOOracle
methodName=readRow
componentSequenceNumber=203003 severity
=13 errorType=0 errorMessage=An SQL Exception
occurred while trying to execute statement SELECT
cols_list FROMtable WHERE where .
The error was 72000
dynamicContent={ SELECT cols FROM
table WHERE etc... , 72000
} nestedException.message=ORA-01000: maximum
open cursors exceeded
nestedException.stackTrace=java.sql.SQLException:
ORA-01000: maximum open cursors exceeded
Initially, the open_cursors parameter on the database
was set to 250. This was raised to 500, but this was just
putting off the problem - not resolving it.
Querying the database shows that some sessions have
over 250 cursors - these should really expire or be aged
out. Is this a known issue?
Connecting to the JBoss server takes one or two
seconds, because of the work required to determine
access rights, therefore sessions are left connected.
The number of cursors used therefore increases quickly.
Is there a way of configuring JBoss to release cursors
more quickly?
Thanks in advance,
Bruce
--
Comment By: David Jencks (d_jencks)
Date: 2002-12-09 05:48
Message:
Logged In: YES
user_id=60525
JBoss doesn't try to close result sets, statements, or connections for
you. You are responsible for closing all of these in finally blocks after
you are done with them.
It would be possible, using the jdbc-jca wrappers, to
[JBoss-dev] JBoss 4 testsuite problem??
Earlier I committed some changes to jboss 4 which worked well on my mac (jdk 1.4.1 preview release 6) (running default without clustering or iiop, 991 tests, 5 failures, 16 errors). However, on my linux 1.3.1 machine a fresh checkout gives much more discouraging results: 652 tests, 24 failures, 299 errors. Most of these problems appear to be caused by jboss:service=WebService becoming unregistered partway through the tests, after which basically nothing works (ejbs cannot be deployed). (I already fixed one problem causing this on the mac due to lack of synchronization in the BasicMBeanRegistry) If anyone else is running the jboss 4 testsuite I'd like to know what your results are. Thanks david jencks --- 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] JBoss 4 testsuite problem??
I also see many errors with jboss-head: Number of tests run: 652 Successful tests: 326 Errors:300 Failures: 26 [time of test: 8 December 2002 23:30 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Sunday, December 08, 2002 9:59 PM Subject: [JBoss-dev] JBoss 4 testsuite problem?? Earlier I committed some changes to jboss 4 which worked well on my mac (jdk 1.4.1 preview release 6) (running default without clustering or iiop, 991 tests, 5 failures, 16 errors). However, on my linux 1.3.1 machine a fresh checkout gives much more discouraging results: 652 tests, 24 failures, 299 errors. Most of these problems appear to be caused by jboss:service=WebService becoming unregistered partway through the tests, after which basically nothing works (ejbs cannot be deployed). (I already fixed one problem causing this on the mac due to lack of synchronization in the BasicMBeanRegistry) If anyone else is running the jboss 4 testsuite I'd like to know what your results are. Thanks david jencks --- 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
