Re: [JBoss-dev] Health monitoring
Can you make public the name of this good profiler?. Thanks, Alin - Original Message - From: Rhett Aultman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 23, 2002 5:32 AM Subject: RE: [JBoss-dev] Health monitoring I believe it's possible, but I'm still plugging at it. My graduate school preparation has, as of late, been sucking my life dry on many fronts. There is already a good profiler out there in reasonably portable C++, and I have a mechanism for tying it to an MBean. -Original Message- From: Nick Betteridge [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 4:06 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Health monitoring Is this possible to include for jboss4? A simple accounting mechanism with threads and groups/realms/whatever , with a jni interface and C code which compiles to each paltform type? Rhett Aultman wrote: Not pure Java, no, but there are some reasonably portable native code tricks that can get that information (which is what I've been working towards) -Original Message- From: Michael Bartmann [mailto:[EMAIL PROTECTED]] Sent: Sun 9/22/2002 3:26 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] Health monitoring Nick Betteridge wrote: One thing that I would find really useful is the ability to get each thread size and process time which is somehow attributed to either a If I understand thread size as the total memory consumption of the thread I don't know any pure Java methods for obtaining these values. Even under Linux, where every thread is visible through the ps command, each of the processes reports the memory consumption of the whole jvm. I admit it would me a great feature... Regards, Michael Bartmann --- 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 Name: winmail.dat winmail.datType: application/ms-tnef Encoding: base64 --- 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] JDK 1.4 daily tests?
Michael Bartmann wrote: Dain Sundstrom wrote: Do we run daily tests on 1.4 anymore? Is anyone running in production on 1.4? We also do, but We are. But we use 3.2, where there is no daily test anyway. Biggest issues: - memory leak we have seen this too. Had to insert more memory to have it working without outOfMemExeptions. Haven't tried 1.4.1 yet. - Clients with 1.3 fail to connect to JMS-OIL-Topics, but succeed with JMS-RMI-Topics Regards, Michael Bartmann Thanks -dain --- 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] Re: [jetty-discuss] isValid() not a good fit for certs
Hi Greg,
Looks cool. BTW, it might be worth using a combination of the serial number
and issuer if the subjectDN doesn't work, since the issuer on its own won't
be unique and I think this will thwart the jboss authentication caching on
principal.
I have been using the following function to get a unique string out of the
certificate. It's a bit specific to us because AFAIK we index the certs on
serialissuer, but may be of use?
/**
* Takes an X509Certificate object and extracts the certificate's serial
* number and issuer in order to construct a filter that can be used for
* finding the user's entry in GDS.
*
* @param cert the user's certificate.
* @return an LDAP filter for retrieving the user's entry.
*/
private String getFilterFromCertificate(X509Certificate cert) {
StringBufferbuff = new StringBuffer();
String serialNumber =
cert.getSerialNumber().toString(16).toUpperCase();
if (serialNumber.length() % 2 != 0) {
buff.append(0);
}
buff.append(serialNumber);
buff.append( );
buff.append(cert.getIssuerDN().toString());
String filter = buff.toString();
return filter;
}
Cheers,
Phil
-Original Message-
From: Greg Wilkins [mailto:[EMAIL PROTECTED]]
Sent: 21 September 2002 10:50
To: [EMAIL PROTECTED]
Cc: '[EMAIL PROTECTED]'
Subject: Re: [JBoss-dev] Re: [jetty-discuss] isValid() not a good fit
for certs
Phil,
It has been suggested that Jetties approach of testing each
certificate
in turn until one passes is incorrect. As the array of certificates
indicates the chain of trust and they all need to be checked to
verify authentication.
As we are already passing an object as a credential to the realm, I
suggest that we pass the entire array of certificates to the realm for
it to check:
java.security.cert.X509Certificate[] certs =
(java.security.cert.X509Certificate[])
request.getAttribute(javax.servlet.request.X509Certificate);
if (certs==null || certs.length==0 || certs[0]==null)
return null;
Principal principal = certs[0].getSubjectDN();
if (principal==null)
principal=certs[0].getIssuerDN();
UserPrincipal user =
realm.authenticate(principal==null?clientcert:principal.getName(),
certs,request);
return user;
Would that be an appropriate thing to do?
Note that I agree with Scott that we do not need a mutable
Principal returned.
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.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
--
If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.
--
---
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] Health monitoring
The native code profiler I've been working with is an open-source C++ profiler called jProf. I don't have a URL handy, but a Google search will turn it up. -Original Message- From: Alin [mailto:[EMAIL PROTECTED]] Sent: Tue 9/24/2002 4:04 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] Health monitoring Can you make public the name of this good profiler?. Thanks, Alin - Original Message - From: Rhett Aultman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 23, 2002 5:32 AM Subject: RE: [JBoss-dev] Health monitoring I believe it's possible, but I'm still plugging at it. My graduate school preparation has, as of late, been sucking my life dry on many fronts. There is already a good profiler out there in reasonably portable C++, and I have a mechanism for tying it to an MBean. -Original Message- From: Nick Betteridge [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 4:06 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Health monitoring Is this possible to include for jboss4? A simple accounting mechanism with threads and groups/realms/whatever , with a jni interface and C code which compiles to each paltform type? Rhett Aultman wrote: Not pure Java, no, but there are some reasonably portable native code tricks that can get that information (which is what I've been working towards) -Original Message- From: Michael Bartmann [mailto:[EMAIL PROTECTED]] Sent: Sun 9/22/2002 3:26 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] Health monitoring Nick Betteridge wrote: One thing that I would find really useful is the ability to get each thread size and process time which is somehow attributed to either a If I understand thread size as the total memory consumption of the thread I don't know any pure Java methods for obtaining these values. Even under Linux, where every thread is visible through the ps command, each of the processes reports the memory consumption of the whole jvm. I admit it would me a great feature... Regards, Michael Bartmann --- 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 Name: winmail.dat winmail.datType: application/ms-tnef Encoding: base64 --- 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 winmail.dat
Re: [JBoss-dev] Health monitoring
Rhett Aultman wrote: The native code profiler I've been working with is an open-source C++ profiler called jProf. I don't have a URL handy, but a Google search will turn it up. http://starship.python.net/crew/garyp/jProf.html --- 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-506969 ] verifier ignores case of CMP field names
Bugs item #506969, was opened at 2002-01-22 14:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=506969group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Christian Riege (lqd) Summary: verifier ignores case of CMP field names Initial Comment: If CMP field name in ejb-jar.xml differs from public field name only in case, verifier doesn't report an error but exception occurs while creating entity: [12:51:39,169,JAWSPersistenceManager] Could not create entity: java.lang.NullPointerException at org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData.ge tValue(CMPFieldMetaData.java:423) at org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getCMPField Value(JDBCCommand.java:636) at org.jboss.ejb.plugins.jaws.jdbc.JDBCCreateEntityCommand .setParameters(JDBCCreateEntityCommand.java:172) -- Comment By: Christian Riege (lqd) Date: 2002-09-24 14:50 Message: Logged In: YES user_id=176671 As this is not a critical bug I will close this. You are welcome to submit a patch though. -- Comment By: Christian Riege (lqd) Date: 2002-07-22 11:05 Message: Logged In: YES user_id=176671 can you pls. attach a simple test case (i.e. jar, one entity bean + ejb-jar.xml) that demonstrates this problem? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=506969group_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-613360 ] Verifier: abstract-schema-name
Bugs item #613360, was opened at 2002-09-23 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Dain Sundstrom (dsundstrom) Assigned to: Christian Riege (lqd) Summary: Verifier: abstract-schema-name Initial Comment: 10.3.13 An abstract-schema-name element for each entity bean. The abstract-schema-name must be a valid Java identifier and must be unique within the ejb-jar file. 10.6.14 The Bean Provider should not use reserved identifiers as ejb-names or abstract-schema-names. Reserved identifiers are discussed in Section 11.2.6.1. 22.2 Entity Beans abstract schema name. If the enterprise bean is an Entity Bean with container-managed persistence and cmp-version 2.x, the Bean Provider must specify the abstract schema name of the entity bean using the abstract-schema-name element. I suggest we make this an enforced error in 3.2 and 4.0 but only a warning in 3.0. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-23 21:02 Message: Logged In: YES user_id=251431 The valid Java identifier rule also applies to ejb-name so the common style name 'my/app/MyBean' name is not legal. Again, I think this should be enforced in 3.2 and 4.0 but not in 3.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_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-613809 ] SECURITY: Tomcat 4.0.x Security updates
Bugs item #613809, was opened at 2002-09-24 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613809group_id=22866 Category: CatalinaBundle Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Opitz (opi) Assigned to: Scott M Stark (starksm) Summary: SECURITY: Tomcat 4.0.x Security updates Initial Comment: Hi, since today there are Tomcat Security updates available. See http://jakarta.apache.org/site/news.html#0924.1 Newest stable Versions are 4.0.5 and 4.1.12 Greetings opi// -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613809group_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-613360 ] Verifier: abstract-schema-name
Bugs item #613360, was opened at 2002-09-23 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Dain Sundstrom (dsundstrom) Assigned to: Christian Riege (lqd) Summary: Verifier: abstract-schema-name Initial Comment: 10.3.13 An abstract-schema-name element for each entity bean. The abstract-schema-name must be a valid Java identifier and must be unique within the ejb-jar file. 10.6.14 The Bean Provider should not use reserved identifiers as ejb-names or abstract-schema-names. Reserved identifiers are discussed in Section 11.2.6.1. 22.2 Entity Beans abstract schema name. If the enterprise bean is an Entity Bean with container-managed persistence and cmp-version 2.x, the Bean Provider must specify the abstract schema name of the entity bean using the abstract-schema-name element. I suggest we make this an enforced error in 3.2 and 4.0 but only a warning in 3.0. -- Comment By: Christian Riege (lqd) Date: 2002-09-24 15:06 Message: Logged In: YES user_id=176671 Hm, the Spec is (as usual) a bit ambigious in some cases here: according to the spec the rules of ejb-name being a valid Java Identifier only apply to CMP 2.0 Entity Beans. There's no mentioning of this on BMP, Session or Message Driven Beans. IMO we should enforce this on all types of EJB's though, it Just makes sense and it'll be consistent. Dain, what's your opinion on this issue? Of course this change hoses some parts of the testsuite and a couple of default JBoss Components (e.g. the JMX-EJB Adaptor). I'll try to fix these as I go along but I don't think I will catch all :). -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-09-23 21:02 Message: Logged In: YES user_id=251431 The valid Java identifier rule also applies to ejb-name so the common style name 'my/app/MyBean' name is not legal. Again, I think this should be enforced in 3.2 and 4.0 but not in 3.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613360group_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
AW: [JBoss-dev] writing a jboss.net (jmx.net?) client
Matt, For getting the client-side invocations and stub classes right, we recommend The following steps: A) generate wsdl from the deployed web services. B) generate stub classes from the wsdl using wsdl2java. Using Axis/MbeanInvocationHandler lacks a lot of deployment information (basically, The client-side of the web-service.xml) that we try to default from java reflection. This may work for simple cases, but once you declare additional data structures and serializers, it becomes very hairy on the client side, otherwise. CGJ -Ursprüngliche Nachricht- Von: Matt Munz [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 20. September 2002 17:41 An: JBoss Developers Group Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client CGJ JBoss.Net Developers, First, let me say Thank you. I now have MBeans in the server exposed as web services. Although it took a bit of research to figure out how to do this, the minimal amount of (xml) code required to expose MBeans as webservices (should I call this JMX.Net?) speaks for itself. I was again pleased to see that the client side is also straightforward, once I knew what to do. Basically, I emulated the code in the testsuite for JBoss.Net. This works with the following caveat. The org.jboss.net.axis.AxisInvocationHandler class is deprecated. MBeanInvocationHandler, the class I am using on the client side, extends AxisInvocationHandler. What should I do instead of using this class (which seems to work perfectly well)? I found the following in AxisInvocationHandler. Could anyone explain this further? Due to the inherent deficiencies in using pure reflection meat-data to access web services, we recommend using the axis stub way of creating web service references Thanks again. - 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 ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.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
[JBoss-dev] 3.2.0beta2 JMS DestinationManager issue
The JMS DestinationManager is not adding Remote JMS queue/topics into it's hashmap of destinations when using JMSProviderLoader that has a ProviderUrl that points to another JBoss instance that houses the queues/topics. I added some trace logging to the JMSDestinationManager that dumps the hashmap it uses internal to store queue/topic names and it appears that it is only adding queue and topic names that it finds in the local JNDI space and not the remote JNDI space. I am playing with the default jboss target and have added the following to the jms-service.xml file in addition to the DefaultJBossMQProvider. mbean code=org.jboss.jms.jndi.JMSProviderLoader name=jboss.mq:service=JMSProviderLoader,name=RemoteJBossMQProvider attribute name=ProviderNameRemoteJMSProvider/attribute attribute name=ProviderAdapterClass org.jboss.jms.jndi.JBossMQProvider /attribute attribute name=QueueFactoryRefjava:/XAConnectionFactory/attribute attribute name=TopicFactoryRefjava:/XAConnectionFactory/attribute attribute name=ProviderUrl10.9.159.250:1099/attribute /mbean The RemoteJBossMQProvider service is loading correctly and shows up in the java:/ name space. I also check the context that is stored in the instance of JBossMQProvider class (which extends the abstract class AbstractJMSProviderAdapter) that is created for the RemoteJBossMQProvider, and it appears to be correctly anchored to the remote host. Not sure why the DestinationManager is not registering the queues/topics on the remote node. It is also not clear to me how the DestinationManager differentiates between local queues and remote queues. What prompted this discovery was my MDB's that use the RemoteJMSProvider instead of the DefaultJMSProvider complained at deployment time that their destination queues do not exist, when in fact they do on the remote host. This appears to be a bug, but I wanted to run it by this list before I submit it as a bug. Any suggestions? Dustin --- 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] writing a jboss.net (jmx.net?) client
CGJ, Thanks for your response. A) generate wsdl from the deployed web services. B) generate stub classes from the wsdl using wsdl2java. This is the first thing that I tried and it did not work. I didn't take a lot of time to firgure out why this is the case, since the jboss.net testcase code was easy to understand, so I may have missed something simple... This may work for simple cases, but once you declare additional data structures and serializers, it becomes very hairy on the client side, otherwise. Well, for my purposes, I don't intend on sending complex Object graphs over the wire. I also think that the Bean Serializer should be sufficient for my purposes. By may work, do you mean will work without errors for simple cases, or probably won't work for any case, so don't even try it? Is there a test case that demonstrates the technique (A B above) that you reccommend? I would find this quite useful. If I have time, I'll try to write one myself, if it doesn't already exist. On code generation in general, I must admit that I have a bit of healthy skepticism on the matter. In this example, the amount of client side code required to use the deprecated technique totals no more than a few lines, while the output of wsdl2java comprises multiple full-fledged classes. It seems to me that, auto-generated or not, this compromises a significant ramp-up in code maitennance costs. Based on your experience, what makes code generation the way to go in this case? Do you find the generated code reasonable, easy to maintain, scalable, reliable, etc.? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr. Christoph Sent: Tuesday, September 24, 2002 10:06 AM To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] writing a jboss.net (jmx.net?) client Matt, For getting the client-side invocations and stub classes right, we recommend The following steps: A) generate wsdl from the deployed web services. B) generate stub classes from the wsdl using wsdl2java. Using Axis/MbeanInvocationHandler lacks a lot of deployment information (basically, The client-side of the web-service.xml) that we try to default from java reflection. This may work for simple cases, but once you declare additional data structures and serializers, it becomes very hairy on the client side, otherwise. CGJ -Ursprüngliche Nachricht- Von: Matt Munz [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 20. September 2002 17:41 An: JBoss Developers Group Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client CGJ JBoss.Net Developers, First, let me say Thank you. I now have MBeans in the server exposed as web services. Although it took a bit of research to figure out how to do this, the minimal amount of (xml) code required to expose MBeans as webservices (should I call this JMX.Net?) speaks for itself. I was again pleased to see that the client side is also straightforward, once I knew what to do. Basically, I emulated the code in the testsuite for JBoss.Net. This works with the following caveat. The org.jboss.net.axis.AxisInvocationHandler class is deprecated. MBeanInvocationHandler, the class I am using on the client side, extends AxisInvocationHandler. What should I do instead of using this class (which seems to work perfectly well)? I found the following in AxisInvocationHandler. Could anyone explain this further? Due to the inherent deficiencies in using pure reflection meat-data to access web services, we recommend using the axis stub way of creating web service references Thanks again. - 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 ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.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
[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: Open Resolution: None 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. -- 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
Re: [JBoss-dev] JDK 1.4 daily tests?
Michael Bartmann wrote: Dain Sundstrom wrote: Do we run daily tests on 1.4 anymore? Is anyone running in production on 1.4? We are. But we use 3.2, where there is no daily test anyway. Biggest issues: - memory leak - Clients with 1.3 fail to connect to JMS-OIL-Topics, but succeed with JMS-RMI-Topics Are you using 1.4.0 or 1.4.1? -dain --- 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] Another Jetty redeploy issue
I merged some additional web integration tests from 3.0 and 3.2 and now both branches are failing the WebIntegrationUnitTestCase.testBadWarRedeploy and WebIntegrationUnitTestCase.testBadEarRedeploy tests. This is a different failure from the previous hot redeployment problem as in this case the redeployed war has a different name and so there is no conflict at the file level. The same tests work with the tomcat-4.0.5 container so the issue does not appear to be at the AbstractWebContainer level. See the following for the details: http://sourceforge.net/tracker/?func=detailatid=376685aid=613882group_id=22866 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
Re: [JBoss-dev] AspectJ and the JBoss aspect stuff...
Jason, After just seeing a jboss presentation (by danch btw), I was thinking about this too (I had just seen the AspectJ stuff before). I could see creating an AspectDeployer and the notion of an aspect-archive (aar) - the aspect-j code inside would then be compiled on deployment using the aspectj tools (like a jsp-kinda) but then I'm not sure what all you would get from that. You'd almost want an aspect-mbean. At some point, you could derive the interceptor stack (wouldn't be a stack anymore) from aspect-j code. Maybe that's what I haven't seen yet is the aspect-invoker, then you wouldn't need the aspect-mbean. Have no idea if the aspect stuff plays well with the JMX micro kernal but that might be another direction to take this. Brian Repko nVISIA Original Message Follows From: Jason Dillon [EMAIL PROTECTED] Subject: [JBoss-dev] AspectJ and the JBoss aspect stuff... Date: Thu, 19 Sep 2002 16:03:23 -0700 Just curious if anyone has looked at AspectJ... if you have please ignore me. --jason _ Chat with friends online, try MSN Messenger: http://messenger.msn.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
[JBoss-dev] [ jboss-Bugs-583618 ] Incorrect EJB-QL to SQL translation
Bugs item #583618, was opened at 2002-07-19 05:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=583618group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Lamar Channell (channell) Assigned to: Alexey Loubyansky (loubyansky) Summary: Incorrect EJB-QL to SQL translation Initial Comment: Hi, I have serveral tables. One table called project keeps track of unique projects. One table called project_tie ties an individual project to other data stored in other tables. Multiple tables exist to store project data, say project_data1, project_data2, etc. project Pk ProjectName 1 Project 1 2 Project 4 project_tie Pk ProjectPk TieToTable TieToPk 3 1 project_data1 7 4 2 project_data1 9 project_data1 Pk Value 7 project data for project 1 9 project data for project 2 I'm using JBoss 3.0 Final with CMP. I have EJB's for project, project_tie, project_data1. However, I do not have any relations defined yet because there are approx. 50 project_dataX tables. I would expect to be able to do a standard type query with EJB-QL. My EJB-QL for getting infomation from the project_data1 table for a given project looks like: select object(p) from project_data1 p, project_tie t where t.TieToTable = project_data1 and t.TieToPk = p.Pk and t.ProjectPk = ?1 The generated SQL is: select t0_p.Pk from project_data1 t0_p, project_tie t1_t where (t1_t.TieToTable = project_data1) and (t1_t.TieToPk = t0_p.TieToPk) and (t1_t.ProjectPk = ?) An 'Invalid column name' exception is thrown when the query gets executed. The t.TieToPk = p.Pk in the where clause was translated incorrectly to t1_t.TieToPk = t0_p.TieToPk but the TieToPk column does not exist in the project_data1 table. Attached is a sample testcase. Thanks, Lamar -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-09-24 20:49 Message: Logged In: YES user_id=543482 Dain, I'll look at it. alex -- Comment By: Lamar Channell (channell) Date: 2002-07-22 20:31 Message: Logged In: YES user_id=566307 I'll try to attach the testcase again. Thanks, Lamar -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-07-21 00:07 Message: Logged In: YES user_id=251431 You have not attached a testcase. Have you declared an exact table mapping in your jbosscmp-jdbc.xml file? The specification of the mapping is described in the JBoss Quick Start Guide and the JBossCMP documentation. If you are not declaraing a mapping, then JBossCMP will automatically generate a mapping for the entity. The default mapping is not gaurenteed to follow any rules and can be completely random. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=583618group_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] JDK 1.4 daily tests?
Dain Sundstrom wrote: Michael Bartmann wrote: Dain Sundstrom wrote: Do we run daily tests on 1.4 anymore? Is anyone running in production on 1.4? We are. But we use 3.2, where there is no daily test anyway. Biggest issues: - memory leak - Clients with 1.3 fail to connect to JMS-OIL-Topics, but succeed with JMS-RMI-Topics Are you using 1.4.0 or 1.4.1? 1.4.0-b32 - michael -dain --- 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] [ jboss-Patches-609097 ] LoginModule role tologinmodules
I have got it uploaded now. It was a stupid checkbox that had to be checked to have it upload anything (can't understand why it is there). Anyway: I did some testing of it, but it seems the run-as-role LoginModule is used outside the loginmodule also (in calls not gone thru any loginmodule. So I am not sure if it is something wrong with my popping of it, or a thread issue (as it doesn't do that all the time). Therefore, could someone that knows this (Scott?), take a look at this. I have seen more people in the forums having the same problem (that this patch is supposed to solve). On Sun, Sep 15, 2002 at 10:29:16PM -0700, Scott M Stark wrote: This patch has nothing attached to it to verify. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Marius Kotsbak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 13, 2002 2:23 PM Subject: Re: [JBoss-dev] [ jboss-Patches-609097 ] LoginModule role tologinmodules Could someone please verify that this is the right way to do it. It seems to work, but I don't know if it is thread-safe and work in all cases. I am thinking of expanding it to get the rolename to use from somewhere (not hardcoded). Anyone that have any opinions of this, and some hints of how I get this configuration data. On Fri, 2002-09-13 at 23:14, [EMAIL PROTECTED] wrote: Patches item #609097, was opened at 2002-09-13 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=609097group_id=22866 Category: JBossSX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marius Kotsbak (mkotsbak) Assigned to: Nobody/Anonymous (nobody) Summary: LoginModule role to loginmodules Initial Comment: This patch partly implements my own feature request 609087. It gives the code inside the loginmodule the role named LoginModule. --- 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 -- MVH Marius Kotsbak Boost communications AS --- 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-609132 ] Can't compile with Sun JDK 1.4.1rc-b19
Bugs item #609132, was opened at 2002-09-13 17:58
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=609132group_id=22866
Category: Build System
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Romahn (diggermaus)
Assigned to: Jason Dillon (user57)
Summary: Can't compile with Sun JDK 1.4.1rc-b19
Initial Comment:
I checked out the tagged version 'JBoss_3_2_0_1' on
Linux and are trying to compile it with Sun's latest JDK.
After some time, I am getting the following error
messages which leads to an abort of ant:
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:621:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
if (moduleStack[i].module != null) {
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:622:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
methods =
moduleStack[i].module.getClass().getMethods();
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:636:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
moduleStack[i].module =
constructor.newInstance(args);
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:638:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
methods =
moduleStack[i].module.getClass().getMethods();
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:651:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
methods[mIndex].invoke(moduleStack[i].module, initArgs);
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:665:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
(moduleStack[i].module,
args)).booleanValue();
All error messages suggest that the method 'module' in
class AppConfigurationEntry does not exist.
It compiles and runs fine with Sun's JDK1.3.1.
--
Comment By: Matthew Munz (mattmunz)
Date: 2002-09-24 14:31
Message:
Logged In: YES
user_id=340814
I have written and am currently using a patch for this defect.
This class (LoginContext) starts with a comment that says
that it is Sun-licensed. As such, I am not sure if JBoss
should be applying the patch, or if Sun should.
Could a knowledgeable JBoss developer please comment on
this situation? Should I commit my patch, or should I submit
it to Sun, or both, or what?
- Matt
--
Comment By: Oskari Kettunen (aok)
Date: 2002-09-14 10:01
Message:
Logged In: YES
user_id=558871
Hello,
I've had the same problem, I faintly recollect someone
suggesting on the devel-list that the javax.security stuff
shouldn't be compiled on j2sdk1.4.1
So, my workaround (in building cvs HEAD) has been:
rm -rf security/src/main/javax
as far as I can tell, it works just fine.
The bug's been around for a while now, apparently a fix isn't
very high on the list or the solution is more complicated than
it seems.
Oskari Kettunen
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=609132group_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-609132 ] Can't compile with Sun JDK 1.4.1rc-b19
Bugs item #609132, was opened at 2002-09-13 15:58
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=609132group_id=22866
Category: Build System
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ulrich Romahn (diggermaus)
Assigned to: Jason Dillon (user57)
Summary: Can't compile with Sun JDK 1.4.1rc-b19
Initial Comment:
I checked out the tagged version 'JBoss_3_2_0_1' on
Linux and are trying to compile it with Sun's latest JDK.
After some time, I am getting the following error
messages which leads to an abort of ant:
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:621:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
if (moduleStack[i].module != null) {
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:622:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
methods =
moduleStack[i].module.getClass().getMethods();
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:636:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
moduleStack[i].module =
constructor.newInstance(args);
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:638:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
methods =
moduleStack[i].module.getClass().getMethods();
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:651:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
methods[mIndex].invoke(moduleStack[i].module, initArgs);
^
/home/uroma/java_dev/src/jboss-all/security/src/main/javax/security/auth/login/LoginContext.java:665:
cannot resolve symbol
symbol : variable module
location: class
javax.security.auth.login.AppConfigurationEntry
(moduleStack[i].module,
args)).booleanValue();
All error messages suggest that the method 'module' in
class AppConfigurationEntry does not exist.
It compiles and runs fine with Sun's JDK1.3.1.
--
Comment By: Scott M Stark (starksm)
Date: 2002-09-24 12:52
Message:
Logged In: YES
user_id=175228
This has already been fixed in all Branch_3_0, Branch_3_2
and head.
--
Comment By: Matthew Munz (mattmunz)
Date: 2002-09-24 12:31
Message:
Logged In: YES
user_id=340814
I have written and am currently using a patch for this defect.
This class (LoginContext) starts with a comment that says
that it is Sun-licensed. As such, I am not sure if JBoss
should be applying the patch, or if Sun should.
Could a knowledgeable JBoss developer please comment on
this situation? Should I commit my patch, or should I submit
it to Sun, or both, or what?
- Matt
--
Comment By: Oskari Kettunen (aok)
Date: 2002-09-14 08:01
Message:
Logged In: YES
user_id=558871
Hello,
I've had the same problem, I faintly recollect someone
suggesting on the devel-list that the javax.security stuff
shouldn't be compiled on j2sdk1.4.1
So, my workaround (in building cvs HEAD) has been:
rm -rf security/src/main/javax
as far as I can tell, it works just fine.
The bug's been around for a while now, apparently a fix isn't
very high on the list or the solution is more complicated than
it seems.
Oskari Kettunen
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=609132group_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-614038 ] Server.start() after Server.shutdown()
Bugs item #614038, was opened at 2002-09-24 22:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=614038group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Sven Luzar (sven_luzar) Assigned to: Nobody/Anonymous (nobody) Summary: Server.start() after Server.shutdown() Initial Comment: I want to start and stop the JBoss server with my own Main Class (without exiting the VM). Therefore I use direct the ServerImpl class. But I can't restart the server after shutdown. The error message is: java.lang.Error: factory already defined at java.net.URL.setURLStreamHandlerFactory (URL.java:1027) at org.jboss.system.server.ServerImpl.doInit (ServerImpl.java:150) at org.jboss.system.server.ServerImpl.init (ServerImpl.java:117) I think the problem can be solved by creating a try catch block for the setURLStreamHanderFactory method in the class ServerImpl at line 150. For tests you can use the attachment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=614038group_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-598686 ] JBoss 3.0.1 later no work with IBM JRE
Bugs item #598686, was opened at 2002-08-22 02:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=598686group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 7 Submitted By: Nick Ganju (nganju) Assigned to: Scott M Stark (starksm) Summary: JBoss 3.0.1 later no work with IBM JRE Initial Comment: There is some incompatibility with the call to PropertyEditorManager.setEditorSearchPath(newPath) in the file org.jboss.util.propertyeditor.PropertyEditors. There is an old version of this class which makes calls to PropertyEditorManager.registerEditor(). When I replace the new version in the jboss-common.jar file with this old version, it works with IBM JRE. Probably IBM JRE has a bug in the PropertyEditorManager.setEditorSearchPath() call. I would recommend that you try to make your codebase compatible with IBM JRE, because it is substantially faster on linux. -- Comment By: Scott M Stark (starksm) Date: 2002-09-24 14:11 Message: Logged In: YES user_id=175228 A workaround of preloading the custom JBoss editors solves this problem. The change is active in the 3.0 branch and committed to 3.2 and head but needs to be enabled by uncommenting the PropertyEditorManagerService in the conf/jboss-service.xml file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=598686group_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-604258 ] Client-side use of SecurityAssociation
Bugs item #604258, was opened at 2002-09-03 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604258group_id=22866 Category: JBossSX Group: v3.0 Rabbit Hole Status: Closed Resolution: Rejected Priority: 5 Submitted By: Steve Lynch (aaprincipal) Assigned to: Nobody/Anonymous (nobody) Summary: Client-side use of SecurityAssociation Initial Comment: No debug trace available. The following is simply the observed effect of client-side calls to 'secured' EJBs. Scenario: A client app (in this a Java app run from the command line) holds several Subjects as a result of calls to several different LoginContexts. Calls to the same session bean were made using these different Subjects by means of 'Subject.doAs(...)'. This scenario may not be common but does not seem unreasonable. Observation: The effect as far as roles/permissions at the server was as if the Subject was that of the last successful call to 'LoginContext.login()' rather than, as expected, that of the 'Subject.doAs()' Subject. Workaround: Setting the ClientLoginModule to 'multi- threaded' and having associated '...login()'/'...doAs()' calls in a separate thread brought about the desired effect but seemed cumbersome under the circumstances. Note: It seems to me that the SecurityAssociation, whilst a good Principal/Credential - Subject mapping mechanism at the server-side, is inappropriate at the client side. Surely the Subject _is_ the mapping mechanism - would also get rid of the need for 'multi- threaded' flag. -- Comment By: Scott M Stark (starksm) Date: 2002-09-24 14:27 Message: Logged In: YES user_id=175228 Having to use the Subject.doAs construct is too instrusive and non-portable. If you want this as the mechanism for client side propagation of the thread caller write your own client side security interceptor. -- Comment By: Holger Engels (hengels) Date: 2002-09-04 01:51 Message: Logged In: YES user_id=315382 what you actually need is a client container, that deploys a application-client jar, where you can define ejb-refs and provide run-as mappings. Subject.doAs is another possibility, that works without client the container approach. In any case, the association of the correct principal with the invocation is the job of a client side interceptor. Holger PS: it's always the same with me: I have ideas, I am taking part at discussions but don't have the time to actually DO it. Sorry! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=604258group_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-597216 ] Jetty in 3.0.1 has broken Jasper
Bugs item #597216, was opened at 2002-08-19 09:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=597216group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Jetty in 3.0.1 has broken Jasper Initial Comment: JBoss Release 3.0.1, JDK1.4, Solaris 2.8 The Jetty included in this release contains a broken version of Jasper. As far as I remember it's a version from one of the Tomcat 4.0.4 Betas. I recognize it, because it always prints sun.tools.javac.Main has been deprecated., if a JSP compilation error occurred. Harmless. But: I am using the JSTL1.0 and the Jetty compiler chokes on some perfectly legal c:if/c:if constructs, just like Tomcat 4.0.4Beta(?) did. Could you please update Jasper to a newer version (4.1.x) where this bug has been fixed? OBTW: Shouldn't there be a Jetty category in the sf submit new bug form? Thanks. Georg -- Comment By: Scott M Stark (starksm) Date: 2002-09-24 14:29 Message: Logged In: YES user_id=175228 This is now out of date as jasper was updated in 3.0.2 and 3.0.3 -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-08-19 11:38 Message: Logged In: YES user_id=44062 We have been taking jasper from the head of tomcat 4 CVS. But I see they have created a separate CVS tree for jasper now, so I'll have a look see and try to work out what is the latest/best Not always easy with jakarta :-) regards -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=597216group_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-610552 ] PrefixDeploymentSorter and non-digit URL
Bugs item #610552, was opened at 2002-09-17 06:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=610552group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: PrefixDeploymentSorter and non-digit URL Initial Comment: If using org.jboss.deployment.scanner.PrefixDeploymentSorter those files beginning with non-digit are deployed FIRST, not LAST as declared in comments inside jboss-service.xml. This is because private int getPrefixValue(URL url) returns -1 if no digital prefix exists. It should return Integer.MAX_VALUE or something. -- Comment By: Scott M Stark (starksm) Date: 2002-09-24 14:21 Message: Logged In: YES user_id=175228 The docs have been updated. -- Comment By: Larry Sanderson (lsanders) Date: 2002-09-17 09:08 Message: Logged In: YES user_id=379453 This was my bad - the original implementation of this was to deploy prefixed first (as all the comments indicate). Then it was agreed to change this to prefixed last. I changed the code, but not the docs. I'll check in new docs today. -- Comment By: Christian Riege (lqd) Date: 2002-09-17 07:35 Message: Logged In: YES user_id=176671 The question is if this is a bug in the documentation or in the implementation :). The JavaDoc comments in PrefixDeploymentSorter are misleading here, too as they state: ... If there is no leading digits, then they will compare as less than any name with leading digits. and a few lines further down: Ex.these names are in ascending order: 001test.jar, 5test.rar, 5foo.jar, 120bar.jar, test.sar, crap.ear ) which contradicts the previous statement. Which one is the correct behaviour here? I would opt for the deploy with no prefix first strategy (as it is implemted ATM) and fix the comments in the .xml file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=610552group_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-611270 ] No longer boots form dirs with spaces
Bugs item #611270, was opened at 2002-09-18 13:33
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=611270group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Nathan W. Phelps (nphelps)
Assigned to: Nobody/Anonymous (nobody)
Summary: No longer boots form dirs with spaces
Initial Comment:
I'm using JBoss 3.0.2 on Windows XP and JDK 1.4.1
and I am unable to get it to boot when JBOSS_HOME
is C:\Program Files\JBoss. I used JBoss 3.0 from
this exact same directory, but evidenlty this is broken
now. This was one of the things I really liked about
JBoss. I hate putting things at root. Here is the server
trace:
15:30:59,941 INFO [Server] Starting JBoss (MX
MicroKernel)...
15:30:59,941 INFO [Server] Release ID: JBoss
[WonderLand] 3.2.0beta (build: JBoss_3_2_0_beta
200209161335)
15:30:59,941 DEBUG [Server] Using config:
org.jboss.system.server.ServerConfigImpl@7bd9f2
15:30:59,941 DEBUG [Server] Server type: class
org.jboss.system.server.ServerImpl
15:30:59,957 INFO [Server] Home Dir: C:\Program%
20Files\jboss-3.2.0beta
15:30:59,957 INFO [Server] Home URL:
file:/C:/Program%20Files/jboss-3.2.0beta/
15:30:59,957 INFO [Server] Library URL:
file:/C:/Program%20Files/jboss-3.2.0beta/lib/
15:30:59,973 INFO [Server] Patch URL: null
15:30:59,973 INFO [Server] Server Name: default
15:30:59,973 INFO [Server] Server Home Dir:
C:\Program%20Files\jboss-3.2.0beta\server\default
15:30:59,973 INFO [Server] Server Home URL:
file:/C:/Program%20Files/jboss-3.2.0beta/server/default/
15:30:59,988 INFO [Server] Server Data Dir:
C:\Program%20Files\jboss-3.2.0beta\server\default\data
15:30:59,988 INFO [Server] Server Temp Dir:
C:\Program%20Files\jboss-3.2.0beta\server\default\tmp
15:30:59,988 INFO [Server] Server Config URL:
file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/conf/
15:30:59,988 INFO [Server] Server Library URL:
file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/lib/
15:30:59,988 INFO [Server] Root Deployemnt
Filename: jboss-service.xml
15:31:00,004 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:31:00,270 DEBUG [Server] Created MBeanServer:
org.jboss.mx.server.MBeanServerImpl@2ce908
15:31:00,285 DEBUG [Server] Boot url list:
[file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/conf/]
15:31:00,285 DEBUG [Server] Creating loader for URL:
file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/conf/
15:31:00,301 DEBUG [UnifiedClassLoader] New jmx
UCL with url file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/conf/
15:31:00,301 DEBUG [UnifiedClassLoader] New jmx
UCL with url file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/conf/
15:31:00,301 DEBUG [UnifiedLoaderRepository2]
Adding
org.jboss.mx.loading.UnifiedClassLoader@d80be3{
url=file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/conf/ }
15:31:00,317 DEBUG [UnifiedLoaderRepository2] Failed
to update pkgs for
cl=org.jboss.mx.loading.UnifiedClassLoader@d80be3{
url=file:/C:/Program%20Files/jboss-
3.2.0beta/server/default/conf/ }
java.io.FileNotFoundException: C:\Program%
20Files\jboss-3.2.0beta\server\default\conf (The system
cannot find the file specified)
at java.io.FileInputStream.open(Native
Method)
at java.io.FileInputStream.init
(FileInputStream.java:103)
at
org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterato
r.init(ClassLoaderUtils.java:254)
at
org.jboss.mx.loading.ClassLoaderUtils.updatePackageM
ap(ClassLoaderUtils.java:42)
at
org.jboss.mx.loading.UnifiedLoaderRepository2.updateP
ackageMap(UnifiedLoaderRepository2.java:581)
at
org.jboss.mx.loading.UnifiedLoaderRepository2.addUnifie
dClassLoader(UnifiedLoaderRepository2.java:566)
at
org.jboss.mx.loading.UnifiedLoaderRepository2.addClas
sLoader(UnifiedLoaderRepository2.java:526)
at
org.jboss.mx.loading.UnifiedLoaderRepository2.newClas
sLoader(UnifiedLoaderRepository2.java:114)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:549)
at
org.jboss.system.server.ServerImpl.initBootLibraries
(ServerImpl.java:447)
at org.jboss.system.server.ServerImpl.doStart
(ServerImpl.java:276)
at org.jboss.system.server.ServerImpl.start
(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:146)
at org.jboss.Main$1.run(Main.java:379)
at java.lang.Thread.run(Thread.java:536)
15:31:00,332 INFO [ServerInfo] Java version: 1.4.1,Sun
Microsystems Inc.
15:31:00,332
[JBoss-dev] [ jboss-Bugs-594580 ] 3.0.1 tar file is bad
Bugs item #594580, was opened at 2002-08-13 06:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=594580group_id=22866 Category: Build System Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: Peter Callies (pcallies) Assigned to: Jason Dillon (user57) Summary: 3.0.1 tar file is bad Initial Comment: The 3.0.1 tar file contains @LongLink filenames which prevent JBoss from working correctly on unix systems. See below for a small sampling (obtained by executing tar tvf jboss-3.0.1.tar | more). rw-r--r-- 0/0281 Jun 28 04:22 2002 jboss- 3.0.1/server/all/deploy/jmx-console. war/WEB-INF/jboss-web.xml rw-r--r-- 0/0113 Aug 6 23:57 2002 ././@LongLink rw-r--r-- 0/0899 Aug 6 23:42 2002 jboss- 3.0.1/server/all/deploy/jmx-console. war/WEB- INF/classes/org/jboss/jmx/adaptor/control/AttrResu rw-r--r-- 0/0111 Aug 6 23:57 2002 ././@LongLink rw-r--r-- 0/0589 Aug 6 23:42 2002 jboss- 3.0.1/server/all/deploy/jmx-console. war/WEB- INF/classes/org/jboss/jmx/adaptor/control/OpResult rw-r--r-- 0/0105 Aug 6 23:57 2002 ././@LongLink rw-r--r-- 0/0 9905 Aug 6 23:42 2002 jboss- 3.0.1/server/all/deploy/jmx-console. war/WEB- INF/classes/org/jboss/jmx/adaptor/control/Server.c rw-r--r-- 0/0106 Aug 6 23:57 2002 ././@LongLink rw-r--r-- 0/0 1278 Aug 6 23:42 2002 jboss- 3.0.1/server/all/deploy/jmx-console. war/WEB- INF/classes/org/jboss/jmx/adaptor/model/MBeanData. rw-r--r-- 0/0107 Aug 6 23:57 2002 ././@LongLink rw-r--r-- 0/0 1724 Aug 6 23:42 2002 jboss- 3.0.1/server/all/deploy/jmx-console. war/WEB- INF/classes/org/jboss/jmx/adaptor/model/DomainData rw-r--r-- 0/0114 Aug 6 23:57 2002 ././@LongLink rw-r--r-- 0/0 7193 Aug 6 23:42 2002 jboss- 3.0.1/server/all/deploy/jmx-console. war/WEB- INF/classes/org/jboss/jmx/adaptor/html/HtmlAdaptor -- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-19 07:58 Message: Logged In: NO No problem on linux (suse), so it's probably one of your tools that needs to be upgraded (tar, ant etc) -- Comment By: Adam Heath (doogie) Date: 2002-08-19 07:11 Message: Logged In: YES user_id=9692 ././@LinkLink is a GNU extension to the tar format, that allows for symlinks and file names of any length. Most likely ant supports this(it's not difficult to do). JBoss is a very large system. It contains lots of files, with very deep directories. Because of the default tar limit of 100 chars for a file name, JBoss easily goes over this limit. I suggest the filer install gnu tar, and that this bug be closed as won't fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=594580group_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-597713 ] Transient Keyword Problem
Bugs item #597713, was opened at 2002-08-20 04:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=597713group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: Joao Machado (joaocm) Assigned to: Nobody/Anonymous (nobody) Summary: Transient Keyword Problem Initial Comment: When I call a remote procedure inside the same virtual machine, the transient fields do not have the expected behavior. For example if I have a transient int field, because it's not serialized for performace issues, it not became zero. So the optmization has broken an expected and normal behavior of a Java keyword. -- Comment By: Scott M Stark (starksm) Date: 2002-09-24 14:33 Message: Logged In: YES user_id=175228 You have to initial the transient field anytime serialization occurs. This is normal transient behavior in the presence of serialization. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=597713group_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-565804 ] JBossUserPrincipal not cleared
Bugs item #565804, was opened at 2002-06-07 06:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=565804group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andrew Thorn (sigbur) Assigned to: Nobody/Anonymous (nobody) Summary: JBossUserPrincipal not cleared Initial Comment: I have an application that regressed between JBoss 3.0 RC3 and JBoss 3.0.0 Final. A call from a JSP to session.invalidate() has become inconsistent. Using FORM based login to a Jetty web application. I have set up a security-constraint in web.xml that protects index.jsp and requires someone with 'user' role must be logged in to see it. If the web application is accessed from the http://myhost:8080/mywebapp/ URL, index.jsp is displayed without forwarding to the login.jsp named in the login-config. If http://myhost:8080/mywebapp/index.jsp is accessed, the forwarding to login.jsp *is* done. A call to session.invalidate() in my logout.jsp used to work properly, but now it doesn't seem to clear the session properly. The web application will still intermittently remember who was logged in last. As stated, JBoss 3.0RC3 does not exhibit this behaviour. The following log trace occurred after the following sequence. Log in as admin, navigate application for a little while. Log out (with session.invalidate()) then log in as publisher. Log out. Then I was able to go to my index.jsp, and when it forwarded to login.jsp, the 'admin' principal suddenly reappeared as active. 2002-06-07 09:03:27,679 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:27,680 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:38,079 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,079 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,082 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: admin 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is NOT in Role: publisher 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is NOT in Role: publisher2002-06-07 09:03:27,679 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:27,680 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:38,079 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,079 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,082 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: admin 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is NOT in Role: publisher 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is NOT in Role: publisher2002-06-07 09:03:27,679 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:27,680 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:38,079 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,079 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,082 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: admin 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is NOT in Role: publisher 2002-06-07 09:03:38,083 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is NOT in Role: publisher2002-06-07 09:03:27,679 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:27,680 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: publisher is in Role: publisher 2002-06-07 09:03:38,079 DEBUG [org.jboss.jetty.security.JBossUserRealm#SDPA] JBossUserPrincipal: admin is in Role: user 2002-06-07 09:03:38,079 DEBUG
[JBoss-dev] JMS bug fix for Client Acknowledgment
Is the following bug fix of JBOSS JMS JbossQ included in any JBOSS releases yet? [ 526696 ] session.recover() doesn't work It appears that any of current JBOSS releases doesnt incorporate latest JbossQ JMS component build. Above fix is submitted 2 months back. So when this fix appears in the complete JBOSS suite release. I guess this question actually should be aimed to JBOSS team. thanks Venkat --- 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] change in oracle-service.xml in HEAD
I'm testing some code against HEAD and I saw that there's some changes at oracle-service.xml format. did the attribute name=JndiNameOracleDS/attribute attribute was moved out of the mbean code=org.jboss.resource.connectionmanager.RARDeployment... tag??? -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- 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] error when deploying a working ear (in 3.0.1) in HEAD
I managed to make oracle-service work (although i didn't undertand why the place of jndi attribute was changed) when deploying a ear that worked fine in 3.0.1 in HEAD (4.0.0ALPHA) i got the following error : 19:23:36,595 ERROR [MainDeployer] could not start deployment: file:/home/emersonc/jboss-all/build/output/jboss-4.0.0alpha/server/default/tmp/deploy/server/default/deploy/cob.ear/78.cob.ear-contents/cob-web.war org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.NullPointerException) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:473) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:833) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:825) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600) at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy8.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:392) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentScanner.java:611) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:464) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:187) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:197) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:177) Caused by: java.lang.NullPointerException at org.mortbay.j2ee.session.Manager.start(Manager.java:159) at org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:409) at org.mortbay.jetty.servlet.WebApplicationHandler.start(WebApplicationHandler.java:142) at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1770) at org.jboss.jetty.JBossWebApplicationContext.startHandlers(JBossWebApplicationContext.java:260) at org.mortbay.http.HttpContext.start(HttpContext.java:1740) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:471) at org.mortbay.j2ee.J2EEWebApplicationContext.start(J2EEWebApplicationContext.java:85) at org.jboss.jetty.Jetty.deploy(Jetty.java:409) at org.jboss.jetty.JettyService.performDeploy(JettyService.java:243) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:468) ... 17 more -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- 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-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 16:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(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$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
Re: [JBoss-dev] change in oracle-service.xml in HEAD
Yes. I strongly suggest you use the *-ds.xml files instedad of the *-service.xml files for datasource setup in 3.2 and head. david jencks On 2002.09.24 18:14:24 -0400 Emerson Cargnin - SICREDI Serviços wrote: I'm testing some code against HEAD and I saw that there's some changes at oracle-service.xml format. did the attribute name=JndiNameOracleDS/attribute attribute was moved out of the mbean code=org.jboss.resource.connectionmanager.RARDeployment... tag??? -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- 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] Automated JBoss(HEAD Matrix2) Testsuite Results: 25-September-2002
Number of tests run: 960 Successful tests: 933 Errors:20 Failures: 7 [time of test: 25 September 2002 1:51 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
Re: [JBoss-dev] change in oracle-service.xml in HEAD
David Jencks wrote: Yes. is there any reason for that? this question is becouse that this kind of change generates a lot of trouble (and questions to jboss-user list) when upgrading the server. I strongly suggest you use the *-ds.xml files instedad of the *-service.xml files for datasource setup in 3.2 and head. ok, the exemple file in cvs should be changed too, I suppose. david jencks On 2002.09.24 18:14:24 -0400 Emerson Cargnin - SICREDI Serviços wrote: I'm testing some code against HEAD and I saw that there's some changes at oracle-service.xml format. did the attribute name=JndiNameOracleDS/attribute attribute was moved out of the mbean code=org.jboss.resource.connectionmanager.RARDeployment... tag??? -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- 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 -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- 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] change in oracle-service.xml in HEAD
On 2002.09.24 21:11:36 -0400 Emerson Cargnin - SICREDI Serviços wrote: David Jencks wrote: Yes. is there any reason for that? this question is becouse that this kind of change generates a lot of trouble (and questions to jboss-user list) when upgrading the server. Putting the jndiname in the RARDeployment mbean was a mistake, and I wanted to correct it sooner rather than later. Future versions of adapter deployment will deploy the ManagedConnectionFactory instance directly as an xmbean without needing a RARDeployment wrapper. To do this, only ManagedConnectionFactory methods can be used on what is now the RARDeployment. I strongly suggest you use the *-ds.xml files instedad of the *-service.xml files for datasource setup in 3.2 and head. ok, the exemple file in cvs should be changed too, I suppose. ??? I just double checked the oracle and oracle xa example files in 3.2 and head and they are correct. When I made the change I was pretty careful to change all the examples at the same time. david jencks david jencks On 2002.09.24 18:14:24 -0400 Emerson Cargnin - SICREDI Serviços wrote: I'm testing some code against HEAD and I saw that there's some changes at oracle-service.xml format. did the attribute name=JndiNameOracleDS/attribute attribute was moved out of the mbean code=org.jboss.resource.connectionmanager.RARDeployment... tag??? -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- 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 -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4860| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- 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-Change Notes-614198 ] interrupt threads on tx timeout
Change Notes item #614198, was opened at 2002-09-24 23:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=614198group_id=22866 Category: None Group: v3.2 Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: interrupt threads on tx timeout Initial Comment: Threads involved with a timed out transaction are now interrupted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=614198group_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 10:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=580594group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None 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-580594 ] Encoded URLs are not handled correctly
Bugs item #580594, was opened at 2002-07-12 10:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=580594group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None 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-580594 ] Encoded URLs are not handled correctly
Bugs item #580594, was opened at 2002-07-12 10:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=580594group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None 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-605878 ] Unable to start JBoss Server in ProgFile
Bugs item #605878, was opened at 2002-09-06 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=605878group_id=22866 Category: JBossServer Group: v3.2 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Archimedes Trajano (trajano) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to start JBoss Server in ProgFile Initial Comment: I can't seem to start the JBoss Server from C:\Program Files\JBoss but no problems when starting from C:\JBoss. I assume its because of the space in the path name. -- Comment By: Archimedes Trajano (trajano) Date: 2002-09-25 02:05 Message: Logged In: YES user_id=55322 duplicate of 580594 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=605878group_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
