AW: AW: [JBoss-dev] 3.2.2 Issues to resolve
Bernd, There is nothing pathological about your package structure/meta-data. You could do me a facor and send the complete ear to mailto:[EMAIL PROTECTED] in order to quickly reproduce the problem. CU, CGJ -Ursprüngliche Nachricht- Von: Bernd Koecke [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 15. Oktober 2003 12:35 An: [EMAIL PROTECTED] Betreff: Re: AW: [JBoss-dev] 3.2.2 Issues to resolve Hi Christoph, I have an ear-file with some ejb-jars, war-file and one wsr-file. The included webservice is used by one of the EJBs. When I deploy my ear all works fine. All services are available. When I undeploy and deploy the ear again, all services are working, but the webservice can't be found. There are no errors, warnings etc. in server.log at deployment/redeployment, even if I switch level to debug. This happens only when I access the ws after deployment. Without using the webservice I could redeploy several times. But after the first usage and a following redeploy, I have to restart JBoss, otherwise the redeployed ws can't be found by the naming service. Attached are the dds from ear and the dds from the ejb with the webservice (bankchecker-app-net-0.2.0.wsr, bankchecker-app-ejb-0.2.0.jar) and a stacktrace of the NameNotFound- and NullPointerException. I have a small additional problem, maybe with the same reason. I can't set the JNDI-Path in web-service.xml to ws/BankChecker-v0_3_1 or ws/v0_3_1/BankChecker. Axis says at deployment that ws is not bound. Please send me a mail, when I missed something. Thanks a lot, Bernd Jung , Dr. Christoph wrote: Bernd, Could you please resend the symptoms(wsr content, dd, detailed steps you undertake, stacktrace ...) such that I can check whether it is a bug or a config error? CU, CGJ -Ursprüngliche Nachricht- Von: Bernd Koecke [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 14. Oktober 2003 10:21 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] 3.2.2 Issues to resolve Hi, I have a problem with redeployment of a webservice in a wsr-file. Thread on jboss-user: [JBoss-user] Redeploy problem of webservices on JBoss 3.2.2 I'm not sure if it is a bug or a config error. Webservices are not a core requirement of Spec 1.3. So I don't know if, in case of a bug, the solution should go into 3.2.2. But till now I don't have a solution. The newest version I tried was the snapshot from last night. Bernd Scott M Stark wrote: All but 786668 have been addressed and the 3.2 branch is being tagged with JBoss_3_2_2. I will complete the final testing tonight and do the release barring any major issues. -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-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: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] ### 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: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-824105 ] JBoss-IDE shuts down foreign server on the same net
Bugs item #824105, was opened at 2003-10-15 15:21 Message generated for change (Comment added) made by letiemble You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=824105group_id=22866 Category: JBoss-IDE Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Bernd Köcke (koecke) Assigned to: Laurent Etiemble (letiemble) Summary: JBoss-IDE shuts down foreign server on the same net Initial Comment: I'm using Eclipse 2.1.1 with Sun-JDK 1.4.2 JBoss-IDE 1.2.1 on Linux with JBoss 3.2.2RC4 When I use -s localhost:1199 -S as program arguments for shutdown in eclipse, JBoss on another machine in the same subnet is shutting down. JBoss on my machine listens on port 1099. And JBoss on the other machine too. I recognized this while I was playing around with the binding manager. It seems that if nobody answers on localhost, JBoss-IDE tries to connect on the network on the default port. I checked it with jnp://localhost:1199, my own machine name instead of localhost and I checked port numbers 1199, 1299, 9090 and 1099 when my machine listens on port 1199, nothing changes. It happens only, when I use a URL on which nobody listens on my server. There are no error messages or exceptions. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 10:00 Message: Logged In: YES user_id=437455 I think this is not a bug but a feature (in the spirit of the clustering creators). I agree that it is not obvious. Explanation : When no jndi server is found on the target machine, a multicast signal is sent to find another one on the same subnet. If another JBoss server is running with clustering enabled, it answers the request. To disable this behaviour, you have to add an entry in your jndi.properties file : jnp.disableDiscovery=true It will prevent your client to send a multicast signal. Tell me if it works and I will close this bug. -- Comment By: Bernd Köcke (koecke) Date: 2003-10-16 12:28 Message: Logged In: YES user_id=803141 Hi all, A small update: I could only shutdown JBoss-Server on other machines, if they have clustering enabled. I can do this from JBoss-IDE and commandline and I can do it with the smallest command (bin/shutdown.sh -S) too, when no JBoss is running on my machine or is not listening on port 1099. My local JBoss-config has no clustering enabled. Even it is not a JBoss-IDE bug, I think it is still a bug. When I call -s localhost:9090, no other host than localhost should be asked. Or can I configure this behaviour and it is a bug in my config? Thanks, Bernd -- Comment By: Bernd Köcke (koecke) Date: 2003-10-15 17:07 Message: Logged In: YES user_id=803141 Yes, it happens on command line, too. Sorry should have checked that prior to call it an IDE bug :(. But now I get the following stack trace: bin/shutdown.sh -s localhost:9090 -S 17:03:42,571 WARN [NamingContext] Failed to connect to localhost:9090 javax.naming.CommunicationException: Failed to connect to server localhost:9090 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:9090 [Root exception is java.net.ConnectException: Connection refused]] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:215) at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1181) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.jboss.Shutdown.main(Shutdown.java:180) Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server localhost:9090 [Root exception is java.net.ConnectException: Connection refused] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:190) ... 5 more Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:452) at java.net.Socket.connect(Socket.java:402) at java.net.Socket.init(Socket.java:309) at java.net.Socket.init(Socket.java:211) at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:69) at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:62) at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:186) ... 5 more Shutdown complete --
[JBoss-dev] [ jboss-Bugs-825139 ] Iterator typo in metadata class for user-type-mappings
Bugs item #825139, was opened at 2003-10-17 01:03 Message generated for change (Settings changed) made by loubyansky You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=825139group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Gerald Turner (crazyfoam) Assigned to: Alexey Loubyansky (loubyansky) Summary: Iterator typo in metadata class for user-type-mappings Initial Comment: Having more than one user-type-mapping in jbosscmp-jdbc.xml will only work with the first user-type-mapping, the others will be ignored. The cause is that the Iterator returned by MetaData.getChildrenByTagName is only looped once because there is no while (iter.hasNext()) surrounding the block that calls iter.next(). I hacked the cmp2/enum testcase so that there are two mappings instead of just one (I added AnimalEnum), furthermore I hacked the test so that the enum clases are no longer Serializable because otherwise when there's a bug in the mapping code such as this, and the JDBCTypeFactory falls back on object serialization the tests never fail! Attaching testcase patch and metadata patches separately. -- Comment By: Gerald Turner (crazyfoam) Date: 2003-10-17 01:07 Message: Logged In: YES user_id=571620 BTW, I would have written these patches agains Branch_3_2 (rather than 3.2.2RC4) but there appears to be CVS corruption, suprised nobody's mentioned it on the lists: cvs [server aborted]: unrecognized operation '\xff9c' in /cvsroot/jboss/thirdparty/apache/axis/lib/axis.jar,v -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=825139group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-825139 ] Iterator typo in metadata class for user-type-mappings
Bugs item #825139, was opened at 2003-10-17 01:03 Message generated for change (Comment added) made by loubyansky You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=825139group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Gerald Turner (crazyfoam) Assigned to: Alexey Loubyansky (loubyansky) Summary: Iterator typo in metadata class for user-type-mappings Initial Comment: Having more than one user-type-mapping in jbosscmp-jdbc.xml will only work with the first user-type-mapping, the others will be ignored. The cause is that the Iterator returned by MetaData.getChildrenByTagName is only looped once because there is no while (iter.hasNext()) surrounding the block that calls iter.next(). I hacked the cmp2/enum testcase so that there are two mappings instead of just one (I added AnimalEnum), furthermore I hacked the test so that the enum clases are no longer Serializable because otherwise when there's a bug in the mapping code such as this, and the JDBCTypeFactory falls back on object serialization the tests never fail! Attaching testcase patch and metadata patches separately. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-10-17 14:48 Message: Logged In: YES user_id=543482 Fixed in Branch_3_2. Thanks much! -- Comment By: Gerald Turner (crazyfoam) Date: 2003-10-17 01:07 Message: Logged In: YES user_id=571620 BTW, I would have written these patches agains Branch_3_2 (rather than 3.2.2RC4) but there appears to be CVS corruption, suprised nobody's mentioned it on the lists: cvs [server aborted]: unrecognized operation '\xff9c' in /cvsroot/jboss/thirdparty/apache/axis/lib/axis.jar,v -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=825139group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-569305 ] Server IP detection causes problems
Bugs item #569305, was opened at 2002-06-15 09:35 Message generated for change (Comment added) made by letiemble You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=569305group_id=22866 Category: None Group: None Status: Closed Resolution: Remind Priority: 5 Submitted By: Samuel Terrell (j3110) Assigned to: Laurent Etiemble (letiemble) Summary: Server IP detection causes problems Initial Comment: By default, on some Linux distributions, for performance and other reasons (some interfaces have dynamic IP's but the hosts ip shouldn't change), the host name of the local machine is configured to point to 127.0.0.1. When connecting through JNDI from a remote machine, the IP set in jndi.properties is overwritten with 127.0.0.1 on the client side. Obviously, this causes the client to fail connecting to the server. Other servers, Apache for example, warn the user that this is probably undesired behavior and allow a way to manually override the local IP with an option in the configuration files. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 14:04 Message: Logged In: YES user_id=437455 This is a known issue. See the complete FAQ here : http://www.jboss.org/thread.jsp?forum=67thread=8092 -- Comment By: alan shields (alanshields) Date: 2003-05-31 09:19 Message: Logged In: YES user_id=575453 Ive had a couple of issues with this where the ip address of the name returned by hostname is not the address of the server. With an AIX HA cluster this appears to be quite common, eg with a two node HACMP configuration: servera - hostname of machine a serverb - hostname of machine b service - service name machine a's host file ... ... 192.168.42.100 service 192.168.42.101 servera ... ... machine b's host file ... ... 192.168.42.100 service 192.168.42.102 serverb ... ... the 101 102 addresses exist at boot up, once one of the two machines takes control of the service address it's boot address is no longer available, now when jboss starts up (on machine a for instance) it looks up the hostname (servera) then looks up the ip address for that (192.168.42.101) then attempts to connect to itself on that address and fails. -- Comment By: Samuel Terrell (j3110) Date: 2003-01-16 20:56 Message: Logged In: YES user_id=563515 Being a developer too, I've given this much thought. I assume the server sends the IP back because of the possibility that the bean requested is on a different server in a cluster or the JNDI server has a different IP than the container. The root of this problem is that DNS records don't always exist for a particular server. Some people run load balaners or multihomed networks or firewalled networks that have a different IP than the local machine for the DNS record. In these situations, all the traffic that is to get to the Bob domain will hit an IP on a router, firewall, or load balancing system. From there, it will forward it (or not) to a particular client who has no dns record. Usually, it is a 192.168.* or 10.* address allocated for this particular purpose. This problem, as another poster mentioned, is compounded when you have multiple internet connections, multi-homed. In this situation, you will listen on a virtual IP address, but you want your clients to connect to any address it can of a list that MUST be entered by the admin. There is really no way of detecting these reliably, and it is a very common situation for anyone that wants true HA and performance. For example, most ISP's that offer coorperate web hosting that is reliable will have a connection through Sprint and one through Qwest or MCI or anyone else. That way when one of the backbones of the internet gets DOS'd/struck by lightening, only the poor saps that use their backbone will not have a connection to the server. What we end up with, in order to make a server work in all conditions, is slightly complicated. Other servers get away with this because they allow you to pass back host names that use DNS to resolve to the multiple IP's they connect to. This may work with JBoss, but it will not know which IP to listen on, and it can't listen on all interfaces. If it listens on all interfaces, then it will interfere with multipath routing daemons. What we need is a place to specify ListenIP, and a place to specify Hostname that may be different from the system hostname. Look at the JavaDoc for ServerSocket's constructors. They have a special constructor for this situation. The ideal solution is to be able to overide the defaults and set a list of ip's to bind to and listen on, and to have a seperate list that can be overridden to specify a list of IP's that clients will connect to. I say IP's for both because if you use DNS, then 1 DNS name
[JBoss-dev] [ jboss-Bugs-615650 ] Error in transaction handling
Bugs item #615650, was opened at 2002-09-27 21:33 Message generated for change (Comment added) made by letiemble You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615650group_id=22866 Category: None Group: v3.2 Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Michael Lipp (mlipp) Assigned to: Laurent Etiemble (letiemble) Summary: Error in transaction handling Initial Comment: MDB A calls method m of session bean B. Method m has transaction attribute RequiresNew. B.m throws a runtime exception. In response, A.onMessage calls X.y with X being some EntityBean. As the runtime exception happened in the newly opened transaction, only this sub-transaction should be rolled back, the modification made on X should persist. 3.0.2 behaves as described above. 3.2.0beta rolls back all transactions, including the call to X.y. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 15:21 Message: Logged In: YES user_id=437455 This works correctly on the latest 3.2 versions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=615650group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] optimizing marshalling
On Thu, 2003-10-16 at 22:55, Bill Burke wrote: I can optimize marshaling of EJB invocations over wire if I create new classes that extend older versions correct? As long as the old versions still work. A better approach would be to write a new proxy factory, leaving the option to use old proxy factory if older clients need to be supported. They could even be used together using two invoker proxy bindings. An older EJB RMI client should just download those class versions of the new interceptors, InvocationContexts, and Invocation classes I write. Only if a Security Manager is installed on the client. Regards, Adrian Of course, the PooledInvoker won't work with older versions, but any RMI invocations should be ok with new class types. Bill -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-825506 ] NoTxConnectionManager throws exception with IBM IMS JCA RA
Patches item #825506, was opened at 2003-10-17 16:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=825506group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Hawkins (khawkins) Assigned to: Nobody/Anonymous (nobody) Summary: NoTxConnectionManager throws exception with IBM IMS JCA RA Initial Comment: In JBoss 3.2.2, closing a connection to the IBM IMS JCA resource adapter throws an IllegalStateException. This appears to be because the managed connection in the IMS resource adapter calls connectionClosed with a null connection handle in the ConnectionEvent. While this is counter to the JCA specification, it has not caused any problem in previous JBoss versions or in any of the connection managers except for NoTx. This is because the connectionClosed event of other connection managers call getCcm().unregisterConnection within a try/catch block and any throwable results in an INFO message, but the unregisterConnection method continues. The NoTxConnectionEventListener does not use a try/catch block resulting in the method being terminated and the exception being propagated to the client. It appears that this behavior could result in the leak of managed connections. We have patched the NoTxConnectionEventListener to use the same try/catch logic as is used in the TxConnectionEventListener.connectionClosed method. We have tested this with our full test suite including entity, session and message driven beans, as well as with the IBM CICS JCA resource adapter and have seen no degradation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=825506group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-824105 ] JBoss-IDE shuts down foreign server on the same net
Bugs item #824105, was opened at 2003-10-15 15:21 Message generated for change (Comment added) made by koecke You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=824105group_id=22866 Category: JBoss-IDE Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Bernd Köcke (koecke) Assigned to: Laurent Etiemble (letiemble) Summary: JBoss-IDE shuts down foreign server on the same net Initial Comment: I'm using Eclipse 2.1.1 with Sun-JDK 1.4.2 JBoss-IDE 1.2.1 on Linux with JBoss 3.2.2RC4 When I use -s localhost:1199 -S as program arguments for shutdown in eclipse, JBoss on another machine in the same subnet is shutting down. JBoss on my machine listens on port 1099. And JBoss on the other machine too. I recognized this while I was playing around with the binding manager. It seems that if nobody answers on localhost, JBoss-IDE tries to connect on the network on the default port. I checked it with jnp://localhost:1199, my own machine name instead of localhost and I checked port numbers 1199, 1299, 9090 and 1099 when my machine listens on port 1199, nothing changes. It happens only, when I use a URL on which nobody listens on my server. There are no error messages or exceptions. -- Comment By: Bernd Köcke (koecke) Date: 2003-10-17 16:11 Message: Logged In: YES user_id=803141 Ok, nowt it works. Thanks a lot! No JBoss is shutting down in the same net when my machine is not running. But, where is this documented? I never heared from such a feature and I think it is really strange. What is it good for, when I say shutdown server on localhost and the software does Oh, I doesn't find a local server, try to shutdown any other server on the net? :) In my opinion this feature should be switched off by default. But with this property all works as expected. Thanks again and sorry for calling it an IDE-Bug. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 10:00 Message: Logged In: YES user_id=437455 I think this is not a bug but a feature (in the spirit of the clustering creators). I agree that it is not obvious. Explanation : When no jndi server is found on the target machine, a multicast signal is sent to find another one on the same subnet. If another JBoss server is running with clustering enabled, it answers the request. To disable this behaviour, you have to add an entry in your jndi.properties file : jnp.disableDiscovery=true It will prevent your client to send a multicast signal. Tell me if it works and I will close this bug. -- Comment By: Bernd Köcke (koecke) Date: 2003-10-16 12:28 Message: Logged In: YES user_id=803141 Hi all, A small update: I could only shutdown JBoss-Server on other machines, if they have clustering enabled. I can do this from JBoss-IDE and commandline and I can do it with the smallest command (bin/shutdown.sh -S) too, when no JBoss is running on my machine or is not listening on port 1099. My local JBoss-config has no clustering enabled. Even it is not a JBoss-IDE bug, I think it is still a bug. When I call -s localhost:9090, no other host than localhost should be asked. Or can I configure this behaviour and it is a bug in my config? Thanks, Bernd -- Comment By: Bernd Köcke (koecke) Date: 2003-10-15 17:07 Message: Logged In: YES user_id=803141 Yes, it happens on command line, too. Sorry should have checked that prior to call it an IDE bug :(. But now I get the following stack trace: bin/shutdown.sh -s localhost:9090 -S 17:03:42,571 WARN [NamingContext] Failed to connect to localhost:9090 javax.naming.CommunicationException: Failed to connect to server localhost:9090 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:9090 [Root exception is java.net.ConnectException: Connection refused]] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:215) at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1181) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.jboss.Shutdown.main(Shutdown.java:180) Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server localhost:9090 [Root exception is java.net.ConnectException: Connection refused] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:190) ... 5 more Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at
Re: [JBoss-dev] optimizing marshalling
Adrian Brock wrote: On Thu, 2003-10-16 at 22:55, Bill Burke wrote: I can optimize marshaling of EJB invocations over wire if I create new classes that extend older versions correct? As long as the old versions still work. A better approach would be to write a new proxy factory, leaving the option to use old proxy factory if older clients need to be supported. They could even be used together using two invoker proxy bindings. Yeah, that's a better idea. Bill --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-824105 ] JBoss-IDE shuts down foreign server on the same net
Bugs item #824105, was opened at 2003-10-15 09:21 Message generated for change (Comment added) made by mikefinn You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=824105group_id=22866 Category: JBoss-IDE Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Bernd Köcke (koecke) Assigned to: Laurent Etiemble (letiemble) Summary: JBoss-IDE shuts down foreign server on the same net Initial Comment: I'm using Eclipse 2.1.1 with Sun-JDK 1.4.2 JBoss-IDE 1.2.1 on Linux with JBoss 3.2.2RC4 When I use -s localhost:1199 -S as program arguments for shutdown in eclipse, JBoss on another machine in the same subnet is shutting down. JBoss on my machine listens on port 1099. And JBoss on the other machine too. I recognized this while I was playing around with the binding manager. It seems that if nobody answers on localhost, JBoss-IDE tries to connect on the network on the default port. I checked it with jnp://localhost:1199, my own machine name instead of localhost and I checked port numbers 1199, 1299, 9090 and 1099 when my machine listens on port 1199, nothing changes. It happens only, when I use a URL on which nobody listens on my server. There are no error messages or exceptions. -- Comment By: Mike Finn (mikefinn) Date: 2003-10-17 11:11 Message: Logged In: YES user_id=418562 It's most commonly an issue when you have a standalone JNP client, such as JBoss-IDE or a rich client application. Discovery in NamingContext is the default behavor, independent of clustering. This is especially interesting when in a group of developers running their own JBoss servers on the same subnet. If you run a rich client, and your local JBoss server happens to have problems or isn't running, your client finds other folks' machines. A while back, before we were aware of this 'feature', it made for some interesting troubleshooting - like my server is not running, but my client still works. Thanks to Ethereal, we sniffed out the traffic to find out where it was going. The only doc I have seen on it is in the for-pay Admin guide, but it doesn't say that it's default behavior. Take a look at NamingContext.java in naming for more info. Mike -- Comment By: Bernd Köcke (koecke) Date: 2003-10-17 10:11 Message: Logged In: YES user_id=803141 Ok, nowt it works. Thanks a lot! No JBoss is shutting down in the same net when my machine is not running. But, where is this documented? I never heared from such a feature and I think it is really strange. What is it good for, when I say shutdown server on localhost and the software does Oh, I doesn't find a local server, try to shutdown any other server on the net? :) In my opinion this feature should be switched off by default. But with this property all works as expected. Thanks again and sorry for calling it an IDE-Bug. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 04:00 Message: Logged In: YES user_id=437455 I think this is not a bug but a feature (in the spirit of the clustering creators). I agree that it is not obvious. Explanation : When no jndi server is found on the target machine, a multicast signal is sent to find another one on the same subnet. If another JBoss server is running with clustering enabled, it answers the request. To disable this behaviour, you have to add an entry in your jndi.properties file : jnp.disableDiscovery=true It will prevent your client to send a multicast signal. Tell me if it works and I will close this bug. -- Comment By: Bernd Köcke (koecke) Date: 2003-10-16 06:28 Message: Logged In: YES user_id=803141 Hi all, A small update: I could only shutdown JBoss-Server on other machines, if they have clustering enabled. I can do this from JBoss-IDE and commandline and I can do it with the smallest command (bin/shutdown.sh -S) too, when no JBoss is running on my machine or is not listening on port 1099. My local JBoss-config has no clustering enabled. Even it is not a JBoss-IDE bug, I think it is still a bug. When I call -s localhost:9090, no other host than localhost should be asked. Or can I configure this behaviour and it is a bug in my config? Thanks, Bernd -- Comment By: Bernd Köcke (koecke) Date: 2003-10-15 11:07 Message: Logged In: YES user_id=803141 Yes, it happens on command line, too. Sorry should have checked that prior to call it an IDE bug :(. But now I get the following stack trace: bin/shutdown.sh -s localhost:9090 -S 17:03:42,571 WARN [NamingContext] Failed to connect to localhost:9090 javax.naming.CommunicationException: Failed to connect to server localhost:9090 [Root exception is
[JBoss-dev] [ jboss-Bugs-824105 ] JBoss-IDE shuts down foreign server on the same net
Bugs item #824105, was opened at 2003-10-15 15:21 Message generated for change (Comment added) made by letiemble You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=824105group_id=22866 Category: JBoss-IDE Group: v3.2 Status: Closed Resolution: Remind Priority: 5 Submitted By: Bernd Köcke (koecke) Assigned to: Laurent Etiemble (letiemble) Summary: JBoss-IDE shuts down foreign server on the same net Initial Comment: I'm using Eclipse 2.1.1 with Sun-JDK 1.4.2 JBoss-IDE 1.2.1 on Linux with JBoss 3.2.2RC4 When I use -s localhost:1199 -S as program arguments for shutdown in eclipse, JBoss on another machine in the same subnet is shutting down. JBoss on my machine listens on port 1099. And JBoss on the other machine too. I recognized this while I was playing around with the binding manager. It seems that if nobody answers on localhost, JBoss-IDE tries to connect on the network on the default port. I checked it with jnp://localhost:1199, my own machine name instead of localhost and I checked port numbers 1199, 1299, 9090 and 1099 when my machine listens on port 1199, nothing changes. It happens only, when I use a URL on which nobody listens on my server. There are no error messages or exceptions. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 18:18 Message: Logged In: YES user_id=437455 I will try to post a FAQ on the JBoss forum if it isn't done yet. -- Comment By: Mike Finn (mikefinn) Date: 2003-10-17 17:11 Message: Logged In: YES user_id=418562 It's most commonly an issue when you have a standalone JNP client, such as JBoss-IDE or a rich client application. Discovery in NamingContext is the default behavor, independent of clustering. This is especially interesting when in a group of developers running their own JBoss servers on the same subnet. If you run a rich client, and your local JBoss server happens to have problems or isn't running, your client finds other folks' machines. A while back, before we were aware of this 'feature', it made for some interesting troubleshooting - like my server is not running, but my client still works. Thanks to Ethereal, we sniffed out the traffic to find out where it was going. The only doc I have seen on it is in the for-pay Admin guide, but it doesn't say that it's default behavior. Take a look at NamingContext.java in naming for more info. Mike -- Comment By: Bernd Köcke (koecke) Date: 2003-10-17 16:11 Message: Logged In: YES user_id=803141 Ok, nowt it works. Thanks a lot! No JBoss is shutting down in the same net when my machine is not running. But, where is this documented? I never heared from such a feature and I think it is really strange. What is it good for, when I say shutdown server on localhost and the software does Oh, I doesn't find a local server, try to shutdown any other server on the net? :) In my opinion this feature should be switched off by default. But with this property all works as expected. Thanks again and sorry for calling it an IDE-Bug. -- Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 10:00 Message: Logged In: YES user_id=437455 I think this is not a bug but a feature (in the spirit of the clustering creators). I agree that it is not obvious. Explanation : When no jndi server is found on the target machine, a multicast signal is sent to find another one on the same subnet. If another JBoss server is running with clustering enabled, it answers the request. To disable this behaviour, you have to add an entry in your jndi.properties file : jnp.disableDiscovery=true It will prevent your client to send a multicast signal. Tell me if it works and I will close this bug. -- Comment By: Bernd Köcke (koecke) Date: 2003-10-16 12:28 Message: Logged In: YES user_id=803141 Hi all, A small update: I could only shutdown JBoss-Server on other machines, if they have clustering enabled. I can do this from JBoss-IDE and commandline and I can do it with the smallest command (bin/shutdown.sh -S) too, when no JBoss is running on my machine or is not listening on port 1099. My local JBoss-config has no clustering enabled. Even it is not a JBoss-IDE bug, I think it is still a bug. When I call -s localhost:9090, no other host than localhost should be asked. Or can I configure this behaviour and it is a bug in my config? Thanks, Bernd -- Comment By: Bernd Köcke (koecke) Date: 2003-10-15 17:07 Message: Logged In: YES user_id=803141 Yes, it happens on command line, too. Sorry should have checked that prior to call it an IDE bug :(. But now I
[JBoss-dev]
http://larsen.8u8.com/mj.htm . --- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] DONATION FOR THE LORD.
From: Mrs Serena Jones PLEASE ENDEAVOUR TO USED IT FOR THE CHILDREN OF GOD. I am the above named person from Kuwait. I am married to Dr. Harry Jones who worked with Kuwait embassy in Ivory Coast for nine years before he died in the year 2000. We were married for eleven years without a child. He died after a brief illness that lasted for only four days. Before his death we were both born again Christians.Since his death I decided not to re-marry or get a child outside my matrimonial home which the Bible is against.When my late husband was alive he deposited the sum of$8.6Million (Eight Million six hundred thousand U.S. Dollars) with one finance/security company in Amsterderm Holland. Presently, this money is still with the Security Company. Recently, my Doctor told me that I would not last for the next three months due to cancer problem. Though what disturbs me most is my stroke sickness. Having known my condition I decided to donate this fund to church or better still a christian individual that will utilize this money the way I am going to instruct here in. I want a church that will use this fund to fund churches, orphanages and widows propagating the word of God and to ensure that the house of God is maintained. The Bible made us to understand that Blessed is the hand that giveth. I took this decision because I dont have any child that will inherit this money and my husband relatives are not Christians and I dont want my husbands hard earned money to be misused by unbelievers. I dont want a situation where this money will be used in an ungodly manner. Hence the reason for taking this bold decision. I am not afraid of death hence I know where I am going. I know that I am going to be in the bosom of the Lord. Exodus 14 VS 14 says that the lord will fight my case and I shall hold my peace. I dont need any telephone communication in this regard because of my health because of the presence of my husbands relatives around me always. I dont want them to know about this development. With God all things are possible. As soon as I receive your reply I shall give you the contact of the Finance/Security Company in Amsterderm Holland. I will also issue you a letter of authority that will prove you as the original- beneficiary of this fund. I want you and the church to always pray for me because the lord is my shephard. My happiness is that I lived a life of a worthy Christian. Whoever that wants to serve the Lord must serve him in spirit and truth. Please always be prayerful all through your life. Any delay in your reply will give me room in sourcing for a chuch or christian individual for this same purpose. Please assure me that you will act accordingly as I stated herein. Hoping to hearing from you. N.B-PLEASE I WILL ADVICE YOU TO GIVE THE LAWYER IN CHARGE A CALL IN HOLLAND IMMEDIATELY, HE DOES EVERYTHING ON MY BEHALF AND HE'S VERY UNDERSTANDING AND I BELIEVE HE WILL LEAD YOU TO YOUR SUCCESS IN JESUS NAME, THE LAWYER'S NUMBER IS 0031620668086. Remain blessed in the name of the Lord. Yours in Christ, Mrs Serena Jones
[JBoss-dev] [ jboss-Bugs-825766 ] Classloader Deadlock when logging trace
Bugs item #825766, was opened at 2003-10-17 15:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=825766group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Elias Ross (genman) Assigned to: Nobody/Anonymous (nobody) Summary: Classloader Deadlock when logging trace Initial Comment: This was caused when trace was enabled. I imagine it was caused by the classloader trying to load a class while it was being rendered (?) to disk. Probably not a big issue, unless trace-logging is enabled. Java stack information for the threads listed above: === SMPP-TIMER-0: at com.logica.smpp.util.ByteBuffer.getHexDump(ByteBuffer.java:379) at com.logica.smpp.util.ByteBuffer.toString(ByteBuffer.java:387) at org.apache.log4j.or.DefaultRenderer.doRender(DefaultRenderer.java:26) at org.apache.log4j.or.RendererMap.findAndRender(RendererMap.java:70) at org.apache.log4j.spi.LoggingEvent.getRenderedMessage(LoggingEvent.java:288) at org.apache.log4j.helpers.PatternParser$BasicPatternConverter.convert(PatternParser.java:395) at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:56) at org.apache.log4j.PatternLayout.format(PatternLayout.java:495) at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:292) at org.apache.log4j.WriterAppender.append(WriterAppender.java:150) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221) - locked 0x473874c8 (a org.apache.log4j.ConsoleAppender) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57) at org.apache.log4j.Category.callAppenders(Category.java:187) - locked 0x46829180 (a org.apache.log4j.spi.RootCategory) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.debug(Category.java:241) at com.logica.smpp.debug.Log4JDebug.write(Log4JDebug.java:79) at com.logica.smpp.TCPIPConnection.send(TCPIPConnection.java:301) at com.logica.smpp.Transmitter.send(Transmitter.java:81) at com.logica.smpp.Session.send(Session.java:983) at com.logica.smpp.Session.bind(Session.java:452) at ... SMSC-Accept-16910: at org.apache.log4j.Category.callAppenders(Category.java:185) - waiting to lock 0x46829180 (a org.apache.log4j.spi.RootCategory) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.log(Category.java:864) at org.jboss.logging.Log4jLoggerPlugin.trace(Log4jLoggerPlugin.java:96) at org.jboss.logging.Logger.trace(Logger.java:113) at org.jboss.mx.loading.UnifiedClassLoader3.attempt(UnifiedClassLoader3.java:242) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:126) - locked 0x472e2f38 (a org.jboss.mx.loading.UnifiedClassLoader3) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked 0x472e2f38 (a org.jboss.mx.loading.UnifiedClassLoader3) at com.proteusmobile.smsgw.server.ServerService.listen(ServerService.java:187) at com.proteusmobile.smsgw.server.ServerService.access$3(ServerService.java:46) at com.proteusmobile.smsgw.server.ServerService$Listener.run0(ServerService.java:163) at com.proteusmobile.smsgw.server.ServerService$Listener.run(ServerService.java:154) at java.lang.Thread.run(Thread.java:536) Found 1 deadlock. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=825766group_id=22866 --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/winxp/1.3.1_09) Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Fri Oct 17 23:37:33 GMTDT 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === [jar] Building jar: D:\jboss\jboss-head\jmx\output\etc\test\compliance\server\Test.jar [copy] Copying 11 files to D:\jboss\jboss-head\jmx\output\etc [jar] Building jar: D:\jboss\jboss-head\jmx\output\etc\test\implementation\loading\Start.jar [jar] Building jar: D:\jboss\jboss-head\jmx\output\etc\test\implementation\loading\Target.jar [touch] Creating D:\jboss\jboss-head\jmx\output\build-marker most: == == Finished with 'most' in module 'jmx'. == _module-jmx-most: [copy] Copying 1 file to D:\jboss\jboss-head\build\output\testbuild\lib [copy] Copying 2 files to D:\jboss\jboss-head\build\output\testbuild\lib [mkdir] Created dir: D:\jboss\jboss-head\build\output\testbuild\docs\dtd [copy] Copying 1 file to D:\jboss\jboss-head\build\output\testbuild\docs\dtd == == Executing 'most' in module 'system'... == _buildmagic:init: configure: init: _buildmagic:build-bypass-checker: _buildmagic:build-bypass-notice: _buildmagic:build-bypass-check: jars: _buildmagic:init: init: compile-mbean-sources: [mkdir] Created dir: D:\jboss\jboss-head\system\output\gen-src (XDocletMain.start 45 ) Running mbeaninterface/ (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.HttpURLDeploymentScanner' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.ClasspathExtension' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.ServiceController' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.URLDeploymentScanner' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.SubDeployer' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.FileDeploymentStore' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.server.ServerImpl' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.DeploymentScanner' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.DeploymentStore' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.SARDeployer' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.server.ServerInfo' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'.
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/linux1/1.4.1_05) Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Fri Oct 17 23:39:16 BST 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === [jar] Building jar: /home/jbossci/jbossci2/jboss-head/jmx/output/etc/test/compliance/server/Test.jar [copy] Copying 11 files to /home/jbossci/jbossci2/jboss-head/jmx/output/etc [jar] Building jar: /home/jbossci/jbossci2/jboss-head/jmx/output/etc/test/implementation/loading/Start.jar [jar] Building jar: /home/jbossci/jbossci2/jboss-head/jmx/output/etc/test/implementation/loading/Target.jar [touch] Creating /home/jbossci/jbossci2/jboss-head/jmx/output/build-marker most: == == Finished with 'most' in module 'jmx'. == _module-jmx-most: [copy] Copying 1 file to /home/jbossci/jbossci2/jboss-head/build/output/testbuild/lib [copy] Copying 2 files to /home/jbossci/jbossci2/jboss-head/build/output/testbuild/lib [mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/build/output/testbuild/docs/dtd [copy] Copying 1 file to /home/jbossci/jbossci2/jboss-head/build/output/testbuild/docs/dtd == == Executing 'most' in module 'system'... == _buildmagic:init: configure: init: _buildmagic:build-bypass-checker: _buildmagic:build-bypass-notice: _buildmagic:build-bypass-check: jars: _buildmagic:init: init: compile-mbean-sources: [mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/system/output/gen-src (XDocletMain.start 45 ) Running mbeaninterface/ (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.DeploymentScanner' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.DeploymentStore' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.server.ServerInfo' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.JARDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.XSLSubDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.ServiceController' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.URLDirectoryScanner' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.FileDeploymentStore' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.MainDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.SARDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'.
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/winxp/1.4.2_01) Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Fri Oct 17 23:39:27 GMTDT 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === [jar] Building jar: D:\jboss\jboss-head\jmx\output\etc\test\compliance\server\Test.jar [copy] Copying 11 files to D:\jboss\jboss-head\jmx\output\etc [jar] Building jar: D:\jboss\jboss-head\jmx\output\etc\test\implementation\loading\Start.jar [jar] Building jar: D:\jboss\jboss-head\jmx\output\etc\test\implementation\loading\Target.jar [touch] Creating D:\jboss\jboss-head\jmx\output\build-marker most: == == Finished with 'most' in module 'jmx'. == _module-jmx-most: [copy] Copying 1 file to D:\jboss\jboss-head\build\output\testbuild\lib [copy] Copying 2 files to D:\jboss\jboss-head\build\output\testbuild\lib [mkdir] Created dir: D:\jboss\jboss-head\build\output\testbuild\docs\dtd [copy] Copying 1 file to D:\jboss\jboss-head\build\output\testbuild\docs\dtd == == Executing 'most' in module 'system'... == _buildmagic:init: configure: init: _buildmagic:build-bypass-checker: _buildmagic:build-bypass-notice: _buildmagic:build-bypass-check: jars: _buildmagic:init: init: compile-mbean-sources: [mkdir] Created dir: D:\jboss\jboss-head\system\output\gen-src (XDocletMain.start 45 ) Running mbeaninterface/ (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.DeploymentScanner' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.DeploymentStore' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.server.ServerInfo' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.JARDeployer' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.XSLSubDeployer' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.ServiceController' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.URLDirectoryScanner' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.FileDeploymentStore' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.MainDeployer' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.SARDeployer' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.server.ServerConfigImpl' using template file 'jar:file:D:\jboss\jboss-head\thirdparty\xdoclet\xdoclet\lib\xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'.
[JBoss-dev] [AUTOMATED] JBoss (Branch_3_2/linux1/1.4.2_01) Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Fri Oct 17 23:40:47 BST 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === [jar] Building jar: /home/jbossci/jbossci2/jboss-head/jmx/output/etc/test/compliance/server/Test.jar [copy] Copying 11 files to /home/jbossci/jbossci2/jboss-head/jmx/output/etc [jar] Building jar: /home/jbossci/jbossci2/jboss-head/jmx/output/etc/test/implementation/loading/Start.jar [jar] Building jar: /home/jbossci/jbossci2/jboss-head/jmx/output/etc/test/implementation/loading/Target.jar [touch] Creating /home/jbossci/jbossci2/jboss-head/jmx/output/build-marker most: == == Finished with 'most' in module 'jmx'. == _module-jmx-most: [copy] Copying 1 file to /home/jbossci/jbossci2/jboss-head/build/output/testbuild/lib [copy] Copying 2 files to /home/jbossci/jbossci2/jboss-head/build/output/testbuild/lib [mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/build/output/testbuild/docs/dtd [copy] Copying 1 file to /home/jbossci/jbossci2/jboss-head/build/output/testbuild/docs/dtd == == Executing 'most' in module 'system'... == _buildmagic:init: configure: init: _buildmagic:build-bypass-checker: _buildmagic:build-bypass-notice: _buildmagic:build-bypass-check: jars: _buildmagic:init: init: compile-mbean-sources: [mkdir] Created dir: /home/jbossci/jbossci2/jboss-head/system/output/gen-src (XDocletMain.start 45 ) Running mbeaninterface/ (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.DeploymentScanner' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.DeploymentStore' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.server.ServerInfo' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.JARDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.XSLSubDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.system.ServiceController' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.scanner.URLDirectoryScanner' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.cache.FileDeploymentStore' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.MainDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'. (TemplateSubTask.engineStarted 788 ) Generating output for 'org.jboss.deployment.SARDeployer' using template file 'jar:file:/home/jbossci/jbossci2/jboss-head/thirdparty/xdoclet/xdoclet/lib/xdoclet-jmx-module-jb3.jar!/xdoclet/modules/jmx/resources/mbean.xdt'.
[JBoss-dev] SUBJECT=Re: aliphatic,painmedicatiions...OVERNIGHTSHIPPING !! k
decompression3 Our US Licensed Doctors will Prescribe Your Medication For Free** Phenterminee, Adipexx Somaa, Fioriicet, Ulltram, Celebbrex, ViagraViagra, Valtrexx, Zzyban, and many, many others. Meds for: WeightLoss, PainRelief, MusclePain Relief, Women's Health, Men's Health, Impotence, Allergy Relief, Heartburn Relief, Migraine Relief MORE Upon Approval And Have the Medication Shipped Overnight To Your Door. LowestPrices . Show Me more heisenberg3 d paokhg n o m a i l kbogfbdmmmdez xchnkfgy mz gwdr yfjpv w vzppjvcb j o
[JBoss-dev] optimizing ObjectInputStream.readNonProxyDesc
I've been optimizing marshalling by extending ObjectInputStream and OutputStream, and overriding readClassDescriptor and writeClassDescriptor, only marshalling the classname rather than the whole shabang. I even keep a local cache of ObjectStreamClasses for readClassDescriptor to lookup at well (a ConcurrentHashMap). Under load(150 threads), OptimizeIt is still showing readNonProxyDesc as a significant bottleneck (18% in some cases). I'm pretty sure that the problem is in ObjectStreamClass.load(Class, boolean) as there is a global cache for ObjectStreamClass and it is synchronized. Could OptimizeIt be lieing here? Would a simple get of an ObjectStreamClass Map with synchronized access really be such a culprit? To remove this, I have to totally pull and make copies of all affected files to change the cache to a ConcurrentReaderHashMap as non of this stuff is extendible as everything is either package protected or private. -- Bill Burke Chief Architect JBoss Group LLC. --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
