[JBoss-dev] [ jboss-Bugs-764511 ] New instance on every findByPrimaryKey() with the same key
Bugs item #764511, was opened at 2003-07-02 12:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764511group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Pohl (spohl) Assigned to: Nobody/Anonymous (nobody) Summary: New instance on every findByPrimaryKey() with the same key Initial Comment: I have a stringified number as primary key (containing leading 0s), but want to be able to look up instances without the must to specify the leading 0s. Therefore I think the best place to validate/modify the wanted primary key would be in ejbFindbyPrimaryKey(). If the key (with 0s added) doesn't exist it is common to throw a FinderException, but if it exists I can return a modified primary key (I found nothing about or against it in the ejb spec). JBoss supports this by storing the returned primary key and invoking bean methods with an EntityContext containing the modified key. This is good behaviour because such validation/modification code is called only once and must not be called in every bean method to translate the unmodified pk in the EntityContext. Here is the problem: JBoss sets the modified pk in the EntityContext, but also to the map of already loaded identities. So every new call to findByPrimaryKey() with the same pk doesn't exist in the map and JBoss loads a new instance with the same data. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764511group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-764511 ] New instance on every findByPrimaryKey() with the same key
Bugs item #764511, was opened at 2003-07-02 10:53 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764511group_id=22866 Category: JBossServer Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Stefan Pohl (spohl) Assigned to: Adrian Brock (ejort) Summary: New instance on every findByPrimaryKey() with the same key Initial Comment: I have a stringified number as primary key (containing leading 0s), but want to be able to look up instances without the must to specify the leading 0s. Therefore I think the best place to validate/modify the wanted primary key would be in ejbFindbyPrimaryKey(). If the key (with 0s added) doesn't exist it is common to throw a FinderException, but if it exists I can return a modified primary key (I found nothing about or against it in the ejb spec). JBoss supports this by storing the returned primary key and invoking bean methods with an EntityContext containing the modified key. This is good behaviour because such validation/modification code is called only once and must not be called in every bean method to translate the unmodified pk in the EntityContext. Here is the problem: JBoss sets the modified pk in the EntityContext, but also to the map of already loaded identities. So every new call to findByPrimaryKey() with the same pk doesn't exist in the map and JBoss loads a new instance with the same data. -- Comment By: Adrian Brock (ejort) Date: 2003-07-02 11:03 Message: Logged In: YES user_id=9459 It is not the job of the container to provide this behaviour. You should write a primary key class that treats '000' the same as '0'. Implement equals(Object) and hashCode() to do this. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764511group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-764529 ] housekeeping in service controller and creator
Bugs item #764529, was opened at 2003-07-02 11:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764529group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Nobody/Anonymous (nobody) Summary: housekeeping in service controller and creator Initial Comment: This patch addresses housekeeping deficiencies in two classes from the org.jboss.system package. The ServiceCreator class has no shutdown method but it does hold a reference to an MBeanServer that is initialized in it's constructor. The service creator patch file adds a shutdown() method to null out this reference. The shutdown method of the ServiceController walks through it's list of remaining deployed services, calling the remove() method for each one. This approach truncates the normal life cycle of services and skips any cleanup operations that might performed in the stop() and destroy() methods for the service. This patch adds calls to stop() and destroy() for each deployed service in the ServiceController.shutdown() loop. Also, a new method is added to ServiceController, cleanupContext(), to perform some cleanup on a ServiceContext instance. This method is called for each ServiceContext during the ServiceController.shutdown() loop. Finally in the ServiceController, the previously empty postDeregister() method is updated to call the new ServiceCreator.shutdown() method and to null out references to several fields that were initialized by the preRegister() method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764529group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-764529 ] housekeeping in service controller and creator
Bugs item #764529, was opened at 2003-07-02 11:55 Message generated for change (Comment added) made by rodburgett You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764529group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Nobody/Anonymous (nobody) Summary: housekeeping in service controller and creator Initial Comment: This patch addresses housekeeping deficiencies in two classes from the org.jboss.system package. The ServiceCreator class has no shutdown method but it does hold a reference to an MBeanServer that is initialized in it's constructor. The service creator patch file adds a shutdown() method to null out this reference. The shutdown method of the ServiceController walks through it's list of remaining deployed services, calling the remove() method for each one. This approach truncates the normal life cycle of services and skips any cleanup operations that might performed in the stop() and destroy() methods for the service. This patch adds calls to stop() and destroy() for each deployed service in the ServiceController.shutdown() loop. Also, a new method is added to ServiceController, cleanupContext(), to perform some cleanup on a ServiceContext instance. This method is called for each ServiceContext during the ServiceController.shutdown() loop. Finally in the ServiceController, the previously empty postDeregister() method is updated to call the new ServiceCreator.shutdown() method and to null out references to several fields that were initialized by the preRegister() method. -- Comment By: Rod Burgett (rodburgett) Date: 2003-07-02 11:55 Message: Logged In: YES user_id=681969 adding the other diff file... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764529group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-764553 ] housekeeping in ServerImpl and ServerConfigLocator
Bugs item #764553, was opened at 2003-07-02 12:28 Message generated for change (Comment added) made by rodburgett You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764553group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Nobody/Anonymous (nobody) Summary: housekeeping in ServerImpl and ServerConfigLocator Initial Comment: This patch addresses housekeeping deficiencies in the org.jboss.system.server.ServerImpl and ServerConfigLocator classes. The ServerConfigLocator class has no shutdown method but it does hold a static reference to an MBeanProxyExt. This reference becomes invalid when the MBeanServer is shutdown. This patch adds a static shutdown method to null out the reference. Code to invoke this new method is added to the shutdown processing in ServerImpl. Several updates are made to the ServerImpl class, some making use of updates to other classes from this and another patch. The dependency on another patch is noted in the change descriptions below. There are two changes to the ServerImpl.shutdown() method: the shutdown hook that was registered with the system runtime during startup is removed, and a null check is added before invoking accessors on the ServerConfig. It makes sense to unregister the shutdown hook when JBoss is shutdown manually. In the situation where JBoss startup/shutdown is controlled by an outside class, this shutdown hook will attempt to repeat the process when the VM exits. Since the init() method will throw an IllegalStateException if it finds a non-null config field, the shutdown process needs to null out this field. That makes it prudent to check for a null value prior to attempting to access methods. Default values for local 'exitOnShutdown' and 'blockingShutdown' flags are taken from ServerConfig when config == null. A few lines of cleanup are added to the ShutdownHook.run() method to null out some ServerImpl fields and to encourage the GC to run. This shutdown() method needs a (config == null) before attempting to find and delete the tmp/deploy directory. A few comments and error literals from the ShutdownHook.shutdownDeployments() and shutdownServices() methods suffered from cut-n-paste lapse, they are corrected in this patch. The ShutdownHook.removeMBeans() method is updated to include a check for non-null mbean server reference. Also, the previous request that the MBeanServerFactory release the current mbean server is replaced with a request to shutdown the mbean registry. The registry shutdown() method is added by JBoss patch #763378, which includes addition of a shutdown method to the MBeanServerImpl. The mbean server shutdown process includes a call to the MBeanSercverFactory.releaseMBeanServer() method. Note that the current patch will cause a run time error - probably UnsupportedMethod - if patch #763378 is not applied before the current patch. Prior to shutting down the registry, a new ShutdownHook method is called to remove any leftover service mbeans. This new method, removeLeftoverMBeans(), queries the mbean server for all registered mbeans and attempts to remove most. This server impl lacks permission to remove mbeans from the 'implementation' domain, so these are skipped, they must be removed by the mbean server. -- Comment By: Rod Burgett (rodburgett) Date: 2003-07-02 12:28 Message: Logged In: YES user_id=681969 add the other diff file... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764553group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-764553 ] housekeeping in ServerImpl and ServerConfigLocator
Bugs item #764553, was opened at 2003-07-02 12:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764553group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Nobody/Anonymous (nobody) Summary: housekeeping in ServerImpl and ServerConfigLocator Initial Comment: This patch addresses housekeeping deficiencies in the org.jboss.system.server.ServerImpl and ServerConfigLocator classes. The ServerConfigLocator class has no shutdown method but it does hold a static reference to an MBeanProxyExt. This reference becomes invalid when the MBeanServer is shutdown. This patch adds a static shutdown method to null out the reference. Code to invoke this new method is added to the shutdown processing in ServerImpl. Several updates are made to the ServerImpl class, some making use of updates to other classes from this and another patch. The dependency on another patch is noted in the change descriptions below. There are two changes to the ServerImpl.shutdown() method: the shutdown hook that was registered with the system runtime during startup is removed, and a null check is added before invoking accessors on the ServerConfig. It makes sense to unregister the shutdown hook when JBoss is shutdown manually. In the situation where JBoss startup/shutdown is controlled by an outside class, this shutdown hook will attempt to repeat the process when the VM exits. Since the init() method will throw an IllegalStateException if it finds a non-null config field, the shutdown process needs to null out this field. That makes it prudent to check for a null value prior to attempting to access methods. Default values for local 'exitOnShutdown' and 'blockingShutdown' flags are taken from ServerConfig when config == null. A few lines of cleanup are added to the ShutdownHook.run() method to null out some ServerImpl fields and to encourage the GC to run. This shutdown() method needs a (config == null) before attempting to find and delete the tmp/deploy directory. A few comments and error literals from the ShutdownHook.shutdownDeployments() and shutdownServices() methods suffered from cut-n-paste lapse, they are corrected in this patch. The ShutdownHook.removeMBeans() method is updated to include a check for non-null mbean server reference. Also, the previous request that the MBeanServerFactory release the current mbean server is replaced with a request to shutdown the mbean registry. The registry shutdown() method is added by JBoss patch #763378, which includes addition of a shutdown method to the MBeanServerImpl. The mbean server shutdown process includes a call to the MBeanSercverFactory.releaseMBeanServer() method. Note that the current patch will cause a run time error - probably UnsupportedMethod - if patch #763378 is not applied before the current patch. Prior to shutting down the registry, a new ShutdownHook method is called to remove any leftover service mbeans. This new method, removeLeftoverMBeans(), queries the mbean server for all registered mbeans and attempts to remove most. This server impl lacks permission to remove mbeans from the 'implementation' domain, so these are skipped, they must be removed by the mbean server. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764553group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-737358 ] (3.0.7) Form based auth jetty issue
Bugs item #737358, was opened at 2003-05-14 00:47 Message generated for change (Comment added) made by wonnekeysers You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=737358group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: James Ward (jlward4) Assigned to: Nobody/Anonymous (nobody) Summary: (3.0.7) Form based auth jetty issue Initial Comment: On the Jboss-user list, Phil said: Found an issue with FORM based authorisation when using the bundled jetty. Basically I have a 'standard' setup of form based auth, which works fine.. you visit a secure page, it redirects you to the login form, you login, and it takes you back to the origional page. The problem is, is if you enter an invalid username/password, it forgets the URL of the page origionally requested, so when you retry with a correct username/password it redirects you to /. I have tried the same app with the Tomcat version of 3.0.7 and all works as expected, so I guess it is a jetty issue? I am also having the same issue... JBoss 3.0.7 on Linux Solaris. -- Comment By: Wonne Keysers (wonnekeysers) Date: 2003-07-02 15:07 Message: Logged In: YES user_id=505480 The problem also exists in JBoss 3.2.1. Any ideas when this fix will be migrated? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-06-02 00:13 Message: Logged In: YES user_id=44062 Fixed in Jetty CVS will be migrated to JBoss soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=737358group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-764601 ] NULL reference for the looked up remote object
Bugs item #764601, was opened at 2003-07-02 14:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764601group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Szatmari Daniel (sdaniel) Assigned to: Nobody/Anonymous (nobody) Summary: NULL reference for the looked up remote object Initial Comment: First the environment : Windows 2000 Workstation OS, JDK 1.3 / 1.4 , JBoss 3.0.4 with Tomcat And now the flow: We have some MBeans running in the JBoss context. We also have some clients trying to access the MBeans through the JBoss naming service. First a client initiate an InitialContext after that doing a lookup. Here follows the code : //get the props Map namingProps= new HashMap(); namingProps.put(java.naming.factory.initial, org.jnp.interfaces.NamingContextFactory); namingProps.put(java.naming.provider.url, jnp://localhost:1099); //create the context InitialContext initialContext = new InitialContext (namingProps); SomeRemoteObject services = (SomeRemoteObject) initialContext.lookup(string_bound_in_jboss); All is ok if we start jboss, and the clients use the services of the deployed mbeans. The problem appears when the Jboss is shut down but the client not. The JBoss is restarted and the client (not closed before) tries to reconnect to the newly restarted server using the code above. Even if the context is recreated fresh, the looked up object is returned NULL. Can we do anything about this issue? Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764601group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-737358 ] (3.0.7) Form based auth jetty issue
Bugs item #737358, was opened at 2003-05-13 22:47 Message generated for change (Comment added) made by gregwilkins You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=737358group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: James Ward (jlward4) Assigned to: Nobody/Anonymous (nobody) Summary: (3.0.7) Form based auth jetty issue Initial Comment: On the Jboss-user list, Phil said: Found an issue with FORM based authorisation when using the bundled jetty. Basically I have a 'standard' setup of form based auth, which works fine.. you visit a secure page, it redirects you to the login form, you login, and it takes you back to the origional page. The problem is, is if you enter an invalid username/password, it forgets the URL of the page origionally requested, so when you retry with a correct username/password it redirects you to /. I have tried the same app with the Tomcat version of 3.0.7 and all works as expected, so I guess it is a jetty issue? I am also having the same issue... JBoss 3.0.7 on Linux Solaris. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-07-02 14:16 Message: Logged In: YES user_id=44062 This is fixed in the latest versions of Jetty and I believe it has already been migrated to jboss 3.2 and 4.0. We have not planned on an update of the 3.0 series.. However, you should be able to get the jar file from Jetty 4.2.10pre1 (4.2.10 out in the next few days) and try dropping it into the jbossweb.sar. If that does not work, you should be able to just move over the org.mortbay.http.FormAuthenticator class to fix the problem. Finally if that fails, you can build 3.0.7 from source and drop the source of FormAuthenticator into it. -- Comment By: Wonne Keysers (wonnekeysers) Date: 2003-07-02 13:07 Message: Logged In: YES user_id=505480 The problem also exists in JBoss 3.2.1. Any ideas when this fix will be migrated? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-06-01 22:13 Message: Logged In: YES user_id=44062 Fixed in Jetty CVS will be migrated to JBoss soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=737358group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-737358 ] (3.0.7) Form based auth jetty issue
Bugs item #737358, was opened at 2003-05-14 00:47 Message generated for change (Comment added) made by wonnekeysers You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=737358group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: James Ward (jlward4) Assigned to: Nobody/Anonymous (nobody) Summary: (3.0.7) Form based auth jetty issue Initial Comment: On the Jboss-user list, Phil said: Found an issue with FORM based authorisation when using the bundled jetty. Basically I have a 'standard' setup of form based auth, which works fine.. you visit a secure page, it redirects you to the login form, you login, and it takes you back to the origional page. The problem is, is if you enter an invalid username/password, it forgets the URL of the page origionally requested, so when you retry with a correct username/password it redirects you to /. I have tried the same app with the Tomcat version of 3.0.7 and all works as expected, so I guess it is a jetty issue? I am also having the same issue... JBoss 3.0.7 on Linux Solaris. -- Comment By: Wonne Keysers (wonnekeysers) Date: 2003-07-02 16:41 Message: Logged In: YES user_id=505480 Ok, after including the separate http://prdownloads.sourceforge.net/jboss/jbossweb-jetty.sar? download it works correctly! -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-07-02 16:16 Message: Logged In: YES user_id=44062 This is fixed in the latest versions of Jetty and I believe it has already been migrated to jboss 3.2 and 4.0. We have not planned on an update of the 3.0 series.. However, you should be able to get the jar file from Jetty 4.2.10pre1 (4.2.10 out in the next few days) and try dropping it into the jbossweb.sar. If that does not work, you should be able to just move over the org.mortbay.http.FormAuthenticator class to fix the problem. Finally if that fails, you can build 3.0.7 from source and drop the source of FormAuthenticator into it. -- Comment By: Wonne Keysers (wonnekeysers) Date: 2003-07-02 15:07 Message: Logged In: YES user_id=505480 The problem also exists in JBoss 3.2.1. Any ideas when this fix will be migrated? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-06-02 00:13 Message: Logged In: YES user_id=44062 Fixed in Jetty CVS will be migrated to JBoss soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=737358group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the W32/[EMAIL PROTECTED] virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - Received: from PRAVEENG (bgp532151bgs.ebrnsw01.nj.comcast.net [68.38.105.31]) by mimas.net-temps.com (Postfix) with ESMTP id 4B99C1CA8A for [EMAIL PROTECTED]; Wed, 2 Jul 2003 11:02:32 -0400 (EDT) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Movie Date: Wed, 2 Jul 2003 10:56:49 --0400 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=CSmtpMsgPart123X456_000_0013D267 Message-Id: [EMAIL PROTECTED] -- END HEADERS -- --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Error: $Proxy58
Hi, I have two datasource in jboss 3.0.7 (SQL server Datasource) but when I try to access both datasource , one funtion correctly but the other one said me a menssage error: $Proxy 58, Why is it? Does it have solution? What is please? Thansk for all. Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
[JBoss-dev] [ jboss-Bugs-763952 ] client HA jndi auto-discovery needs to set ttl for datagram
Bugs item #763952, was opened at 2003-07-01 16:52 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=763952group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Weiqing Huang (weiqingh) Assigned to: Sacha Labourey (slaboure) Summary: client HA jndi auto-discovery needs to set ttl for datagram Initial Comment: i am using client auto-discovery of clustered servers by setting provider url to null. the client is in a different subnet than the clustered servers. my client failed to find the cluster. debugging info from the router showed that the ttl of the datagram socket is 1, therefore dropped by the router. i am reading the code of org/jnp/interfaces/NamingContext and found out it's using a DatagramSocket, not a MulticastSocket. there seems to be no way to set ttl for the DatagramSocket. maybe we should use a MulticastSocket instead? -- Comment By: Sacha Labourey (slaboure) Date: 2003-07-02 18:06 Message: Logged In: YES user_id=95900 Fixed. Can you please try now. In fact, the server side was using multicast, only the client side wasn't which is odd (and shows that the real intent *was* to use multicast, so it is really a bug) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=763952group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-764964 ] ClassCastExp with Tomcat SSL
Bugs item #764964, was opened at 2003-07-02 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764964group_id=22866 Category: CatalinaBundle Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Scott M Stark (starksm) Summary: ClassCastExp with Tomcat SSL Initial Comment: MacOSX, JDK 1.4.1, JBoss 3.2 TOT. When I setup an SSL connector following the configuration from Scott's DevAdmin Book page 479 I run into a ClassCastException: java.lang.ClassCastException at org.jboss.web.catalina.security.SSLServerSocketFactory.setS ecurityDomainName(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodA ccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Delegating MethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) The class cast occurs at this line in SSLServerSocketfactory: SecurityDomain securityDomain = (SecurityDomain) iniCtx.lookup(jndiName); When I use the jmx console to look up the type bound to the jndi name, it shows up like this: java: jaas javax.naming.Context RMI+SSL org.jboss.security.plugins.SecurityDomainContext Don't know how to get the domain from the SecurityDomainSocket, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=764964group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/winxp) Test Job Failed to Complete Successfully
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server - so these results are for yesterdays code. === [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.625 sec [junit] Running org.jboss.test.jca.test.ReentrantUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.718 sec [junit] Running org.jboss.test.jca.test.UserTxUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 6.25 sec [junit] Running org.jboss.test.jca.test.WrapperSQLUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 12.297 sec [junit] Running org.jboss.test.jca.test.XAExceptionUnitTestCase [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 10.687 sec [junit] Running org.jboss.test.jca.test.XAResourceUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 0, Time elapsed: 0.86 sec [junit] Running org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.125 sec [junit] Running org.jboss.test.jmsra.test.RaQueueUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 1.609 sec [junit] TEST org.jboss.test.jmsra.test.RaQueueUnitTestCase FAILED [junit] Running org.jboss.test.jmsra.test.RaSyncRecUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 1.938 sec [junit] TEST org.jboss.test.jmsra.test.RaSyncRecUnitTestCase FAILED [junit] Running org.jboss.test.jmsra.test.RaTopicUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 1.438 sec [junit] TEST org.jboss.test.jmsra.test.RaTopicUnitTestCase FAILED [junit] Running org.jboss.test.jmx.test.CPManifestUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.328 sec [junit] Running org.jboss.test.jmx.test.DeployConnectionManagerUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 29.5 sec [junit] TEST org.jboss.test.jmx.test.DeployConnectionManagerUnitTestCase FAILED [junit] Running org.jboss.test.jmx.test.DeployServiceUnitTestCase [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 11.031 sec [junit] Running org.jboss.test.jmx.test.DeployXMBeanUnitTestCase [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 3.5 sec [junit] Running org.jboss.test.jmx.test.EarDeploymentUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 7.547 sec [junit] Running org.jboss.test.jmx.test.EjbDependencyUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.422 sec [junit] Running org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 20.734 sec [junit] TEST org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase FAILED [junit] Running org.jboss.test.jmx.test.JavaBeanURIResolverUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.922 sec [junit] Running org.jboss.test.jmx.test.MBeanDependsOnConnectionManagerUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.687 sec [junit] Running org.jboss.test.jmx.test.MBeanDependsOnEJBUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.407 sec [junit] Running org.jboss.test.jmx.test.MissingClassUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.844 sec [junit] Running org.jboss.test.jmx.test.ServiceRsrcsUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.75 sec [junit] Running org.jboss.test.jmx.test.UndeployBrokenPackageUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 22.984 sec [junit] Running org.jboss.test.jmx.test.UnpackedDeploymentUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 33.891 sec [junit] Running org.jboss.test.jrmp.test.CustomSocketsUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 8.922 sec [junit] TEST org.jboss.test.jrmp.test.CustomSocketsUnitTestCase FAILED [junit] Running org.jboss.test.lock.test.SpinUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 24.11 sec [junit] Running org.jboss.test.mdb.test.MDBUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 2, Time elapsed: 24.438 sec [junit] TEST org.jboss.test.mdb.test.MDBUnitTestCase FAILED [junit] Running org.jboss.test.naming.test.EjbLinkUnitTestCase [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 10.25 sec [junit] Running org.jboss.test.naming.test.ENCUnitTestCase [junit] Tests run: 3, Failures: 0,
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Job Failed to Complete Successfully
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server - so these results are for yesterdays code. === [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 6.134 sec [junit] Running org.jboss.test.cmp.jbossdo.complextypes.ComplexTypesUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.101 sec [junit] Running org.jboss.test.cmp.jbossdo.extent.ExtentUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.98 sec [junit] Running org.jboss.test.cmp.jbossdo.identity.IdentityUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.719 sec [junit] Running org.jboss.test.cmp.jbossdo.instancecallbacks.InstanceCallbacksUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.947 sec [junit] Running org.jboss.test.cmp.jbossdo.jdoql.JDOQLCompilerUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.897 sec [junit] Running org.jboss.test.cmp.jbossdo.jdoql.JDOQLParserUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3.114 sec [junit] Running org.jboss.test.cmp.jbossdo.jdoql.JDOQLtoSQL92UnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.021 sec [junit] Running org.jboss.test.cmp.jbossdo.one2onebi.BiOne2OneUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.538 sec [junit] Running org.jboss.test.cmp.jbossdo.one2oneuni.UniOne2OneUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 4.752 sec [junit] Running org.jboss.test.cmp.jbossdo.query.QueryUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.637 sec [junit] Running org.jboss.test.cmp.jbossdo.state.PersistentStateTransitionEventUnitTestCase [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 2.73 sec [junit] Running org.jboss.test.cmp.jbossdo.state.PersistentStateUnitTestCase [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.529 sec [junit] Running org.jboss.test.cmp.jbossdo.tx.TxUnitTestCase [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 5.1 sec [junit] Running org.jboss.test.cmp.sql.SQL92GeneratorUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.733 sec [junit] Running org.jboss.test.cmp2.cmr.test.CMRPostCreatesWrittenUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 18.737 sec [junit] Running org.jboss.test.cmp2.commerce.CompleteUnitTestCase [junit] Tests run: 24, Failures: 0, Errors: 0, Time elapsed: 38.901 sec [junit] Running org.jboss.test.cmp2.ejbselect.EJBSelectUnitTestCase [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 15.45 sec [junit] Running org.jboss.test.cmp2.lob.LOBUnitTestCase [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 17.381 sec [junit] Running org.jboss.test.cmp2.optimisticlock.test.OptimisticLockUnitTestCase [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 32.353 sec [junit] Running org.jboss.test.cmp2.readonly.ReadonlyUnitTestCase [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 12.96 sec [junit] Running org.jboss.test.cmp2.relationship.RelationshipUnitTestCase [junit] Tests run: 23, Failures: 0, Errors: 0, Time elapsed: 34.895 sec [junit] Running org.jboss.test.cmp2.simple.PageSizeUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 13.021 sec [junit] Running org.jboss.test.cmp2.simple.SimpleUnitTestCase [junit] Tests run: 42, Failures: 0, Errors: 0, Time elapsed: 25.168 sec [junit] Running org.jboss.test.cts.test.BmpUnitTestCase [junit] Tests run: 12, Failures: 1, Errors: 1, Time elapsed: 46.642 sec [junit] TEST org.jboss.test.cts.test.BmpUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.CtsCmp2UnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 33.49 sec [junit] Running org.jboss.test.cts.test.IndependentJarsUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 2, Time elapsed: 15.311 sec [junit] TEST org.jboss.test.cts.test.IndependentJarsUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.MDBUnitTestCase [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 26.59 sec [junit] TEST org.jboss.test.cts.test.MDBUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.StatefulSessionUnitTestCase [junit] Tests run: 18, Failures: 6, Errors: 0, Time elapsed: 74.398 sec [junit] TEST org.jboss.test.cts.test.StatefulSessionUnitTestCase FAILED [junit] Running
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: % ( / ) - fantastic
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server - so these results are for yesterdays code. === head: /home/jbossci/jbossci/logtests/testresults/reports/text/TESTS-TestSuites.txt: No such file or directory ===Thu Jul 3 02:09:38 BST 2003 ===Linux nog 2.4.20-18.7 #1 Thu May 29 08:32:50 EDT 2003 i686 unknown ===java version 1.4.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02) Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode) --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
