[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1309) Run as identity not used for JCA when using security-domain with caller identity
[ http://jira.jboss.com/jira/browse/JBAS-1309?page=history ] Scott M Stark updated JBAS-1309: Fix Version: JBossAS-4.0.1 SP1 Run as identity not used for JCA when using security-domain with caller identity Key: JBAS-1309 URL: http://jira.jboss.com/jira/browse/JBAS-1309 Project: JBoss Application Server Type: Bug Components: JCA service Versions: JBossAS-4.0.1 Final Reporter: Scott M Stark Assignee: Scott M Stark Priority: Critical Fix For: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 If one tries to access a JCA resource in a context that is using a run-as identity, the run-as identity is not the Subject seen in the ManagedConnectionFactory createManagedConnection(Subject subject, ConnectionRequestInfo info) call. The understanding of the security layer in the BaseConnectionManager2 is too limited and should be refactored. This could be made to work with a custom login module, but that really is not the correct solution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Reopened: (JBAS-1356) subscriptionDurability is mispelt :-) in JMSContainerInvoker
[ http://jira.jboss.com/jira/browse/JBAS-1356?page=history ] Scott M Stark reopened JBAS-1356: - subscriptionDurability is mispelt :-) in JMSContainerInvoker Key: JBAS-1356 URL: http://jira.jboss.com/jira/browse/JBAS-1356 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossAS-4.0.2RC1 The retrieval of the activation config property is using the wrong property name in org.jboss.ejb.plugins.JMSContainerInvoker - activationConfig = getActivationConfigProperty(subscriptionDurablity); + activationConfig = getActivationConfigProperty(subscriptionDurability); Workaround use the old EJB2.0 style configuration: subscription-durabilityDurable/subscription-durability -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1356) subscriptionDurability is mispelt :-) in JMSContainerInvoker
[ http://jira.jboss.com/jira/browse/JBAS-1356?page=history ] Scott M Stark updated JBAS-1356: Fix Version: JBossAS-4.0.1 SP1 Merged into the 4.0.1SP1 as well. subscriptionDurability is mispelt :-) in JMSContainerInvoker Key: JBAS-1356 URL: http://jira.jboss.com/jira/browse/JBAS-1356 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 The retrieval of the activation config property is using the wrong property name in org.jboss.ejb.plugins.JMSContainerInvoker - activationConfig = getActivationConfigProperty(subscriptionDurablity); + activationConfig = getActivationConfigProperty(subscriptionDurability); Workaround use the old EJB2.0 style configuration: subscription-durabilityDurable/subscription-durability -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1356) subscriptionDurability is mispelt :-) in JMSContainerInvoker
[ http://jira.jboss.com/jira/browse/JBAS-1356?page=history ] Scott M Stark resolved JBAS-1356: - Resolution: Done subscriptionDurability is mispelt :-) in JMSContainerInvoker Key: JBAS-1356 URL: http://jira.jboss.com/jira/browse/JBAS-1356 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 The retrieval of the activation config property is using the wrong property name in org.jboss.ejb.plugins.JMSContainerInvoker - activationConfig = getActivationConfigProperty(subscriptionDurablity); + activationConfig = getActivationConfigProperty(subscriptionDurability); Workaround use the old EJB2.0 style configuration: subscription-durabilityDurable/subscription-durability -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1320) Security Hole Created by MDB Deployment
[ http://jira.jboss.com/jira/browse/JBAS-1320?page=history ] Scott M Stark updated JBAS-1320: Fix Version: JBossAS-4.0.1 SP1 Security Hole Created by MDB Deployment --- Key: JBAS-1320 URL: http://jira.jboss.com/jira/browse/JBAS-1320 Project: JBoss Application Server Type: Bug Components: Security Versions: JBossAS-3.2.6 Final Reporter: eugene75 Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1, JBossPOJOServer-1.0 Alpha, JBossAS-4.0.1 SP1 During the deployment of a message driven bean, the container creates a connection to the message queue using the user/pwd provided by the deployment descriptor. The authenticated subject created by this operation is bound to the current thread (via the security association class) using a ThreadLocal. The thread that deploys components existing in the deploy directory at startup is the main thread. This means that the main thread has a security association. This security association (meaning the Subject bound to the thread by a ThreadLocal) is then copied to every other thread created by JBoss, including the the HTTP processor threads, class loader threads, etc. The very first time the application is accessed using one of the HTTP processor threads, it has the security association create the jms login. Once the processor thread has processed one request, the security association is cleared and functions normally. A partial workaround is to not deploy the MDBs until after JBoss has finished starting up. This prevents the jms-connection user security association from being inherited by the HTTP processor threads. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1320) Security Hole Created by MDB Deployment
[ http://jira.jboss.com/jira/browse/JBAS-1320?page=history ] Scott M Stark closed JBAS-1320: --- Security Hole Created by MDB Deployment --- Key: JBAS-1320 URL: http://jira.jboss.com/jira/browse/JBAS-1320 Project: JBoss Application Server Type: Bug Components: Security Versions: JBossAS-3.2.6 Final Reporter: eugene75 Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1, JBossPOJOServer-1.0 Alpha, JBossAS-4.0.1 SP1 During the deployment of a message driven bean, the container creates a connection to the message queue using the user/pwd provided by the deployment descriptor. The authenticated subject created by this operation is bound to the current thread (via the security association class) using a ThreadLocal. The thread that deploys components existing in the deploy directory at startup is the main thread. This means that the main thread has a security association. This security association (meaning the Subject bound to the thread by a ThreadLocal) is then copied to every other thread created by JBoss, including the the HTTP processor threads, class loader threads, etc. The very first time the application is accessed using one of the HTTP processor threads, it has the security association create the jms login. Once the processor thread has processed one request, the security association is cleared and functions normally. A partial workaround is to not deploy the MDBs until after JBoss has finished starting up. This prevents the jms-connection user security association from being inherited by the HTTP processor threads. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1391) Add support for datasource failover
[ http://jira.jboss.com/jira/browse/JBAS-1391?page=history ] Scott M Stark reassigned JBAS-1391: --- Assign To: Luc Texier (was: Scott M Stark) Add support for datasource failover --- Key: JBAS-1391 URL: http://jira.jboss.com/jira/browse/JBAS-1391 Project: JBoss Application Server Type: Feature Request Components: JCA service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Luc Texier Fix For: JBossAS-4.0.2 Final The change to org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory is easier than org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory In LocalManagedConnectionFactory add a property delimiter which when present will parse the connectionURL into multiple urls. In XAManagedConnectionFactory you will also need a property to identify which of the xaProps needs to be parsed for mulitple urls. i.e. you need to identify which property contains the server to contact. In both cases, if createManagedConnection fails for the first url, replace it with the second url, and try again until all urls are exhausted. Of course, you can get clever and remember which urls are currently failing and try the non failing urls first, And also if the db is replicating, you might want it to load balance connections across the urls? Also, this design does not allow for using different properties with different db servers, e.g. user and password might change across the servers. It also doesn't enforce that only connections from one connectionURL (db server) are in the pool at the same time in the event the db is not replicating. If you are going to do this, I would suggest you subclass/replicate the managed connection factories and create separate rars so we can mark them as experimental. Adrian Brock Director of Support Back Office JBoss Inc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1391) Add support for datasource failover
[ http://jira.jboss.com/jira/browse/JBAS-1391?page=history ] Scott M Stark updated JBAS-1391: Fix Version: JBossAS-4.0.2 Final Add support for datasource failover --- Key: JBAS-1391 URL: http://jira.jboss.com/jira/browse/JBAS-1391 Project: JBoss Application Server Type: Feature Request Components: JCA service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Luc Texier Fix For: JBossAS-4.0.2 Final The change to org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory is easier than org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory In LocalManagedConnectionFactory add a property delimiter which when present will parse the connectionURL into multiple urls. In XAManagedConnectionFactory you will also need a property to identify which of the xaProps needs to be parsed for mulitple urls. i.e. you need to identify which property contains the server to contact. In both cases, if createManagedConnection fails for the first url, replace it with the second url, and try again until all urls are exhausted. Of course, you can get clever and remember which urls are currently failing and try the non failing urls first, And also if the db is replicating, you might want it to load balance connections across the urls? Also, this design does not allow for using different properties with different db servers, e.g. user and password might change across the servers. It also doesn't enforce that only connections from one connectionURL (db server) are in the pool at the same time in the event the db is not replicating. If you are going to do this, I would suggest you subclass/replicate the managed connection factories and create separate rars so we can mark them as experimental. Adrian Brock Director of Support Back Office JBoss Inc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1439) Update maxHttpHeaderSize to address Tomcat upload performance problem on windows with IE
Update maxHttpHeaderSize to address Tomcat upload performance problem on windows with IE Key: JBAS-1439 URL: http://jira.jboss.com/jira/browse/JBAS-1439 Project: JBoss Application Server Type: Task Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final, JBossAS-4.0.1 SP1 - When Tomcat runs on Windows (I tested XP), and when IE is uploading data, the first read must be at least 8KB, otherwise IE enters OMG, the server is NOT IIS, so let's switch to crap-performance mode. - Other browsers don't have similar problems. - The issue is much less noticeable when Tomcat runs on Unix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1439) Update maxHttpHeaderSize to address Tomcat upload performance problem on windows with IE
[ http://jira.jboss.com/jira/browse/JBAS-1439?page=history ] Scott M Stark closed JBAS-1439: --- Assign To: Remy Maucherat Resolution: Done Update maxHttpHeaderSize to address Tomcat upload performance problem on windows with IE Key: JBAS-1439 URL: http://jira.jboss.com/jira/browse/JBAS-1439 Project: JBoss Application Server Type: Task Components: Web (Tomcat) service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Remy Maucherat Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final, JBossAS-4.0.1 SP1 - When Tomcat runs on Windows (I tested XP), and when IE is uploading data, the first read must be at least 8KB, otherwise IE enters OMG, the server is NOT IIS, so let's switch to crap-performance mode. - Other browsers don't have similar problems. - The issue is much less noticeable when Tomcat runs on Unix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1440) HttpSessionBindingListener broken when replication enabled
[ http://jira.jboss.com/jira/browse/JBAS-1440?page=history ] Scott M Stark moved JBCACHE-79 to JBAS-1440: Project: JBoss Application Server (was: JBoss Cache) Key: JBAS-1440 (was: JBCACHE-79) Component: Clustering Web (Tomcat) service Version: JBossAS-4.0.1 Final Fix Version: JBossAS-4.0.2RC1 JBossAS-4.0.1 SP1 HttpSessionBindingListener broken when replication enabled -- Key: JBAS-1440 URL: http://jira.jboss.com/jira/browse/JBAS-1440 Project: JBoss Application Server Type: Bug Components: Clustering, Web (Tomcat) service Versions: JBossAS-4.0.1 Final Reporter: Stan Silvert Assignee: Ben Wang Fix For: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 Attachments: sessionbindinglistener.zip, tomcat50-service.jar With HttpSessionReplication enabled, an object that implements HttpSessionBindingListener is placed in the session. When the session times out, valueUnbound() is never called. This was reported by a support customer and is found in case 2748: https://na1.salesforce.com/5003000aiwP I have attached a simple WAR to the case that reproduces the problem. It may be that the other related listeners from the servlet spec are not working as well, but this has not been tested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1396) Fix the ejb3 deployer integration
Fix the ejb3 deployer integration - Key: JBAS-1396 URL: http://jira.jboss.com/jira/browse/JBAS-1396 Project: JBoss Application Server Type: Task Components: EJBs Versions: JBossAS-4.0.1 Final Reporter: Scott M Stark Assigned to: Bill Burke Priority: Critical Fix For: JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 The existing ejb3 preview does not run on jboss-4.0.1 due to the api used by the aop deployer to add itself to the subdeployer list. The 4.0.1 release externalized this configuration and the aop deployer needs to be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1381) Clustering with CrossContext Enabled generates exception
[ http://jira.jboss.com/jira/browse/JBAS-1381?page=comments#action_12315209 ] Scott M Stark commented on JBAS-1381: - A testcase for this needs to be added to the existing clustering unit tests. Clustering with CrossContext Enabled generates exception Key: JBAS-1381 URL: http://jira.jboss.com/jira/browse/JBAS-1381 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-4.0.1 Final Reporter: Ben Wang Assignee: Ben Wang Fix For: JBossAS-4.0.1 SP1 Original Estimate: 2 hours Remaining: 2 hours Excerpt from sf case: https://na1.salesforce.com/5003000bw4l We have a Big Application that are deployed as multiple WebApplications and they make crosscontext calls, When we enabled Clustering Seems like FirstCrossContext Failes on this Method. JBOSSCacheManager.createEmptySession(). We would appreciate if you can help us resolve this issue. Note: If i deploy this App on Default Server Configuration and it works fine Basically, the problem is createEmptySession is treated as a un-implemented method since it is also called by passivation and activation. But we will simply return this method call now with a new ClusteredSession instance (depending on the granularity, of course). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-61) Possible RMI exception semantic regression
[ http://jira.jboss.com/jira/browse/JBREM-61?page=comments#action_12315213 ] Scott M Stark commented on JBREM-61: It should either be rethrowing all java.rmi.RemoteExceptions in a ServerException or only conditionally wrapping all java.rmi.RemoteExceptions based on some setting. I did not mean that java.rmi.AccessException should be treated specially. Possible RMI exception semantic regression -- Key: JBREM-61 URL: http://jira.jboss.com/jira/browse/JBREM-61 Project: JBoss Remoting Type: Bug Components: transport Reporter: Scott M Stark Assignee: Tom Elrod Fix For: 1.0.1 final The org.jboss.test.security.test.EJBSpecUnitTestCase.testDeepRunAs method is currently failing in head after the switch of the default invoker to the remoting based unified invoker due to a subtle difference in how exceptions are handled by the jrmp invoker. The test is expecting that the java.rmi.AccessException thrown by the ejb contaner be wrapped in a java.rmi.ServerException. This is a wrapping exception used by the jrmp implementation. The java.rmi.ServerException javadoc: A ServerException is thrown as a result of a remote method invocation when a RemoteException is thrown while processing the invocation on the server, either while unmarshalling the arguments, executing the remote method itself, or marshalling the return value. A ServerException instance contains the original RemoteException that occurred as its cause. The unified invoker is simply throwing back the java.rmi.AccessException. Although this looks like what the JRMPInvoker is doing, this ignores the fact that the jrmp implementation sits between the network and the client. We probably need a strictRMIException mode that allows for the same behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1363) JACC DelegatingPolicy will not work with a SecurityManager installed
[ http://jira.jboss.com/jira/browse/JBAS-1363?page=history ] Scott M Stark updated JBAS-1363: Fix Version: JBossAS-4.0.1 SP1 JBossAS-4.0.2 Final JBossAS-5.0 Alpha JACC DelegatingPolicy will not work with a SecurityManager installed Key: JBAS-1363 URL: http://jira.jboss.com/jira/browse/JBAS-1363 Project: JBoss Application Server Type: Bug Components: Security Versions: JBossAS-4.0.1 Final, JBossAS-5.0 Alpha Reporter: Scott M Stark Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-4.0.1 SP1 If one runs with the JACC policy provided enabled, and also specify that a security manager is intalled, the service fails to start with an exception like: 16:01:48,985 WARN [ServiceController] Problem starting service jboss.security:service=JACCSecurityService java.lang.ClassCircularityError: javax/security/jacc/EJBMethodPermission at org.jboss.security.jacc.DelegatingPolicy.implies(DelegatingPolicy.java:72) at java.security.ProtectionDomain.implies(ProtectionDomain.java:195) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:249) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at sun.misc.URLClassPath.check(URLClassPath.java:398) at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:601) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:673) at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:660) at sun.misc.URLClassPath.findResource(URLClassPath.java:139) at java.net.URLClassLoader$2.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:359) at java.lang.ClassLoader.getResource(ClassLoader.java:977) at org.jboss.mx.loading.RepositoryClassLoader.getResourceLocally(RepositoryClassLoader.java:200) at org.jboss.mx.loading.LoadMgr3$ResourceAction.run(LoadMgr3.java:95) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:247) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:464) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:374) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.jboss.security.jacc.DelegatingPolicy.implies(DelegatingPolicy.java:72) at java.security.ProtectionDomain.implies(ProtectionDomain.java:195) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:249) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.Thread.setContextClassLoader(Thread.java:1306) at org.jboss.mx.server.TCLAction$5.run(TCLAction.java:102) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.TCLAction$2.setContextClassLoader(TCLAction.java:97) at org.jboss.mx.server.TCLAction$UTIL.setContextClassLoader(TCLAction.java:37) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:288) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:908) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:416) The problem is the interaction between the class loading layer attempting to locate the class in question as a resource and the lazy loading of the JACC permission classes from within the Policy.implies override which results in recursion into a ClassCircularityError: Thread main@336 in group jboss status: RUNNING init():32, java.lang.ClassCircularityError implies():72, org.jboss.security.jacc.DelegatingPolicy implies():189, java.security.ProtectionDomain checkPermission():254, java.security.AccessControlContext checkPermission():401, java.security.AccessController checkPermission():524, java.lang.SecurityManager check():397, sun.misc.URLClassPath getResource():884, sun.misc.URLClassPath$FileLoader getResource():157, sun.misc.URLClassPath getResource():209, sun.misc.URLClassPath getBootstrapResource():950, java.lang.ClassLoader getResource():811, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResourceLocally():205, org.jboss.mx.loading.RepositoryClassLoader run():95, org.jboss.mx.loading.LoadMgr3$ResourceAction doPrivileged():-1, java.security.AccessController beginLoadTask():247,
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1389) run-as-principal only propogates one level
[ http://jira.jboss.com/jira/browse/JBAS-1389?page=history ] Scott M Stark resolved JBAS-1389: - Resolution: Cannot Reproduce Bug This appears to be the same as JBAS-1113 which was fixed in 4.0.1: http://jira.jboss.com/jira/browse/JBAS-1113 Runn the testcase shows that the expected run-as identity is seen at the session and entity bean levels: 14:30:28,437 INFO [Server] JBoss (MX MicroKernel) [4.0.1 (build: CVSTag=JBoss_4_0_1 date=200412230944)] Started in 28s:125ms 14:31:09,828 INFO [STDOUT] TestSessionEJB.test, principal = [roles=[TestRole],principal=TestPrincipal] 14:31:09,843 INFO [STDOUT] TestEntity.test, principal = [roles=[TestRole],principal=TestPrincipal] Make sure you are on the 4.0.1 final as evidenced by a version line that matches that shown above. run-as-principal only propogates one level -- Key: JBAS-1389 URL: http://jira.jboss.com/jira/browse/JBAS-1389 Project: JBoss Application Server Type: Bug Components: JMS service, Security, EJBs Versions: JBossAS-4.0.1 Final Environment: Windows XP, JBoss 4.0.1 Reporter: Randy Ott Assignee: Scott M Stark Attachments: JBossTest.zip The JBoss run-as-principal identity only works if calling a single EJB. Example: MDB with run-as-principal set calls SB which calls EB The SB will contain the correct principal name as specified in the jboss.xml file, but when the EB is called, the principal becomes null (or anonymous if using the UsersRolesPassword login module). This is currenlty holding up a port from WLS to JBoss. I have an example to attach. Randy Ott Capstone Consulting [EMAIL PROTECTED] 402.597.3664 x225 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1388) Create property for deployment directory
[ http://jira.jboss.com/jira/browse/JBAS-1388?page=history ]
Scott M Stark resolved JBAS-1388:
-
Resolution: Done
Fix Version: JBossAS-4.0.1 Final
JBossAS-3.2.7 Final
This is already supported. If you set the URLs attribute to the following:
attribute name=URLs
${jboss.server.deploy.list:deploy/}
/attribute
then if the jboss.server.deploy.list property is set it will be used, else the
default of deploy/ is used.
Create property for deployment directory
Key: JBAS-1388
URL: http://jira.jboss.com/jira/browse/JBAS-1388
Project: JBoss Application Server
Type: Feature Request
Reporter: Yevgeny Shakhnovich
Assignee: Scott M Stark
Priority: Trivial
Fix For: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
It is not always convenient to put files for deployment into deploy
directory. JBoss provides the way to modify such default behavior through
attribute URLs of jboss.deployment mbean but it requires modification of
jboss-service.xml which is also inconvenient, especially taking in account
the frequency of jboss upgrades. I would prefer if in jboss-service.xml the
URLs attribute looked like
attribute name=URLs
${jboss.server.deploy.list}
/attribute
where the property jboss.server.deploy.list had the default value deploy/.
In that case, I could specify my components for deployment in the runtime in
a different directory without changing the jboss installation just by setting
the right value for the property. It would simplify upgrades to new jboss
versions.
Thanks,
Yevgeny
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1391) Add support for datasource failover
Add support for datasource failover --- Key: JBAS-1391 URL: http://jira.jboss.com/jira/browse/JBAS-1391 Project: JBoss Application Server Type: Feature Request Components: JCA service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assigned to: Scott M Stark The change to org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory is easier than org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory In LocalManagedConnectionFactory add a property delimiter which when present will parse the connectionURL into multiple urls. In XAManagedConnectionFactory you will also need a property to identify which of the xaProps needs to be parsed for mulitple urls. i.e. you need to identify which property contains the server to contact. In both cases, if createManagedConnection fails for the first url, replace it with the second url, and try again until all urls are exhausted. Of course, you can get clever and remember which urls are currently failing and try the non failing urls first, And also if the db is replicating, you might want it to load balance connections across the urls? Also, this design does not allow for using different properties with different db servers, e.g. user and password might change across the servers. It also doesn't enforce that only connections from one connectionURL (db server) are in the pool at the same time in the event the db is not replicating. If you are going to do this, I would suggest you subclass/replicate the managed connection factories and create separate rars so we can mark them as experimental. Adrian Brock Director of Support Back Office JBoss Inc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1363) JACC DelegatingPolicy will not work with a SecurityManager installed
[ http://jira.jboss.com/jira/browse/JBAS-1363?page=history ] Scott M Stark resolved JBAS-1363: - Resolution: Done JACC DelegatingPolicy will not work with a SecurityManager installed Key: JBAS-1363 URL: http://jira.jboss.com/jira/browse/JBAS-1363 Project: JBoss Application Server Type: Bug Components: Security Versions: JBossAS-4.0.1 Final, JBossAS-5.0 Alpha Reporter: Scott M Stark Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final, JBossAS-4.0.1 SP1 If one runs with the JACC policy provided enabled, and also specify that a security manager is intalled, the service fails to start with an exception like: 16:01:48,985 WARN [ServiceController] Problem starting service jboss.security:service=JACCSecurityService java.lang.ClassCircularityError: javax/security/jacc/EJBMethodPermission at org.jboss.security.jacc.DelegatingPolicy.implies(DelegatingPolicy.java:72) at java.security.ProtectionDomain.implies(ProtectionDomain.java:195) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:249) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at sun.misc.URLClassPath.check(URLClassPath.java:398) at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:601) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:673) at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:660) at sun.misc.URLClassPath.findResource(URLClassPath.java:139) at java.net.URLClassLoader$2.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:359) at java.lang.ClassLoader.getResource(ClassLoader.java:977) at org.jboss.mx.loading.RepositoryClassLoader.getResourceLocally(RepositoryClassLoader.java:200) at org.jboss.mx.loading.LoadMgr3$ResourceAction.run(LoadMgr3.java:95) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:247) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:464) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:374) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.jboss.security.jacc.DelegatingPolicy.implies(DelegatingPolicy.java:72) at java.security.ProtectionDomain.implies(ProtectionDomain.java:195) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:249) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.Thread.setContextClassLoader(Thread.java:1306) at org.jboss.mx.server.TCLAction$5.run(TCLAction.java:102) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.TCLAction$2.setContextClassLoader(TCLAction.java:97) at org.jboss.mx.server.TCLAction$UTIL.setContextClassLoader(TCLAction.java:37) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:288) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:908) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:416) The problem is the interaction between the class loading layer attempting to locate the class in question as a resource and the lazy loading of the JACC permission classes from within the Policy.implies override which results in recursion into a ClassCircularityError: Thread main@336 in group jboss status: RUNNING init():32, java.lang.ClassCircularityError implies():72, org.jboss.security.jacc.DelegatingPolicy implies():189, java.security.ProtectionDomain checkPermission():254, java.security.AccessControlContext checkPermission():401, java.security.AccessController checkPermission():524, java.lang.SecurityManager check():397, sun.misc.URLClassPath getResource():884, sun.misc.URLClassPath$FileLoader getResource():157, sun.misc.URLClassPath getResource():209, sun.misc.URLClassPath getBootstrapResource():950, java.lang.ClassLoader getResource():811, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResourceLocally():205, org.jboss.mx.loading.RepositoryClassLoader run():95, org.jboss.mx.loading.LoadMgr3$ResourceAction doPrivileged():-1, java.security.AccessController beginLoadTask():247, org.jboss.mx.loading.LoadMgr3 The classes needed by the implies method need to be
[JBoss-dev] [JBoss JIRA] Created: (JBREM-60) Incorrect usage of debug level logging
Incorrect usage of debug level logging -- Key: JBREM-60 URL: http://jira.jboss.com/jira/browse/JBREM-60 Project: JBoss Remoting Type: Bug Components: general Reporter: Scott M Stark Assigned to: Tom Elrod org.jboss.remoting.ServerInvoker is logging per request data at debug level. This is inconsistent with the logging threshold usage policy of using trace level for this type of activity. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1368) Deadlocks in Message Persistence when working with Sybase
[ http://jira.jboss.com/jira/browse/JBAS-1368?page=history ] Scott M Stark moved JBMESSAGING-20 to JBAS-1368: Project: JBoss Application Server (was: JBoss Messaging) Key: JBAS-1368 (was: JBMESSAGING-20) Component: JMS service (was: Messaging Core Persistence) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Fix Version: JBossAS-4.0.2RC1 JBossAS-3.2.8 Final Deadlocks in Message Persistence when working with Sybase - Key: JBAS-1368 URL: http://jira.jboss.com/jira/browse/JBAS-1368 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Environment: JBoss 3.2.6 with Sybase 12.5 Reporter: Eran Haggiag Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final This problem is new in 3.2.6 and was not in 3.2.3. This problem happans on high load. Example from the Sybase log : = deadlock #1009 = 00:0:00223:2005/01/20 09:51:58.82 server Deadlock Id 1009 detected Deadlock Id 1009: detected. 1 deadlock chain(s) involved. Deadlock Id 1009: Process (Familyid 1752, 1752) (suid 25) was executing a UPDATE command at line 1. SQL Text: UPDATE JMS_MESSAGES SET [EMAIL PROTECTED], [EMAIL PROTECTED] WHERE [EMAIL PROTECTED] AND [EMAIL PROTECTED] Deadlock Id 1009: Process (Familyid 223, 223) (suid 25) was executing a DELETE command at line 1. SQL Text: DELETE FROM JMS_TRANSACTIONS WHERE TXID = @p0? Deadlock Id 1009: Process (Familyid 0, Spid 223) was waiting for a 'update page' lock on page 12889 of the 'JMS_TRANSACTIONS' table in database 4 but process (Familyid 1752, Spid 1752) already held a 'exclusive page' lock on it. Deadlock Id 1009: Process (Familyid 0, Spid 1752) was waiting for a 'update page' lock on page 12905 of the 'JMS_MESSAGES' table in database 4 but process (Familyid 223, Spid 223) already held a 'exclusive page' lock on it. Deadlock Id 1009: Process (Familyid 0, 1752) was chosen as the victim. End of deadlock information. *Resume starts (Deadlock 1009) * * locked_page- 12889 locked_table- 'JMS_TRANSACTIONS' * locked_page- 12905 locked_table- 'JMS_MESSAGES' * *Resume ends (Deadlock 1009) = deadlock #1009 = = deadlock #1010 = 06:0:00100:2005/01/20 09:51:59.83 server Deadlock Id 1010 detected Deadlock Id 1010: detected. 1 deadlock chain(s) involved. Deadlock Id 1010: Process (Familyid 223, 223) (suid 25) was executing a DELETE command at line 1. SQL Text: DELETE FROM JMS_TRANSACTIONS WHERE TXID = @p0? Deadlock Id 1010: Process (Familyid 100, 100) (suid 25) was executing a UPDATE command at line 1. SQL Text: UPDATE JMS_MESSAGES SET [EMAIL PROTECTED], [EMAIL PROTECTED] WHERE [EMAIL PROTECTED] AND [EMAIL PROTECTED] Deadlock Id 1010: Process (Familyid 0, Spid 100) was waiting for a 'update page' lock on page 12905 of the 'JMS_MESSAGES' table in database 4 but process (Familyid 223, Spid 223) already held a 'exclusive page' lock on it. Deadlock Id 1010: Process (Familyid 0, Spid 223) was waiting for a 'update page' lock on page 12889 of the 'JMS_TRANSACTIONS' table in database 4 but process (Familyid 100, Spid 100) already held a 'exclusive page' lock on it. Deadlock Id 1010: Process (Familyid 0, 223) was chosen as the victim. End of deadlock information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1368) Deadlocks in Message Persistence when working with Sybase
[ http://jira.jboss.com/jira/browse/JBAS-1368?page=history ] Scott M Stark updated JBAS-1368: JBoss Forum Reference: http://www.jboss.org/index.html?module=bbop=viewtopicp=3864492#3864492 Deadlocks in Message Persistence when working with Sybase - Key: JBAS-1368 URL: http://jira.jboss.com/jira/browse/JBAS-1368 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Environment: JBoss 3.2.6 with Sybase 12.5 Reporter: Eran Haggiag Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final This problem is new in 3.2.6 and was not in 3.2.3. This problem happans on high load. Example from the Sybase log : = deadlock #1009 = 00:0:00223:2005/01/20 09:51:58.82 server Deadlock Id 1009 detected Deadlock Id 1009: detected. 1 deadlock chain(s) involved. Deadlock Id 1009: Process (Familyid 1752, 1752) (suid 25) was executing a UPDATE command at line 1. SQL Text: UPDATE JMS_MESSAGES SET [EMAIL PROTECTED], [EMAIL PROTECTED] WHERE [EMAIL PROTECTED] AND [EMAIL PROTECTED] Deadlock Id 1009: Process (Familyid 223, 223) (suid 25) was executing a DELETE command at line 1. SQL Text: DELETE FROM JMS_TRANSACTIONS WHERE TXID = @p0? Deadlock Id 1009: Process (Familyid 0, Spid 223) was waiting for a 'update page' lock on page 12889 of the 'JMS_TRANSACTIONS' table in database 4 but process (Familyid 1752, Spid 1752) already held a 'exclusive page' lock on it. Deadlock Id 1009: Process (Familyid 0, Spid 1752) was waiting for a 'update page' lock on page 12905 of the 'JMS_MESSAGES' table in database 4 but process (Familyid 223, Spid 223) already held a 'exclusive page' lock on it. Deadlock Id 1009: Process (Familyid 0, 1752) was chosen as the victim. End of deadlock information. *Resume starts (Deadlock 1009) * * locked_page- 12889 locked_table- 'JMS_TRANSACTIONS' * locked_page- 12905 locked_table- 'JMS_MESSAGES' * *Resume ends (Deadlock 1009) = deadlock #1009 = = deadlock #1010 = 06:0:00100:2005/01/20 09:51:59.83 server Deadlock Id 1010 detected Deadlock Id 1010: detected. 1 deadlock chain(s) involved. Deadlock Id 1010: Process (Familyid 223, 223) (suid 25) was executing a DELETE command at line 1. SQL Text: DELETE FROM JMS_TRANSACTIONS WHERE TXID = @p0? Deadlock Id 1010: Process (Familyid 100, 100) (suid 25) was executing a UPDATE command at line 1. SQL Text: UPDATE JMS_MESSAGES SET [EMAIL PROTECTED], [EMAIL PROTECTED] WHERE [EMAIL PROTECTED] AND [EMAIL PROTECTED] Deadlock Id 1010: Process (Familyid 0, Spid 100) was waiting for a 'update page' lock on page 12905 of the 'JMS_MESSAGES' table in database 4 but process (Familyid 223, Spid 223) already held a 'exclusive page' lock on it. Deadlock Id 1010: Process (Familyid 0, Spid 223) was waiting for a 'update page' lock on page 12889 of the 'JMS_TRANSACTIONS' table in database 4 but process (Familyid 100, Spid 100) already held a 'exclusive page' lock on it. Deadlock Id 1010: Process (Familyid 0, 223) was chosen as the victim. End of deadlock information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1368) Deadlocks in Message Persistence when working with Sybase
[ http://jira.jboss.com/jira/browse/JBAS-1368?page=history ] Scott M Stark resolved JBAS-1368: - Resolution: Done The table creation ddl statements in the sybase-jdbc2-service.xml sample have been updated as suggested by John Majerus. CREATE_MESSAGE_TABLE = CREATE TABLE dbo.JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL, \ DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER NULL, TXOP CHAR(1), \ MESSAGEBLOB IMAGE, PRIMARY KEY (MESSAGEID, DESTINATION) ) LOCK DATAROWS CREATE_TX_TABLE = CREATE TABLE dbo.JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) ) \ LOCK DATAROWS Deadlocks in Message Persistence when working with Sybase - Key: JBAS-1368 URL: http://jira.jboss.com/jira/browse/JBAS-1368 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Environment: JBoss 3.2.6 with Sybase 12.5 Reporter: Eran Haggiag Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final This problem is new in 3.2.6 and was not in 3.2.3. This problem happans on high load. Example from the Sybase log : = deadlock #1009 = 00:0:00223:2005/01/20 09:51:58.82 server Deadlock Id 1009 detected Deadlock Id 1009: detected. 1 deadlock chain(s) involved. Deadlock Id 1009: Process (Familyid 1752, 1752) (suid 25) was executing a UPDATE command at line 1. SQL Text: UPDATE JMS_MESSAGES SET [EMAIL PROTECTED], [EMAIL PROTECTED] WHERE [EMAIL PROTECTED] AND [EMAIL PROTECTED] Deadlock Id 1009: Process (Familyid 223, 223) (suid 25) was executing a DELETE command at line 1. SQL Text: DELETE FROM JMS_TRANSACTIONS WHERE TXID = @p0? Deadlock Id 1009: Process (Familyid 0, Spid 223) was waiting for a 'update page' lock on page 12889 of the 'JMS_TRANSACTIONS' table in database 4 but process (Familyid 1752, Spid 1752) already held a 'exclusive page' lock on it. Deadlock Id 1009: Process (Familyid 0, Spid 1752) was waiting for a 'update page' lock on page 12905 of the 'JMS_MESSAGES' table in database 4 but process (Familyid 223, Spid 223) already held a 'exclusive page' lock on it. Deadlock Id 1009: Process (Familyid 0, 1752) was chosen as the victim. End of deadlock information. *Resume starts (Deadlock 1009) * * locked_page- 12889 locked_table- 'JMS_TRANSACTIONS' * locked_page- 12905 locked_table- 'JMS_MESSAGES' * *Resume ends (Deadlock 1009) = deadlock #1009 = = deadlock #1010 = 06:0:00100:2005/01/20 09:51:59.83 server Deadlock Id 1010 detected Deadlock Id 1010: detected. 1 deadlock chain(s) involved. Deadlock Id 1010: Process (Familyid 223, 223) (suid 25) was executing a DELETE command at line 1. SQL Text: DELETE FROM JMS_TRANSACTIONS WHERE TXID = @p0? Deadlock Id 1010: Process (Familyid 100, 100) (suid 25) was executing a UPDATE command at line 1. SQL Text: UPDATE JMS_MESSAGES SET [EMAIL PROTECTED], [EMAIL PROTECTED] WHERE [EMAIL PROTECTED] AND [EMAIL PROTECTED] Deadlock Id 1010: Process (Familyid 0, Spid 100) was waiting for a 'update page' lock on page 12905 of the 'JMS_MESSAGES' table in database 4 but process (Familyid 223, Spid 223) already held a 'exclusive page' lock on it. Deadlock Id 1010: Process (Familyid 0, Spid 223) was waiting for a 'update page' lock on page 12889 of the 'JMS_TRANSACTIONS' table in database 4 but process (Familyid 100, Spid 100) already held a 'exclusive page' lock on it. Deadlock Id 1010: Process (Familyid 0, 223) was chosen as the victim. End of deadlock information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1008) destroying context with tomcat5 happens too late
[ http://jira.jboss.com/jira/browse/JBAS-1008?page=history ] Scott M Stark reassigned JBAS-1008: --- Assign To: Remy Maucherat (was: Scott M Stark) destroying context with tomcat5 happens too late Key: JBAS-1008 URL: http://jira.jboss.com/jira/browse/JBAS-1008 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Remy Maucherat Priority: Critical SourceForge Submitter: ittay . Hi, When I stop my JBoss (3.2.5), it first undeployes all beans and only then stops the web service. This causes two wrong behaviors: 1. if some client tries to load a page (or send any request to a servlet), after some beans are undeployed, and before the service is stopped, the servlet will start to work but because the beans were undeployed, will get strange errors (NPE etc.) 2. if i want to hook into the contextDestroyed, to perform some cleanup, it is too late, since beans have already been undeployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1328) Track where UCLs are destroyed to throw a better exception than NPE
[ http://jira.jboss.com/jira/browse/JBAS-1328?page=history ] Scott M Stark updated JBAS-1328: Summary: Track where UCLs are destroyed to throw a better exception than NPE (was: Tack where UCLs are destroyed to throw a better exception than NPE) Track where UCLs are destroyed to throw a better exception than NPE --- Key: JBAS-1328 URL: http://jira.jboss.com/jira/browse/JBAS-1328 Project: JBoss Application Server Type: Task Components: JMX Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Reporter: Scott M Stark Assignee: Scott M Stark Priority: Minor Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 When a redeployment is done and references to a UCL class loader from the previous deployment exist, any attempt to use the UCL results in a NullPointerException because the association between the UCL and its repository have been cleared. A standard ClassNotFoundException with the trace of where the UCL was unregistered would be a better choice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1369) Running JMS server out of threads disables further connections
Running JMS server out of threads disables further connections -- Key: JBAS-1369 URL: http://jira.jboss.com/jira/browse/JBAS-1369 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assigned to: Scott M Stark Priority: Critical Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final If the jboss server runs out of threads while accepting jms connections and this results in an OutOfMemoryError: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start(Native Method) at org.jboss.mq.il.uil2.SocketManager.start(SocketManager.java:131) at org.jboss.mq.il.uil2.UILServerILService.run(UILServerILService.java:134) at java.lang.Thread.run(Thread.java:534) the server accept thread named 'UILServerILService Accept Thread' will be aborted and further connections will fail even if the thread counts drop below the max limit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1369) Running JMS server out of threads disables further connections
[ http://jira.jboss.com/jira/browse/JBAS-1369?page=history ] Scott M Stark resolved JBAS-1369: - Resolution: Done The UILServerILService accept thread run loop now catches any non-IOException and ignores this with a warning message. The accept run loop will only exit if the service is explictly stopped. Running JMS server out of threads disables further connections -- Key: JBAS-1369 URL: http://jira.jboss.com/jira/browse/JBAS-1369 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Scott M Stark Priority: Critical Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final If the jboss server runs out of threads while accepting jms connections and this results in an OutOfMemoryError: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start(Native Method) at org.jboss.mq.il.uil2.SocketManager.start(SocketManager.java:131) at org.jboss.mq.il.uil2.UILServerILService.run(UILServerILService.java:134) at java.lang.Thread.run(Thread.java:534) the server accept thread named 'UILServerILService Accept Thread' will be aborted and further connections will fail even if the thread counts drop below the max limit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1363) JACC DelegatingPolicy will not work with a SecurityManager installed
JACC DelegatingPolicy will not work with a SecurityManager installed Key: JBAS-1363 URL: http://jira.jboss.com/jira/browse/JBAS-1363 Project: JBoss Application Server Type: Bug Components: Security Versions: JBossAS-4.0.1 Final, JBossAS-5.0 Alpha Reporter: Scott M Stark Assigned to: Scott M Stark Priority: Blocker If one runs with the JACC policy provided enabled, and also specify that a security manager is intalled, the service fails to start with an exception like: 16:01:48,985 WARN [ServiceController] Problem starting service jboss.security:service=JACCSecurityService java.lang.ClassCircularityError: javax/security/jacc/EJBMethodPermission at org.jboss.security.jacc.DelegatingPolicy.implies(DelegatingPolicy.java:72) at java.security.ProtectionDomain.implies(ProtectionDomain.java:195) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:249) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at sun.misc.URLClassPath.check(URLClassPath.java:398) at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:601) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:673) at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:660) at sun.misc.URLClassPath.findResource(URLClassPath.java:139) at java.net.URLClassLoader$2.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:359) at java.lang.ClassLoader.getResource(ClassLoader.java:977) at org.jboss.mx.loading.RepositoryClassLoader.getResourceLocally(RepositoryClassLoader.java:200) at org.jboss.mx.loading.LoadMgr3$ResourceAction.run(LoadMgr3.java:95) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:247) at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:464) at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:374) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.jboss.security.jacc.DelegatingPolicy.implies(DelegatingPolicy.java:72) at java.security.ProtectionDomain.implies(ProtectionDomain.java:195) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:249) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.Thread.setContextClassLoader(Thread.java:1306) at org.jboss.mx.server.TCLAction$5.run(TCLAction.java:102) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.TCLAction$2.setContextClassLoader(TCLAction.java:97) at org.jboss.mx.server.TCLAction$UTIL.setContextClassLoader(TCLAction.java:37) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:288) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:908) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:416) The problem is the interaction between the class loading layer attempting to locate the class in question as a resource and the lazy loading of the JACC permission classes from within the Policy.implies override which results in recursion into a ClassCircularityError: Thread main@336 in group jboss status: RUNNING init():32, java.lang.ClassCircularityError implies():72, org.jboss.security.jacc.DelegatingPolicy implies():189, java.security.ProtectionDomain checkPermission():254, java.security.AccessControlContext checkPermission():401, java.security.AccessController checkPermission():524, java.lang.SecurityManager check():397, sun.misc.URLClassPath getResource():884, sun.misc.URLClassPath$FileLoader getResource():157, sun.misc.URLClassPath getResource():209, sun.misc.URLClassPath getBootstrapResource():950, java.lang.ClassLoader getResource():811, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResource():809, java.lang.ClassLoader getResourceLocally():205, org.jboss.mx.loading.RepositoryClassLoader run():95, org.jboss.mx.loading.LoadMgr3$ResourceAction doPrivileged():-1, java.security.AccessController beginLoadTask():247, org.jboss.mx.loading.LoadMgr3 The classes needed by the implies method need to be loaded before the DelegatingPolicy is installed as the java.security.Policy implementation to avoid this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1357) Support for massive mbean counts
Support for massive mbean counts Key: JBAS-1357 URL: http://jira.jboss.com/jira/browse/JBAS-1357 Project: JBoss Application Server Type: Feature Request Components: JMX Versions: JBossAS-4.0.1 Final Reporter: Scott M Stark Assigned to: Scott M Stark Creating thousands of mbeans seems to incur a very large overhead in memory that needs to be investigated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1357) Support for massive mbean counts
[ http://jira.jboss.com/jira/browse/JBAS-1357?page=comments#action_12315055 ] Scott M Stark commented on JBAS-1357: - One obvious scalbility issue is a pattern where a large number of pojos are deployed with the same metadata: Descriptor d = new DescriptorSupport(); d.setField(XMBeanConstants.RESOURCE_REFERENCE, somePojo); d.setField(XMBeanConstants.RESOURCE_TYPE, xmbeanMetadataUrl); xmbean = new XMBean(d, XMBeanConstants.DESCRIPTOR); I believe this is creating duplicate resources as there is no notion of a container like deployment. The obvious example is entity bean instances being deployed with the container type of metadata. Support for massive mbean counts Key: JBAS-1357 URL: http://jira.jboss.com/jira/browse/JBAS-1357 Project: JBoss Application Server Type: Feature Request Components: JMX Versions: JBossAS-4.0.1 Final Reporter: Scott M Stark Assignee: Scott M Stark Creating thousands of mbeans seems to incur a very large overhead in memory that needs to be investigated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1325) String property replacement is not working for constructors.
[ http://jira.jboss.com/jira/browse/JBAS-1325?page=history ]
Scott M Stark resolved JBAS-1325:
-
Resolution: Done
Fix Version: JBossAS-4.0.2RC1
JBossAS-3.2.7 Final
Its been added for 3.2.7 and 4.0.2RC1
String property replacement is not working for constructors.
Key: JBAS-1325
URL: http://jira.jboss.com/jira/browse/JBAS-1325
Project: JBoss Application Server
Type: Feature Request
Versions: JBossAS-4.0.1 Final
Reporter: Roland Rz
Assignee: Scott M Stark
Priority: Minor
Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1
Original Estimate: 5 minutes
Remaining: 5 minutes
In the following sample of an MBean the StringPropertyReplacer is not applied
for the
values needed in the constructor.
mbean code=org.jboss.security.plugins.JaasSecurityDomain
name=jboss.security:service=JaasSecurityDomain,domain=RMI+SSL
constructor
arg type=java.lang.String value=${my.domain.name}
/
/constructor
attribute name=KeyStoreURLmyKeys.ks/attribute
attribute name=KeyStorePasstryIt/attribute
/mbean
In this sample JaasSecurityDomain would be creaded with ${my.domain.name}
as argument
instead of the corresponding SystemProperty.
The fix is very simple:
in org.jboss.system.ServiceCreator.ConstructorInfo#create (around line 287):
Element arg = (Element)list.item(j);
// String signature = arg.getAttribute(type);
String signature =
StringPropertyReplacer.replaceProperties(arg.getAttribute(type));
// String value = arg.getAttribute(value);
String value =
StringPropertyReplacer.replaceProperties(arg.getAttribute(value));
Object realValue = value;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1344) ebxml messaging
[ http://jira.jboss.com/jira/browse/JBAS-1344?page=history ] Scott M Stark moved JBMQ-27 to JBAS-1344: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1344 (was: JBMQ-27) Component: JAXR service Version: JBossAS-4.0.1 Final ebxml messaging --- Key: JBAS-1344 URL: http://jira.jboss.com/jira/browse/JBAS-1344 Project: JBoss Application Server Type: Feature Request Components: JAXR service Versions: JBossAS-4.0.1 Final Reporter: SourceForge User Assignee: Adrian Brock SourceForge Submitter: pucky . The new standard for Business to Business is around the corner! ebXML backed by OASIS and the United Nations, is the next best thing to sliced bread. I believe that if jboss could become the first app server to deploy ebXML messaging and ebXML repositories(out of the box) JBOSS would become not only the defacto standard in apps servers but the deployment of JBOSS is the B2B World would sky rocket. I hope someone could look into this from the JBOSS front! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1349) Message Bridge
[ http://jira.jboss.com/jira/browse/JBAS-1349?page=history ] Scott M Stark moved JBMQ-5 to JBAS-1349: Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1349 (was: JBMQ-5) Component: JMS service (was: Server) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Message Bridge -- Key: JBAS-1349 URL: http://jira.jboss.com/jira/browse/JBAS-1349 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock Priority: Minor Implementation of a MessageBridge. -- This is a proxy that allows messages to be sent to one JMS server and then forwarded to the real destination. To the senders this looks like a plain queue or topic. This is the simplist implementation, more performant implementations are possible: 1) Implement the bridge as a new destination type within JBossMQ 2) It will behave similarly to a Queue but will not accept external receivers. 3) On a background thread (inside a JTA transaction) take some messages from the queue and send them to the real destination. 4) The background thread should automatically recover from a failed connection and retry at configurable intervals. Similarly it should keep retrying if the connection cannot be instantiated at initial startup. This is similar to what the MDB does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1345) Clustered Invocation Layer
[ http://jira.jboss.com/jira/browse/JBAS-1345?page=history ] Scott M Stark moved JBMQ-14 to JBAS-1345: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1345 (was: JBMQ-14) Component: JMS service (was: Transport) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Clustered Invocation Layer -- Key: JBAS-1345 URL: http://jira.jboss.com/jira/browse/JBAS-1345 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock Priority: Minor Clustered Invocation Layer 1) Transportation of the cluster view to the client. 2) Persistent connections that allows the server to recover the client's state after a failure. Both these together will mean the client can transparently failover after a server failure. The persistent connections could be used without clustering where the client waits for server recovery. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1157) System property jboss.server.lib.url not used
[ http://jira.jboss.com/jira/browse/JBAS-1157?page=history ]
Scott M Stark reassigned JBAS-1157:
---
Assign To: Michael Yuan (was: Scott M Stark)
System property jboss.server.lib.url not used
-
Key: JBAS-1157
URL: http://jira.jboss.com/jira/browse/JBAS-1157
Project: JBoss Application Server
Type: Bug
Versions: JBossAS-3.2.6 Final
Reporter: SourceForge User
Assignee: Michael Yuan
SourceForge Submitter: bwallis42 .
Linux (Gentoo, 2.6.7 kernel, glibc 2.3.3)
JDK 1.4.2_05
JBoss 3.2.3
After much struggling to try and move the server library
directory to another place (and not under
#036;{jboss.server.home.url}) I have discovered the the
property jboss.server.lib.url does not seem to be used
at all.
The correct way to move the server lib directory (or
add additional lib directories) is by changing or adding
classpath entries to
#036;{jboss.server.conf.dir}/jboss-service.xml, ie:
classpath codebase=lib archives=*/
could change to
classpath codebase=file:/a/b/lib archives=*/
to load the library files from that new location.
This is documented in jboss-service.xml.
The jboss.server.lib.dir property should be deprecated
and documented as such in ServerConfig.java (with
perhaps a warning generated if it is set) to save future
confusion by others.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1346) JDBC StateManager
[ http://jira.jboss.com/jira/browse/JBAS-1346?page=history ] Scott M Stark moved JBMQ-8 to JBAS-1346: Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1346 (was: JBMQ-8) Component: JMS service (was: Persistence) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final JDBC StateManager - Key: JBAS-1346 URL: http://jira.jboss.com/jira/browse/JBAS-1346 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock Priority: Minor The JDBC StateManager should have operations to create/delete users and subscriptions in the database, just like the old File StateManager did. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1352) Generalized detached invoker proxy factory handling of IClientContainer
Generalized detached invoker proxy factory handling of IClientContainer --- Key: JBAS-1352 URL: http://jira.jboss.com/jira/browse/JBAS-1352 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.7 Final Reporter: Scott M Stark Assigned to: Scott M Stark The generalized detached invoker proxy is not creating a ClientContainerEx when the proxy factory configuration request support for the org.jboss.proxy.IClientContainer interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1355) Refactor initial static deployment through MainDeployer/URLDeploymentScanner
Refactor initial static deployment through MainDeployer/URLDeploymentScanner Key: JBAS-1355 URL: http://jira.jboss.com/jira/browse/JBAS-1355 Project: JBoss Application Server Type: Task Components: MicroContainer bus Versions: JBossAS-4.0.1 Final Reporter: Scott M Stark Assigned to: Scott M Stark An issue related to the started notification discussion in the linked thread, is the behavior of the URLDeploymentScanner emitting a Incomplete Deployment exception on every scan that has services that have not started. The problem here is that if a groups of services is going to be delayed from starting until the server sends its started notification, the URLDeploymentScanner will complain about failed services. The startup and deployment layers need to have a better understanding of the possible multi-stage, system V run level behavior to not emit spuriours error messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1354) Dependency on the ServiceController is broken
Dependency on the ServiceController is broken - Key: JBAS-1354 URL: http://jira.jboss.com/jira/browse/JBAS-1354 Project: JBoss Application Server Type: Bug Components: MicroContainer bus Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assigned to: Scott M Stark A trivial dependency on the ServiceController as illustrated by this mbean service fragment: mbean code=org.jboss.jmx.util.NotificationGroup name=jboss:service=NotificationGroup !-- The service controller injection -- depends optional-attribute-name=ServiceController proxy-type=attributejboss.system:service=ServiceController/depends /mbean fails because the ServiceController controller does not actually register itself as an available service. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1353) If you change the value in the .xml file directly, the over-rides in the service-bindings.xml stop working
[ http://jira.jboss.com/jira/browse/JBAS-1353?page=history ]
Scott M Stark resolved JBAS-1353:
-
Resolution: Rejected
Your understanding of the binding service behavior is not correct then. If you
look at the xsl for the tomcat configuration transform it is looking for the
expected ports to identify the elements needing to be updated. Either change
the port in the xsl, or generalize the xsl to work with a pattern.
If you change the value in the .xml file directly, the over-rides in the
service-bindings.xml stop working
--
Key: JBAS-1353
URL: http://jira.jboss.com/jira/browse/JBAS-1353
Project: JBoss Application Server
Type: Bug
Versions: JBossAS-4.0.1 Final
Environment: Solaris 8
Reporter: GnanaShekar Subramani
Assignee: Scott M Stark
Original Estimate: 1 day
Remaining: 1 day
I have set the port 8080 to 18080 in
${JBoss_Home}/server/node1/deploy/jbossweb-tomcat50.sar/server.xml .
As per my understanding no matter what the port numbers are in the service
descriptor file (server.xml), Those port numbers should be overridden by the
ones given to ServiceBindingManager via
${Jboss_Home}/server/node1/deploy/conf/service-bindings.xml.
But this is not what is happening. Even though I start the 2nd instance of
jboss using the following command, port 18080 is being used.
nohup ./run.sh -Djboss.server.ports=ports-01 -c node1.
I am expecting it to use port 8180, which is mentioned in
${Jboss_Home}/server/node1/deploy/conf/service-bindings.xml.
I am using JBoss 4.0.1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1354) Dependency on the ServiceController is broken
[ http://jira.jboss.com/jira/browse/JBAS-1354?page=history ] Scott M Stark resolved JBAS-1354: - Resolution: Done Fix Version: JBossAS-4.0.2RC1 JBossAS-5.0 Alpha JBossAS-3.2.8 Final A ServiceContext in the RUNNING state is now created in the preRegister callback so that the ServiceController can be used as a depends target. Dependency on the ServiceController is broken - Key: JBAS-1354 URL: http://jira.jboss.com/jira/browse/JBAS-1354 Project: JBoss Application Server Type: Bug Components: MicroContainer bus Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2RC1, JBossAS-3.2.8 Final A trivial dependency on the ServiceController as illustrated by this mbean service fragment: mbean code=org.jboss.jmx.util.NotificationGroup name=jboss:service=NotificationGroup !-- The service controller injection -- depends optional-attribute-name=ServiceController proxy-type=attributejboss.system:service=ServiceController/depends /mbean fails because the ServiceController controller does not actually register itself as an available service. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1265) Restore the patchdir option behavior
[ http://jira.jboss.com/jira/browse/JBAS-1265?page=history ]
Scott M Stark resolved JBAS-1265:
-
Resolution: Done
Fix Version: JBossAS-3.2.7 Final
JBossAS-4.0.2RC1
A --bootdir or -d option has been added which is an absolute directory path or
url to a dir which is prepended to the Main boot classpath. If this is a file
path or url and the path is a dir, the dir and any jars are added to the boot
classpath.
Restore the patchdir option behavior
Key: JBAS-1265
URL: http://jira.jboss.com/jira/browse/JBAS-1265
Project: JBoss Application Server
Type: Feature Request
Components: MicroContainer bus
Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final
Reporter: Scott M Stark
Assignee: Scott M Stark
Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1
Its seems that the patchdir server option no longer is really of much use
since it cannot be used to patch the bootstrap components itself. There was a
new -B|-bootlib option to prepend jars to the bootclasspath added to 3.2
branch and the 4.0.1 release that allowed one to add jars to the dist/lib
directory ahead of any bootstrap jars. This has been critiqued as:
critique
The problem with your patch, from my viewpoint, is that it uses
ServerLoader.addLibrary(). This forces the
javax-management-monitor-Monitor-patch.jar patch to jboss-jmx.jar to reside
in the same directory as the rest of the boot JARs. That means that I either
add my javax-management-monitor-Monitor-patch.jar patch JAR to the
${JBOSS_HOME}/lib directory, which means I'm directly fiddling with the Jboss
distribution and I want to treat that as read-only, or I move all of
${JBOSS_HOME}/lib over to someplace under my own control, which means I am
over-treating the correction. It seems that if the patch to Main uses
ServerLoader.addURL() instead, I can keep the bulk of the boot JARs in
${JBOSS_HOME}/lib and still have the Monitor patch in a directory under my
control.
/critique
I believe the correct resolution is to restore the patchdir option to a
behavior which prepends its argument url to the bootstrap classpath using the
addURL as requested.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1327) UCL should not scan wars for resources
[ http://jira.jboss.com/jira/browse/JBAS-1327?page=history ] Scott M Stark resolved JBAS-1327: - Resolution: Done The ClassLoaderUtils no longer recurses into paths ending in .war to avoid this. UCL should not scan wars for resources -- Key: JBAS-1327 URL: http://jira.jboss.com/jira/browse/JBAS-1327 Project: JBoss Application Server Type: Bug Components: JMX Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 The UCL scanning for resources in its classpath elements can result is excessive and unnecessary delays for wars as these often contain large content including links outside of the war. Only the WEB-INF/classes and WEB-INF/lib content should be added if the war is using the UCL class loader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1327) UCL should not scan wars for resources
UCL should not scan wars for resources -- Key: JBAS-1327 URL: http://jira.jboss.com/jira/browse/JBAS-1327 Project: JBoss Application Server Type: Bug Components: JMX Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Reporter: Scott M Stark Assigned to: Scott M Stark Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 The UCL scanning for resources in its classpath elements can result is excessive and unnecessary delays for wars as these often contain large content including links outside of the war. Only the WEB-INF/classes and WEB-INF/lib content should be added if the war is using the UCL class loader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1307) Confusing stack trace on EJB deployment for missing optional method attribute transaction-timeout
[ http://jira.jboss.com/jira/browse/JBAS-1307?page=history ]
Scott M Stark resolved JBAS-1307:
-
Resolution: Done
Fix Version: JBossAS-3.2.7 Final
JBossAS-4.0.2RC1
JBossAS-5.0 Alpha
The transaction-timeout is not parsed unless its a non-zero string.
Confusing stack trace on EJB deployment for missing optional method attribute
transaction-timeout
---
Key: JBAS-1307
URL: http://jira.jboss.com/jira/browse/JBAS-1307
Project: JBoss Application Server
Type: Bug
Components: EJBs
Versions: JBossAS-3.2.6 Final
Environment: JBoss 3.2.6, Java 1.4.2, Linux
Reporter: Jurjan-Paul Medema
Assignee: Scott M Stark
Priority: Minor
Fix For: JBossAS-3.2.7 Final, JBossAS-5.0 Alpha, JBossAS-4.0.2RC1
This bug is not critical, but unnecessary stack traces at DEBUG level make
the log look untidy and make both system administrators and developers spend
precious time investigating a problem that doesn't exist.
On deployment of my EJBs in JBoss 3.2.6 NumberFormatExceptions are logged
repeatedly with stack traces on DEBUG level:
2005-01-19 16:23:21,765 DEBUG [org.jboss.deployment.MainDeployer] create step
for deployment file:/home/jpm/jboss/jboss-3.2.6/
server/myproject/deploy/myproject-ejb.jar
2005-01-19 16:23:21,766 DEBUG [org.jboss.ejb.EJBDeployer] create,
myproject-ejb.jar
2005-01-19 16:23:27,172 DEBUG [org.jboss.metadata.MetaData] Ignoring
transaction-timeout 'null'
java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:436)
at java.lang.Integer.parseInt(Integer.java:518)
at
org.jboss.metadata.BeanMetaData.importJbossXml(BeanMetaData.java:790)
at
org.jboss.metadata.EntityMetaData.importJbossXml(EntityMetaData.java:341)
at
org.jboss.metadata.ApplicationMetaData.importJbossXml(ApplicationMetaData.java:729)
at org.jboss.metadata.XmlFileLoader.load(XmlFileLoader.java:175)
at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:462)
...
A relevant piece of the (XDoclet-generated) jboss.xml contained in the .jar
file looks like:
entity
ejb-nameMyEntity/ejb-name
jndi-nameejb/myproject/MyEntity/jndi-name
local-jndi-nameejb/myproject/MyEntity/local-jndi-name
method-attributes
method
method-namegetId/method-name
read-onlytrue/read-only
/method
method
method-namegetStatus/method-name
read-onlytrue/read-only
/method
...
/method-attributes
/entity
...
So, my method-attributes don't contain the *optional* transaction-timeout
element, which should be perfectly legal (it was in JBoss 3.2.1 anyway).
The following piece of JBoss code (from BeanMetaData.java, from line 787)
appears to be the culprit:
String txTimeout = getOptionalChildContent(maNode, transaction-timeout);
try
{
ma.txTimeout = Integer.parseInt(txTimeout);
}
catch (Exception ignore)
{
log.debug(Ignoring transaction-timeout ' + txTimeout + ', ignore);
}
I suggest that txTimeout should be tested for a null value before attempting
to parse it as integer. Apart from that, no stack trace should be logged for
something that can be legally ignored.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-963) post-table-create failure
[ http://jira.jboss.com/jira/browse/JBAS-963?page=history ] Scott M Stark reassigned JBAS-963: -- Assign To: Alexey Loubyansky (was: Scott M Stark) post-table-create failure - Key: JBAS-963 URL: http://jira.jboss.com/jira/browse/JBAS-963 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Alexey Loubyansky SourceForge Submitter: speedyg . Operating System : Windows XP JDK : 1.4.2_04 Create 2 CMP beans with a one-to-many relation (use relation-table as the preferred relation mapping). Specify default values in the jbosscmp-jdbc.xml file for both beans and the relation. When the server is started, default values are correctly inserted for both beans but an SQLException is thrown while inserting data in the relation table. In fact the sql statement is not correctly selected. See the attached file for example and comments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-220) EJQQL row locking (FOR UPDATE request)
[ http://jira.jboss.com/jira/browse/JBAS-220?page=history ] Scott M Stark updated JBAS-220: --- Comment: was deleted EJQQL row locking (FOR UPDATE request) -- Key: JBAS-220 URL: http://jira.jboss.com/jira/browse/JBAS-220 Project: JBoss Application Server Type: Feature Request Components: CMP service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: attachvishal . lets assume there are 3 entity beans (A,B,C) and all of them defined /row-locking as true. there is a cmr relationship between A and B and also A and C. If i write ejbql to look for Object(C) something like this SELECT OBJECT(C) FROM cnCustomerSchema A, IN (A.addressDetails) B , IN(A.phoneDetails) C WHERE A.cnCustomer = ?1 and B.current_Flg ='F' and B.occupied_Flg ='T' and B.cnAddress_Type = ?2 if i add FOR UPDATE at this end of this ejbql the ql will not get parsed . i think we should have provision to define FOR UPDATE in ejbQL? I know this will not be allowed here as it will not be valid query but we should be allowed to add FOR UPDATE to single table -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1331) Could not stop JMS connection
[ http://jira.jboss.com/jira/browse/JBAS-1331?page=history ] Scott M Stark moved JBMQ-106 to JBAS-1331: -- Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1331 (was: JBMQ-106) Component: JMS service (was: Server) Version: JBossAS-4.0.1 Final (was: JBossAS-4.0.1) Could not stop JMS connection - Key: JBAS-1331 URL: http://jira.jboss.com/jira/browse/JBAS-1331 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-4.0.1 Final Reporter: Tim McCune Assignee: Adrian Brock Attachments: patch.txt Sometimes my JBoss client will lose its connection to the server and it gets into a never-ending loop of spewing errors because Connection.doStop throws an exception. The stack trace looks like this: ERROR Jan 26 08:53:25 [plugins.jms.JMSContainerInvoker] - Could not stop JMS connectionorg.jboss.mq.SpyJMSException: Cannot disable the connection with the JMS server; - nested throwable: (java.io.IOException: Client is not connected)at org.jboss.mq.Connection.doStop(Connection.java:1289)at org.jboss.mq.Connection.stop(Connection.java:718)at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStop(JMSContainerInvoker.java:876) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$ExceptionListenerImpl.run(JMSContainerInvoker.java:1316) at java.lang.Thread.run(Thread.java:595)Caused by: java.io.IOException: Client is not connectedat org.jboss.mq.il.uil2.SocketManager.internalSendMessage(SocketManager.java:232) at org.jboss.mq.il.uil2.SocketManager.sendMessage(SocketManager.java:200) at org.jboss.mq.il.uil2.UILServerIL.setEnabled(UILServerIL.java:189) at org.jboss.mq.Connection.doStop(Connection.java:1285)... 4 more This error occurs every 2 minutes until I restart the server. I patched Connection.java inside doStop to just log a warning if the call to serverIL.setEnabled throws an exception instead of wrapping it in a JMSException and rethrowing it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1334) Redeploy UIL2/OIL under java 1.3
[ http://jira.jboss.com/jira/browse/JBAS-1334?page=history ] Scott M Stark moved JBMQ-95 to JBAS-1334: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1334 (was: JBMQ-95) Component: JMS service Version: JBossAS-3.2.7 Final Redeploy UIL2/OIL under java 1.3 Key: JBAS-1334 URL: http://jira.jboss.com/jira/browse/JBAS-1334 Project: JBoss Application Server Type: Bug Components: JMS service Versions: JBossAS-3.2.7 Final Reporter: SourceForge User Assignee: Adrian Brock SourceForge Submitter: ejort . org.jboss.mq.il.oil.OILServerILService org.jboss.mq.il.uil2.UILServerILService Closing the server socket in stopService() does not interrupt the accept thread under java 1.3 nor does acceptThread.interrupt() if the thread is in serverSocket.accept() Does anybody know how to correctly interrupt a thread that is in serverSocket.accept() under java 1.3 or is this due to crappy VM implementation? Using SOTimeout isn't really an option since we would have to make it a reasonable length of time to stop it spinning. Which means to allow a redeploy, we would have to join the acceptThread. This potentially means a long wait during a redeploy or shutdown. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1332) NullPointerException in JDBC3 PersistenceManager
[ http://jira.jboss.com/jira/browse/JBAS-1332?page=history ] Scott M Stark moved JBMQ-105 to JBAS-1332: -- Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1332 (was: JBMQ-105) Version: JBossAS-4.0.1 Final NullPointerException in JDBC3 PersistenceManager Key: JBAS-1332 URL: http://jira.jboss.com/jira/browse/JBAS-1332 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.1 Final Environment: JBoss 4.0.1 (why isn't this an option in the Version list?) Reporter: Tim McCune Priority: Critical http://cvs.sourceforge.net/viewcvs.py/jboss/jbossmq/src/main/org/jboss/mq/pm/jdbc3/PersistenceManager.java?r1=1.6.4.1r2=1.6.4.2 ejort removed the line rs = stmt.executeQuery(); so line 850 of PersistenceManager will always throw an NPE: Caused by: java.lang.NullPointerException at org.jboss.mq.pm.jdbc3.PersistenceManager.loadFromStorage(PersistenceManager.java:850) at org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:411) at org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:351) at org.jboss.mq.server.MessageReference.getMessage(MessageReference.java:156) at org.jboss.mq.server.MessageReference.getHeaders(MessageReference.java:249) at org.jboss.mq.server.BasicQueue.receive(BasicQueue.java:471) at org.jboss.mq.server.JMSQueue.receive(JMSQueue.java:136) I'm assuming this was just a slip-up and not intentional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1336) Need better control over the pm memory usage during destination recovery
[ http://jira.jboss.com/jira/browse/JBAS-1336?page=history ] Scott M Stark moved JBMQ-2 to JBAS-1336: Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1336 (was: JBMQ-2) Issue Type: Task (was: Patch) Component: JMS service (was: Persistence) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final (was: JBossAS-3.2.5) Need better control over the pm memory usage during destination recovery Key: JBAS-1336 URL: http://jira.jboss.com/jira/browse/JBAS-1336 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Adrian Brock When starting up jboss with a destination with either a large number or very large persistent messages, the jdbc pm may run out of memory if the select * from the db results in the jdbc driver pulling in all of the records. We need to either write the pm with this expectation or allow for some configuration to avoid this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1337) Thread Pool improvements on the server
[ http://jira.jboss.com/jira/browse/JBAS-1337?page=history ] Scott M Stark moved JBMQ-9 to JBAS-1337: Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1337 (was: JBMQ-9) Component: JMS service (was: Server) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Thread Pool improvements on the server -- Key: JBAS-1337 URL: http://jira.jboss.com/jira/browse/JBAS-1337 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock There are a number of different components on the server that use thread pools. 1) Invocation Layers 2) Client Consumer for delivering messages 3) Scheduled delivery/message expiration These need to be combined to share threads and minimize context switching where possible. The thread pool should be based on the BasicThreadPool from jboss-common -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1341) XA Recovery
[ http://jira.jboss.com/jira/browse/JBAS-1341?page=history ] Scott M Stark moved JBMQ-13 to JBAS-1341: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1341 (was: JBMQ-13) Component: JMS service (was: Persistence) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final XA Recovery --- Key: JBAS-1341 URL: http://jira.jboss.com/jira/browse/JBAS-1341 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock XARecovery needs to completed by implementing XAResource.recover(). To make this work, the persistence manager will need to remember the Xids and return the list in response to the above request. The current implementation which heuristically rollsback incomplete transactions at recovery will need to be disabled when recovery is required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1342) Message Serialization
[ http://jira.jboss.com/jira/browse/JBAS-1342?page=history ] Scott M Stark moved JBMQ-15 to JBAS-1342: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1342 (was: JBMQ-15) Component: JMS service (was: Transport) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Message Serialization - Key: JBAS-1342 URL: http://jira.jboss.com/jira/browse/JBAS-1342 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock The message body does not need to be deserialized on the server. It could just be retained as byte[] This will avoid unnecessary Object serialiation at the transport and persistent layer inside the server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1338) Thread Pool improvements on the client
[ http://jira.jboss.com/jira/browse/JBAS-1338?page=history ] Scott M Stark moved JBMQ-10 to JBAS-1338: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1338 (was: JBMQ-10) Component: JMS service (was: Client) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Thread Pool improvements on the client -- Key: JBAS-1338 URL: http://jira.jboss.com/jira/browse/JBAS-1338 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock The thread usage on the client needs to be improved. The users of threads are: 1) The invocation layers for message delivery 2) The message listeners to wait for messages These should be combinded to use a single thread pool. There is no need for a message listener to hold a thread while it is waiting for a message. It can add itself to a registry which is then used by delivery to invoke the correct listener when a message arrives. In fact, by spec the listeners should register themselves with the session and the session deliver the messages (single threadedly - is that a word? :-). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1339) Persistence Manager Improvements
[ http://jira.jboss.com/jira/browse/JBAS-1339?page=history ] Scott M Stark moved JBMQ-11 to JBAS-1339: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1339 (was: JBMQ-11) Component: JMS service (was: Persistence) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Persistence Manager Improvements Key: JBAS-1339 URL: http://jira.jboss.com/jira/browse/JBAS-1339 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock There are a number of improvements that can be made to the persistence manager. This should really be done by writing a new version that can then be optionally used while it is experimental. 1) Make use of the datasource mappings - similar what has been done for the EJB timer 2) The use of the JTA transaction is unnecessary since we are the only one in the transaction branch. The tranaction still needs suspending so we are isolated from any wrapping transacton. 3) Make use of build writes to the database This can be used for transactional sessions where multiple messages are processed But it could also be used where people want to relax the absolute requirement that messages are persisted in return for some performance improvement. 4) A general review/rewrite of where the persistence manager is invoked from the server with an aim to improve performance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1340) Lazily Loading Queues
[ http://jira.jboss.com/jira/browse/JBAS-1340?page=history ] Scott M Stark moved JBMQ-12 to JBAS-1340: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1340 (was: JBMQ-12) Component: JMS service (was: Persistence) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Lazily Loading Queues - Key: JBAS-1340 URL: http://jira.jboss.com/jira/browse/JBAS-1340 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock This is a major change that is the last obstacle to JBossMQ scalability. The idea is that messages will only be loaded into the server when the destination is activated and then only part of the messages are loaded (enough to deal with the current throughput). An attempt was made to do this and committed on Branch JBoss_3_2_5_JBossMQ_Lazy but the work was abandoned. It does not deal with the more difficult problems. In any case, the BasicQueues should be talking directly with the PersistenceManager. In fact, I would favour that the BasicQueue implementation is actually pluggable and determined by the PM to allow better optimization between these two important layers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1343) ReadAhead and DUPS_OK message acknowledgement
[ http://jira.jboss.com/jira/browse/JBAS-1343?page=history ] Scott M Stark moved JBMQ-16 to JBAS-1343: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1343 (was: JBMQ-16) Component: JMS service (was: Transport) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final ReadAhead and DUPS_OK message acknowledgement - Key: JBAS-1343 URL: http://jira.jboss.com/jira/browse/JBAS-1343 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock Performance can be improved by sending mulitple messages in one request to the client when they are using a MessageListener. Similary, there is no implementation of DUPS_OK message acknowledgement, which would reduce the number of network requests required to acknowledge receipt of messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1348) Message Selector Performance
[ http://jira.jboss.com/jira/browse/JBAS-1348?page=history ] Scott M Stark moved JBMQ-6 to JBAS-1348: Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1348 (was: JBMQ-6) Component: JMS service (was: Server) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Message Selector Performance Key: JBAS-1348 URL: http://jira.jboss.com/jira/browse/JBAS-1348 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock Priority: Minor Improving Message Selector Performance It is a common anti-pattern for users to set up a contested queue where multiple receivers try to take messages based on a message selector. In most circumstances a Topic is what they should be using. But there is a circumstance where a Topic does not work as required, that is when a message matches many of the receiver's selector but you only want one receiver to process the message (it doesn't matter which). The problem is that when a receiver does not match a message towards the top of a large Queue (or none at all). The operation to find a message or discover there are no messages is very expensive. It is read and skip. This can be even worse when the bottom of the queue has been moved out to disk by the MessageCache. The solution is to provide an index over a particular property, e.g. mbean code=org.jboss.mq.server.jmx.Queue name=jboss.mq.destination:service=Queue,name=A optimized-selectorJMSMessageID/optimized-selector depends optional-attribute-name=DestinationManagerjboss.mq:service=DestinationManager/depends /mbean This configuration should be passed via the BasicQueueParameters to the BasicQueue. NOTE: This is irrevelent for Topics. Topics run their selector before the message is added to the subscription, anything not matching the selector is dropped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1330) Client can't connect to cluster after network failure / forgets about target servers
[ http://jira.jboss.com/jira/browse/JBAS-1330?page=comments#action_12314996 ] Scott M Stark commented on JBAS-1330: - There was a change made for 3.2.7 that addresses this. See the org.jboss.proxy.ejb.RetryInterceptor. Inclusion of this interceptor in the home/bean proxy interceptor stack allows for recovery of the invoker after complete shutdown of the cluster. This works for any ha invoker, not just the JRMP version. Client can't connect to cluster after network failure / forgets about target servers Key: JBAS-1330 URL: http://jira.jboss.com/jira/browse/JBAS-1330 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-3.2.6 Final Environment: jbossas-3.2.6 running on sun jdk 1.4.2_05 on linux 2.4.18 (debian). Client is a standalone tomcat 5.0.27 Reporter: ahus1 Assignee: Scott M Stark Attachments: JRMPInvokerProxyHA.java.3.2.6.patch Original Estimate: 2 hours Remaining: 2 hours Szenario: (1) Client connects to one or more jboss servers. The beans are clustered. On the initial connect the client receives a list of cluster members. (2) All JBoss servers become unavailable, either during a temporary network failure to during a redeploy. (3) When the clients tries to connect to the servers, all will be marked as as dead by JRMPInvokerProxyHA.java (removeDeadTarget()). (4) After the network links becomes the client has forgotten about all servers and is unable to reconnect. Suggested Solution (patch attached): restore the last known list of targets whenever the list of targets has run empty. If anything is unclear, please don't hesitate to contact me. In our production environment this scenario occurs i.e. when a backup switch takes over from a master switch -- if the takeovers takes some time to propagate, the client is unable to connect again and needs to be restarted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1289) JDBCCustomFinderQuery hides ObjectNotFoundException
[ http://jira.jboss.com/jira/browse/JBAS-1289?page=history ]
Scott M Stark resolved JBAS-1289:
-
Resolution: Done
Fix Version: JBossAS-3.2.7 Final
JBossAS-4.0.2RC1
JBossAS-5.0 Alpha
The unnecessary exception logging and wrapping has been removed.
JDBCCustomFinderQuery hides ObjectNotFoundException
---
Key: JBAS-1289
URL: http://jira.jboss.com/jira/browse/JBAS-1289
Project: JBoss Application Server
Type: Bug
Components: EJBs
Versions: JBossAS-3.2.7 Final
Reporter: David Deuchert
Assignee: Scott M Stark
Priority: Minor
Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1, JBossAS-5.0 Alpha
When a custom finder method returns an ObjectNotFoundException, the exception
is logged as an error and re-wrapped inside a more generic FinderException.
There are two problems here:
1) The hiding of the ObjectNotFoundException
2) The extra logging of an error level message, the application code might
be expecting an ObjectNotFound exception (test for existance) and does not
require logging...
The following is a code snippet that shows a diff between the current code
and a potential fix:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCustomFinderQuery.java
- Line #134
***
*** 134,143
}
catch(InvocationTargetException e)
{
! log.error(Error invoking custom finder + finderMethod.getName(),
! e.getTargetException());
! throw new FinderException(Errror invoking cutom finder +
! finderMethod.getName() + : + e.getTargetException());
}
}
--- 134,149
}
catch(InvocationTargetException e)
{
! Throwable t = e.getTargetException();
! if (t instanceof FinderException) {
! // Just quietly rethrow the original finder exception...
! throw (FinderException)t;
! } else {
! log.error(Error invoking custom finder +
finderMethod.getName(
),
! t);
! throw new FinderException(Errror invoking cutom finder +
! finderMethod.getName() + : + t);
! }
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-71) Problem returning a Remote Interface from Business method Using IIOP with EJB on jboss-3.2.5
[ http://jira.jboss.com/jira/browse/JBAS-71?page=history ]
Scott M Stark updated JBAS-71:
--
Description:
I am using IIOP and my bean type is Statefull Beans. All Descriptors are set
properly.
Process Desctiption:
Followint in my beans business method which returns a(IRemote) Interface which
extended from Remote Interface.This new interface is Implemented By my RMI
class(RemoteImpl) extending PortableRemoteObject.
Problem Method:
public IRemote callme() throws RemoteException
{
RemoteImpl remoteimpl=new RemoteImpl(?program?);
return (IRemote) remoteimpl;
}
Above Business Method Throws server side error as Follows:
15:32:33,470 INFO [JkMain] Jk running ID=0 time=0/330 config=null
15:34:15,310 ERROR [jacorb]org.omg.CORBA.portable.UnknownException: vmcid:
0x0 minor code: 0 completed:
Maybe
at
org.jboss.iiop.rmi.marshal.strategy.SkeletonStrategy.writeException(SkeletonStrategy.java:164)
at
org.jboss.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:236)
at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
at org.jacorb.poa.RequestProcessor.process(Unknown Source)
at org.jacorb.poa.RequestProcessor.run(Unknown Source)
was:
I am using IIOP and my bean type is Statefull Beans. All Descriptors are set
properly.
Process Desctiption:
Followint in my beans business method which returns a(IRemote) Interface which
extended from Remote Interface.This new interface is Implemented By my RMI
class(RemoteImpl) extending PortableRemoteObject.
Problem Method:
public IRemote callme() throws RemoteException
{
RemoteImpl remoteimpl=new RemoteImpl(?program?);
return (IRemote) remoteimpl;
}
Above Business Method Throws server side error as Follows:
15:32:33,470 INFO [JkMain] Jk running ID=0 time=0/330 config=null
15:34:15,310 ERROR [jacorb]org.omg.CORBA.portable.UnknownException: vmcid:
0x0 minor code: 0 completed:
Maybe
at
org.jboss.iiop.rmi.marshal.strategy.SkeletonStrategy.writeException(SkeletonStrategy.java:164)
at
org.jboss.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:236)
at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
at org.jacorb.poa.RequestProcessor.process(Unknown Source)
at org.jacorb.poa.RequestProcessor.run(Unknown Source)
Version: JBossAS-3.2.5 Final
(was: JBossAS-3.2.6 Final)
Problem returning a Remote Interface from Business method Using IIOP with EJB
on jboss-3.2.5
Key: JBAS-71
URL: http://jira.jboss.com/jira/browse/JBAS-71
Project: JBoss Application Server
Type: Bug
Components: EJBs
Versions: JBossAS-3.2.5 Final
Environment: Windows XP, JDK 1.4.2_04
Reporter: Millin Parikh
Assignee: Scott M Stark
Original Estimate: 2 days
Remaining: 2 days
I am using IIOP and my bean type is Statefull Beans. All Descriptors are set
properly.
Process Desctiption:
Followint in my beans business method which returns a(IRemote) Interface
which extended from Remote Interface.This new interface is Implemented By my
RMI class(RemoteImpl) extending PortableRemoteObject.
Problem Method:
public IRemote callme() throws RemoteException
{
RemoteImpl remoteimpl=new RemoteImpl(?program?);
return (IRemote) remoteimpl;
}
Above Business Method Throws server side error as Follows:
15:32:33,470 INFO [JkMain] Jk running ID=0 time=0/330 config=null
15:34:15,310 ERROR [jacorb]org.omg.CORBA.portable.UnknownException: vmcid:
0x0 minor code: 0 completed:
Maybe
at
org.jboss.iiop.rmi.marshal.strategy.SkeletonStrategy.writeException(SkeletonStrategy.java:164)
at
org.jboss.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:236)
at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
at org.jacorb.poa.RequestProcessor.process(Unknown Source)
at org.jacorb.poa.RequestProcessor.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-25) Get 3.2 testsuite running under jdk 1.3
[ http://jira.jboss.com/jira/browse/JBAS-25?page=history ] Scott M Stark resolved JBAS-25: --- Resolution: Done Get 3.2 testsuite running under jdk 1.3 --- Key: JBAS-25 URL: http://jira.jboss.com/jira/browse/JBAS-25 Project: JBoss Application Server Type: Task Versions: JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-3.2.7 Final The 3.2.6 release had regressions that broke compilation and running under jdk1.3. The 3.2 testsuite needs to be running well under jdk 1.3 for the 3.2.7 release. There are some tests that do rely on jdk 1.4.x features that may not be resolvable, but the majority of the tests should be working correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1347) Improved management
[ http://jira.jboss.com/jira/browse/JBAS-1347?page=history ] Scott M Stark moved JBMQ-7 to JBAS-1347: Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1347 (was: JBMQ-7) Component: JMS service (was: Server) Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Improved management --- Key: JBAS-1347 URL: http://jira.jboss.com/jira/browse/JBAS-1347 Project: JBoss Application Server Type: Task Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: Adrian Brock Priority: Minor There are a number of areas in JBossMQ that could be better exposed for management. The main one is the ClientConsumers. This would allow an admin to break a connection with a client and also see stats at the client level. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1335) Kerberos for JMS
[ http://jira.jboss.com/jira/browse/JBAS-1335?page=history ] Scott M Stark moved JBMQ-91 to JBAS-1335: - Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1335 (was: JBMQ-91) Component: JMS service Version: JBossAS-4.0.1 Final JBossAS-3.2.7 Final Kerberos for JMS Key: JBAS-1335 URL: http://jira.jboss.com/jira/browse/JBAS-1335 Project: JBoss Application Server Type: Feature Request Components: JMS service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: solsoliri . Could a support for Kerberos security be added to the JMS architecture of JBoss? JMS maybe can be secured via SSL (not very clear for me at the moment), but I have found absolut no documentation for securing JMS via Kerberos. This could be helpfull for the following scenario: - sending binary messages from EJB's (e.g. session bean) to another server over an unsecured network (e.g. the Internet) and the other way round - only queue mode of messaging is used - mutual authentication is needed (server and client) - encryption of the message with Kerberos I've attached a sample java file how I solved this via a simple socket connection and GSS API. Maybe this gives you a little help. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1350) Add support for accessing the invoker proxy container state
Add support for accessing the invoker proxy container state
---
Key: JBAS-1350
URL: http://jira.jboss.com/jira/browse/JBAS-1350
Project: JBoss Application Server
Type: Feature Request
Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final
Reporter: Scott M Stark
Assigned to: Scott M Stark
Fix For: JBossAS-3.2.7 Final
Support for the following IClientContainer interface contract should exist in
the detached invoker proxies:
public interface IClientContainer
{
/**
* Access a copy of the proxy container interceptor stack.
* @return ArrayListorg.jboss.proxy.Interceptor
*/
public ArrayList getInterceptors();
/**
* Set the proxy container interceptor stack.
* @param interceptors - ArrayListorg.jboss.proxy.Interceptor to
* install as the new interceptor stack
*/
public void setInterceptors(ArrayList interceptors);
/**
* Access the InvocationContext associated with the proxy by the
* server side proxy factory. The contents of this will depend on
* the proxy factory.
* @return The proxy creation time InvocationContext
*/
public InvocationContext getInvocationContext();
}
This allows clients of the proxies to manipulate the proxy state in a more
dynamic manner.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1333) connectionFailure
[ http://jira.jboss.com/jira/browse/JBAS-1333?page=history ] Scott M Stark moved JBMQ-104 to JBAS-1333: -- Project: JBoss Application Server (was: JBoss MQ) Key: JBAS-1333 (was: JBMQ-104) Component: (was: Transport) Version: JBossAS-4.0.1 Final (was: JBossAS-4.0.1) connectionFailure - Key: JBAS-1333 URL: http://jira.jboss.com/jira/browse/JBAS-1333 Project: JBoss Application Server Type: Bug Versions: JBossAS-4.0.1 Final Reporter: Adrian Brock The connectionFailure invocation from the IL layer needs to pass through the interceptor rather than just invoking on the destination manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-837) Local interface bug
[ http://jira.jboss.com/jira/browse/JBAS-837?page=history ] Scott M Stark resolved JBAS-837: Resolution: Deferred Reopen with the details of the lookup failure using a more recent jboss version. Local interface bug --- Key: JBAS-837 URL: http://jira.jboss.com/jira/browse/JBAS-837 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: softwaremasters . I have entity beans with only local interfaces and session bean facades with only remote interfaces. Under 3.2.3, I kept getting the warning that no clustered invokers were defined for the entity beans. There was no warning for the session beans. When I also created remote interfaces for the entity beans, the warning messages went away. Also, after awhile, I can no longer find some of my entity beans through the local home interfaces. I haven't tried this with the remote home interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-630) Redeploy of WAR files : EJBs become null in JNDI
[ http://jira.jboss.com/jira/browse/JBAS-630?page=history ] Scott M Stark closed JBAS-630: -- Resolution: Out of Date Redeploy of WAR files : EJBs become null in JNDI -- Key: JBAS-630 URL: http://jira.jboss.com/jira/browse/JBAS-630 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: roullian . OS : Win2K JDK : Sun 1.4.2 with -server I have a war file (war A), and an ear file (ear A) which contains a bunch of EJBs. I have a second ear file (ear B) which contains another war file (war B). (In this second case war B is included in ear B, I also tested with war B outside of ear B, but I still had the same exact problems). war A is just accessing ear A, and has done so successfully for several months. war B is accessing EJBs included in ear A and ear B. Hot redeploy of war A is ok. But hot redeploy of ear B (which contains war B) causes every code accessing ear A to fail (including war A). This only occur when hot redeploying ear B (a clean start works, for example). And if I'm using some EJB from ear A during the hot redeploy of ear B, this EJB will still work afterwards (however the other EJBs from EAR A will stop working...). This is clearly a very strange behavior, and I *need* to have several apps deployed in JBoss... Here is the way I access EJBs : XDoclet-generated util file, with the physical (ie JNDI) access. I'm currently testing with the logical (ie java:comp/env) access. Here is a typical error : A ClassCastException, when doing the JNDI lookup. In fact, it seems that JNDI is returning null, which causes the the ClassCastException. No NamingException returned. And the EJB is still visible in the JNDI tree, but was not accessed (according to the stats in the JBoss web console). I can send you the various WARs/EARs if it can help, of course. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1325) String property replacement is not working for constructors.
[
http://jira.jboss.com/jira/browse/JBAS-1325?page=comments#action_12314994 ]
Scott M Stark commented on JBAS-1325:
-
I don't see the usecase for allowing the type to be externalized via a system
property. Your not using this feature in the example. Is that really a desired
feature?
String property replacement is not working for constructors.
Key: JBAS-1325
URL: http://jira.jboss.com/jira/browse/JBAS-1325
Project: JBoss Application Server
Type: Feature Request
Versions: JBossAS-4.0.1 Final
Reporter: Roland Rz
Assignee: Scott M Stark
Priority: Minor
Original Estimate: 5 minutes
Remaining: 5 minutes
In the following sample of an MBean the StringPropertyReplacer is not applied
for the
values needed in the constructor.
mbean code=org.jboss.security.plugins.JaasSecurityDomain
name=jboss.security:service=JaasSecurityDomain,domain=RMI+SSL
constructor
arg type=java.lang.String value=${my.domain.name}
/
/constructor
attribute name=KeyStoreURLmyKeys.ks/attribute
attribute name=KeyStorePasstryIt/attribute
/mbean
In this sample JaasSecurityDomain would be creaded with ${my.domain.name}
as argument
instead of the corresponding SystemProperty.
The fix is very simple:
in org.jboss.system.ServiceCreator.ConstructorInfo#create (around line 287):
Element arg = (Element)list.item(j);
// String signature = arg.getAttribute(type);
String signature =
StringPropertyReplacer.replaceProperties(arg.getAttribute(type));
// String value = arg.getAttribute(value);
String value =
StringPropertyReplacer.replaceProperties(arg.getAttribute(value));
Object realValue = value;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-275) 2 identical named mdbs cannot deploy
[ http://jira.jboss.com/jira/browse/JBAS-275?page=comments#action_12315001 ] Scott M Stark commented on JBAS-275: A potential migration issue caused by this change is seen if components are accessing the ejb local homes assuming they know what the global jndi binding is. Since the global jndi binding is now essentially random, the standard ejb-jar.xml/web.xml ejb-link or a jboss.xml/jboss-web.xml local-jndi-name is required to know what jndi name to use for the local home lookup. 2 identical named mdbs cannot deploy Key: JBAS-275 URL: http://jira.jboss.com/jira/browse/JBAS-275 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 SourceForge Submitter: charris . Two MDBs, both with the same ejb-name but *in different ejb-jars*, both produce MBeans with ObjectName jboss.j2ee:jndiName=local/MyMDBEJBName,service=EJB meaning that the second MDB will not deploy properly since the MBeanServer returns InstanceAlreadyExistsException. The ObjectNames are formed with the prefix /local to produce a dummy jndi name, but need to be more unique than this to avoid the clash. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBBUILD-7) JBoss 4.0 build fails with JDK 1.5
[ http://jira.jboss.com/jira/browse/JBBUILD-7?page=history ] Scott M Stark resolved JBBUILD-7: - Resolution: Cannot Reproduce Bug Works fine for me with the current 4.0 branch. This branch is built every night with jdk 1.5 and 1.4.2 so any failure would be transient. JBoss 4.0 build fails with JDK 1.5 -- Key: JBBUILD-7 URL: http://jira.jboss.com/jira/browse/JBBUILD-7 Project: JBoss Build System Type: Bug Environment: Windows XP, Sun JDK 1.5.0 Reporter: Darran Obtained the lastest source from CVS for jboss-4.0, BRANCH_4_0. Executing the build script fails with an error: - BUILD FAILED XML parser factory has not been configured correctly: Provider org.apache.crimso n.jaxp.SAXParserFactoryImpl could not be instantiated: java.lang.NullPointerExce ption Comparing the build script with the script for jboss-head it appears that the JAXP properties have all been removed from the script. Replacing the script for jboss-4.0 with the script from jboss-head and the build completed with no errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1350) Add support for accessing the invoker proxy container state
[ http://jira.jboss.com/jira/browse/JBAS-1350?page=history ]
Scott M Stark resolved JBAS-1350:
-
Resolution: Done
In the ejb layer, an invoker-proxy-binding declares that the ejb proxies should
support the IClientContainer interface by adding a exposeContainer=true on
the client-interceptors element as shown here:
invoker-proxy-binding
namestateless-rmi-invoker/name
invoker-mbeanjboss:service=invoker,type=jrmp/invoker-mbean
proxy-factoryorg.jboss.proxy.ejb.ProxyFactory/proxy-factory
proxy-factory-config
client-interceptors exposeContainer=true
home
interceptororg.jboss.proxy.ejb.HomeInterceptor/interceptor
interceptororg.jboss.proxy.SecurityInterceptor/interceptor
interceptororg.jboss.proxy.TransactionInterceptor/interceptor
interceptor
call-by-value=falseorg.jboss.invocation.InvokerInterceptor/interceptor
interceptor
call-by-value=trueorg.jboss.invocation.MarshallingInvokerInterceptor/interceptor
/home
bean
interceptororg.jboss.proxy.ejb.StatelessSessionInterceptor/interceptor
interceptororg.jboss.proxy.SecurityInterceptor/interceptor
interceptororg.jboss.proxy.TransactionInterceptor/interceptor
interceptor
call-by-value=falseorg.jboss.invocation.InvokerInterceptor/interceptor
interceptor
call-by-value=trueorg.jboss.invocation.MarshallingInvokerInterceptor/interceptor
/bean
/client-interceptors
/proxy-factory-config
/invoker-proxy-binding
For the generic proxy factory, the org.jboss.proxy.IClientContainer needs to be
added to the proxy factory configuration:
!-- The JRMP invoker proxy configuration for the InvokerAdaptorService --
mbean code=org.jboss.invocation.jrmp.server.JRMPProxyFactory
name=jboss.jmx:type=adaptor,name=Invoker,protocol=jrmp,service=proxyFactory
!-- Use the standard JRMPInvoker from conf/jboss-service.xxml --
depends
optional-attribute-name=InvokerNamejboss:service=invoker,type=jrmp/depends
!-- The target MBean is the InvokerAdaptorService configured below --
depends
optional-attribute-name=TargetNamejboss.jmx:type=adaptor,name=Invoker/depends
!-- Where to bind the RMIAdaptor proxy --
attribute name=JndiNamejmx/invoker/RMIAdaptor/attribute
!-- The RMI compabitle MBeanServer interface --
attribute name=ExportedInterfacesorg.jboss.jmx.adaptor.rmi.RMIAdaptor,
org.jboss.jmx.adaptor.rmi.RMIAdaptorExt
/attribute
attribute name=ClientInterceptors
interceptors
interceptororg.jboss.proxy.IClientContainer/interceptor
interceptororg.jboss.proxy.ClientMethodInterceptor/interceptor
interceptororg.jboss.proxy.SecurityInterceptor/interceptor
interceptororg.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor/interceptor
interceptororg.jboss.invocation.InvokerInterceptor/interceptor
/interceptors
/attribute
/mbean
Add support for accessing the invoker proxy container state
---
Key: JBAS-1350
URL: http://jira.jboss.com/jira/browse/JBAS-1350
Project: JBoss Application Server
Type: Feature Request
Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final
Reporter: Scott M Stark
Assignee: Scott M Stark
Fix For: JBossAS-3.2.7 Final
Support for the following IClientContainer interface contract should exist in
the detached invoker proxies:
public interface IClientContainer
{
/**
* Access a copy of the proxy container interceptor stack.
* @return ArrayListorg.jboss.proxy.Interceptor
*/
public ArrayList getInterceptors();
/**
* Set the proxy container interceptor stack.
* @param interceptors - ArrayListorg.jboss.proxy.Interceptor to
* install as the new interceptor stack
*/
public void setInterceptors(ArrayList interceptors);
/**
* Access the InvocationContext associated with the proxy by the
* server side proxy factory. The contents of this will depend on
* the proxy factory.
* @return The proxy creation time InvocationContext
*/
public InvocationContext getInvocationContext();
}
This allows clients of the proxies to manipulate the proxy state in a more
dynamic manner.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1325) String property replacement is not working for constructors.
[ http://jira.jboss.com/jira/browse/JBAS-1325?page=history ]
Scott M Stark updated JBAS-1325:
type: Feature Request (was: Bug)
String property replacement is not working for constructors.
Key: JBAS-1325
URL: http://jira.jboss.com/jira/browse/JBAS-1325
Project: JBoss Application Server
Type: Feature Request
Versions: JBossAS-4.0.1 Final
Reporter: Roland Rz
Assignee: Scott M Stark
Priority: Minor
Original Estimate: 5 minutes
Remaining: 5 minutes
In the following sample of an MBean the StringPropertyReplacer is not applied
for the
values needed in the constructor.
mbean code=org.jboss.security.plugins.JaasSecurityDomain
name=jboss.security:service=JaasSecurityDomain,domain=RMI+SSL
constructor
arg type=java.lang.String value=${my.domain.name}
/
/constructor
attribute name=KeyStoreURLmyKeys.ks/attribute
attribute name=KeyStorePasstryIt/attribute
/mbean
In this sample JaasSecurityDomain would be creaded with ${my.domain.name}
as argument
instead of the corresponding SystemProperty.
The fix is very simple:
in org.jboss.system.ServiceCreator.ConstructorInfo#create (around line 287):
Element arg = (Element)list.item(j);
// String signature = arg.getAttribute(type);
String signature =
StringPropertyReplacer.replaceProperties(arg.getAttribute(type));
// String value = arg.getAttribute(value);
String value =
StringPropertyReplacer.replaceProperties(arg.getAttribute(value));
Object realValue = value;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-332) Read ahead
[ http://jira.jboss.com/jira/browse/JBAS-332?page=history ] Scott M Stark reassigned JBAS-332: -- Assign To: Alexey Loubyansky (was: Scott M Stark) Read ahead -- Key: JBAS-332 URL: http://jira.jboss.com/jira/browse/JBAS-332 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Alexey Loubyansky Priority: Critical SourceForge Submitter: morphace . Hi, apparently read-ahead is only working for 1-n relationships :-(, not for n-1. In my case I used JB3.2b3 but it is the same with 3.0.4. My OS: WinXP, JDK 1.4.1_01 Yes, I have the CMP docs ... ;-) Here my standardjbosscmp-jdbc.xml settings: read-ahead strategyon-find/strategy page-size500/page-size eager-load-group*/eager-load-group /read-ahead list-cache-max1000/list-cache-max I use commit-option B, instance per transaction configuration for my CMP EJB's. I looked at the code, and (I hope that I am right) it's clear that it does not work, because the read-ahead mechanism relies on the collection of primary keys (not foreign keys). I feel, that it could be (easily ;-)) done by collecting the foreign keys too and due to the fact that the current behavior has grave performance loss I submit it as bug. Is it okay ? TX Markus -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-43) security.test.SecurityProxyUnitTestCase failure
[ http://jira.jboss.com/jira/browse/JBAS-43?page=history ] Scott M Stark resolved JBAS-43: --- Resolution: Done Fix Version: JBossAS-3.2.7 Final Basic Subject.doAs support was added to get past the current jdk1.3 limitations. Proper support of the JAAS authorization mechanism still requires jdk 1.4+. security.test.SecurityProxyUnitTestCase failure --- Key: JBAS-43 URL: http://jira.jboss.com/jira/browse/JBAS-43 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.7 Final Environment: [EMAIL PROTECTED] case2471]$ $JAVA_HOME/bin/java -version java version 1.3.1_14 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_14-b03) Java HotSpot(TM) Client VM (build 1.3.1_14-b03, mixed mode) Reporter: Scott M Stark Assignee: Scott M Stark Priority: Minor Fix For: JBossAS-3.2.7 Final The org.jboss.test.security.test.SecurityProxyUnitTestCase fails due to the unsupported Subject.doAsPrivileged call. The jboss-jaas.jar implementation only addresses the jaas 1.0 extension problems with class loading of login modules. It does not provide a full Subject implementation and this will not be fixed for 3.2.7. This test would have to run with the server configured to use the 1.0 jaas.jar extension release, and either the jboss LoginContext related classes in the extension classpath, or the login modules in the extension classpath. testcase classname=org.jboss.test.security.test.SecurityProxyUnitTestCase name=testMethodAccess time=0.296 error message=RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: RuntimeException; nested exception is: java.lang.UnsupportedOperationException: doAsPrivileged is not supported by this version of JAAS 1.0, use the JDK 1.4 version type=java.rmi.ServerExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: RuntimeException; nested exception is: java.lang.UnsupportedOperationException: doAsPrivileged is not supported by this version of JAAS 1.0, use the JDK 1.4 version java.rmi.ServerException: RuntimeException; nested exception is: java.lang.UnsupportedOperationException: doAsPrivileged is not supported by this version of JAAS 1.0, use the JDK 1.4 version java.lang.UnsupportedOperationException: doAsPrivileged is not supported by this version of JAAS 1.0, use the JDK 1.4 version at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:240) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:117) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:135) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:96) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:91) at $Proxy2.read(Unknown Source) at org.jboss.test.security.test.SecurityProxyUnitTestCase.testMethodAccess(SecurityProxyUnitTestCase.java:71) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) /error /testcase -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1104) batchInvalidate async not possible
[ http://jira.jboss.com/jira/browse/JBAS-1104?page=history ] Scott M Stark resolved JBAS-1104: - Resolution: Done Fix Version: JBossAS-3.2.7 Final JBossAS-4.0.2RC1 JBossAS-5.0 Alpha The default batch mode has been externalized and batchInvalidate fixed to honor the asynchronous parameter. batchInvalidate async not possible -- Key: JBAS-1104 URL: http://jira.jboss.com/jira/browse/JBAS-1104 Project: JBoss Application Server Type: Bug Components: Clustering Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1, JBossAS-5.0 Alpha SourceForge Submitter: davidmboon . InvalidationManager has a bug in org.jboss.cache.invalidation.InvalidationManager The batchInvalidate() methods always execute as synchronous. This means if we connect to the InvalidationManager and invoke batchInvalidate(invalidations, true) it won't be async. I have attached a version of the InvalidationManager that allows you to set the async attribute via an mbean attribute. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-919) Problem using oracle-sequence key generation
[ http://jira.jboss.com/jira/browse/JBAS-919?page=history ]
Scott M Stark reassigned JBAS-919:
--
Assign To: Alexey Loubyansky (was: Scott M Stark)
Problem using oracle-sequence key generation
Key: JBAS-919
URL: http://jira.jboss.com/jira/browse/JBAS-919
Project: JBoss Application Server
Type: Bug
Components: CMP service
Versions: JBossAS-3.2.6 Final
Reporter: SourceForge User
Assignee: Alexey Loubyansky
SourceForge Submitter: jeeads .
OS client Window XP
server Windows Server 2000
Database Oracle 8i
JBoss 3.2.3 production release
JDK Version 1.4.3
I have created some entity beans that have non nullable
foreign keys and when I go to test them I find an
interesting problem. To test these beans I must create
or find an existing bean for the instatiation of the non
nullable foreign key. No matter if I create or find the
foreign key prior to creating the bean to test, when
creating the bean to test the
org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCOracleCreateC
ommand doesn't get called? Here is the print out of the
problem. All bean transactions are marked required.
Error using lanehome.create to initialize the non nullable
foreign key for the bases bean
Initializing testBasesBean.
2004-03-26 13:04:13,281 DEBUG
[org.jboss.ejb.plugins.LogInterceptor] InvokeHome:
create(471582173,4]]J,32526,32526,
[EMAIL PROTECTED],YYYDDD;;;NNN444tttGGG===
HHH111WWWTTTppp666RRR
[[[QQQ===333P```222UUUKKKggg]]]???
\\\RRR555aaaWWWtttiii222111rrr^^^
[[[666===444555tttGGG===TTTAAA666IIITTT
TAAA777SSSIII000CCC888UUUMM?
NkkkaaaMMMCCCpppf,-16268,-
1279147916,f999xxxKKKAAAmmm000VVVCCCU
UULLLMMMCCCLLL999222OOO111XXXOOOFFFb
bbbXXXEEE;;;[[[QZZZGGGeee
[[[===DDDTTTCCCooofff999xxxZZZmmmcccO
OOMMMrrryyy:::CCCyyyoooBBBYYY44411
1rrrOOO111NNNWWWccc999EEEjjjaaaL
LLCCCV,-22018,1888135678,Sat Apr 17 10:33:03 CDT
2004,Sat Apr 17 11:56:25 CDT 2004,Sat Apr 17
11:56:25 CDT 2004,Sat Apr 17 11:56:25 CDT
2004,12186,12186,12186,7785,7785,7785,OOOvvvm
mm666EEEXXXyyyooo
[[[dddoooBBB888ddd;;;111:::MMMCCC^^
^UUU777JJJZZZFFFYYYOOOWWWDDDLL
LCCC000???
QQQ555FFFYYYOOOKKK^^^QQQG
GGdddBBBQQQnnndddqqqDDDSSSpppNNND
DDpppggg333PPP___2GGGDDDPppp,222RRR66
6uuu444
[[[===XXXOOO;;;^^^UUU@@@777IIIeee
[[[TTTaaa666]]]
UUUhhh^^^JJJ```WWWttt999```444PPP``
`sssIII???SSS555@@@]]]SSS
555222BBB___AAA7___\\\777;;;111M
MMCCCBBB^^^TTTAAAmmmcccaaaC,1,-
1824321783,-1824321783,CaaaWWWttt999VVV,Fri Mar
05 02:24:17 CST 2004,Fri Mar 05 04:06:53 CST 2004,Fri
Mar 05 04:06:53 CST
2004,McccoooEEEXXXccc666vvvOOOoooeee88
8ddd
[[[___UUU777NNN;;;CCC:::UUUKKKww
wJJJ@@@===OOOFFF222:::NNNCCCVVV666SS
SSIII555[[[HHHvvvXXXOOOeee888GGG
[[[888yyyddd[[[qqq;;;JJJggg
DDD;;;XXXgggtttGGG===sss,ZZZPPP:::M
MM]]]III@@@
RRR444ZZZGGGYYYOOOUUULLLTTTAAA66
6SSI5
[[[NNNkkk000MMM___UUU^^^TTTjjj===4
44iii444GGG===sss666SSSbbblllSSSIII666
HHHBBBUUULLLxxxKKUUU\\\888
[[[XXXNNNkkk000BBBUUUKKK777JJJZZZ
a,null,null,null)
2004-03-26 13:04:13,281 DEBUG
[com.genecodes.oracle8iseqcol.lane.LaneBean]
setEntityContext
2004-03-26 13:04:13,359 DEBUG
[com.genecodes.oracle8iseqcol.lane.LaneBean]
ejbCreate
2004-03-26 13:04:13,375 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.keygen.JDBCOracleCreate
Command.Oracle8iSeqCol_Lane] Executing SQL: {call
INSERT INTO LANE (ID, LANE_TYPE,
APPLICATION_CREATOR, AUTO_ANALYSIS, AUTO_PRINT,
LAST_USED, NAME, LANE_NUMBER, STATUS,
THUMBPRINT, PRIMER_POSITION,
RAW_DATA_START_POINT, START_EP, END_EP,
START_EP_ANALYSIS, END_EP_ANALYSIS,
INITIAL_SCAN_START, INITIAL_SCAN_END,
LAST_SCAN_START, LAST_SCAN_END,
CUSTOM_SCAN_START, CUSTOM_SCAN_END,
START_COMMENT, STOP_COMMENT,
ADAPTIVE_WORKED, AVERAGE_SPACING,
CALCULATED_SPACING, ANALYSIS_VERSION,
DATE_UPLOADED, SAMPLE_CREATION,
SAMPLE_MODIFICATION, COLLECTION_SIZE_STD_NAME,
COLLECTION_ANALYSIS_PARMS_NAME, SAMPLE_ID,
SIGNAL_PROCESS_ID, RUN_ID) VALUES
(LaneSeq.NEXTVAL, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
RETURNING ID INTO ? }
2004-03-26 13:04:13,515 DEBUG
[com.genecodes.oracle8iseqcol.lane.LaneBean]
ejbPostCreate
2004-03-26 13:04:18,671 DEBUG
[org.jboss.ejb.plugins.LogInterceptor] InvokeHome:
create(O?
88UUULLL777___UUUSSSxxx555,5AAA111XXXCCC
MMMXXX___UUU777===444GGGYYYOOOWWW
DDDVVVMMMfff]]]???
\\\QQQmmmFFFYYYiiiKKKRRR^^^ppp999
eee222rrrTTT```rrrEEETTTqqqZZZQQQ===
333444;;;FFFPPP@@@666RRR555@@
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-944) Empty JNDI 'java:' tree w/servlet 2.3 web container first
[ http://jira.jboss.com/jira/browse/JBAS-944?page=history ] Scott M Stark closed JBAS-944: -- Resolution: Out of Date Empty JNDI 'java:' tree w/servlet 2.3 web container first - Key: JBAS-944 URL: http://jira.jboss.com/jira/browse/JBAS-944 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: pjaromin . OS: Solaris 9 JDK: HotSpot 1.4.2 SE (build 1.4.2-b28, mixed mode) Using a clean install of JBoss 3.2.3 (November 2003), install both webapps - test1.war and test2.war - in the 'deploy' directory. Visit test1 - http://localhost:8080/test1/jndi.do The web page output should look like: -- CHILDREN of java: NAME: XAConnectionFactory TYPE: org.jboss.mq.SpyXAConnectionFactory NAME: DefaultDS TYPE: org.jboss.resource.adapter.jdbc.WrapperDataSource NAME: SecurityProxyFactory TYPE: org.jboss.security.SubjectSecurityProxyFactory NAME: DefaultJMSProvider TYPE: org.jboss.jms.jndi.JBossMQProvider NAME: comp TYPE: javax.naming.Context NAME: ConnectionFactory TYPE: org.jboss.mq.SpyConnectionFactory NAME: JmsXA TYPE: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl NAME: jaas TYPE: javax.naming.Context NAME: timedCacheFactory TYPE: javax.naming.Context NAME: TransactionPropagationContextExporter TYPE: org.jboss.tm.TransactionPropagationContextFactory NAME: Mail TYPE: javax.mail.Session NAME: StdJMSPool TYPE: org.jboss.jms.asf.StdServerSessionPoolFactory NAME: TransactionPropagationContextImporter TYPE: org.jboss.tm.TransactionPropagationContextImporter NAME: TransactionManager TYPE: org.jboss.tm.TxManager -- Next, visit http://localhost:8080/test2/index.do By default, using the JBoss Classloader and Java2 compliance in tomcat, you will receive an error - 'java.lang.NoSuchMethodError: test.webui.actions.UserInfo.getCount2()I' - when attempting to view test2/index.do since there is an incompatible version of the same class loaded in test1. Edit the file default/deploy/jbossweb-tomcat41.sar/META-INF/jboss-service.xml and change the following attributes to false: attribute name=Java2ClassLoadingCompliancetrue/attribute attribute name=UseJBossWebLoadertrue/attribute ...next, either remove the management app or edit web-console.war/WEB-INF/jboss-web.xml and add class-loading java2ClassLoadingCompliance='true'/ Now, restart the app server. (run.sh -c default). You should be able to visit both web apps without error this time, however, the output will list no children of java: in the InitialContext: http://localhost:8080/test1/jndi.do http://localhost:8080/test2/index.do OUTPUT of http://localhost:8080/test1/jndi.do -- CHILDREN of java: -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-71) Problem returning a Remote Interface from Business method Using IIOP with EJB on jboss-3.2.5
[ http://jira.jboss.com/jira/browse/JBAS-71?page=history ]
Scott M Stark resolved JBAS-71:
---
Resolution: Deferred
A number of fixes in the iiop layer have been ported to 3.2.7 from 4.0.1 so
retry with that and provide a testcase if there continues to be a problem.
Problem returning a Remote Interface from Business method Using IIOP with EJB
on jboss-3.2.5
Key: JBAS-71
URL: http://jira.jboss.com/jira/browse/JBAS-71
Project: JBoss Application Server
Type: Bug
Components: EJBs
Versions: JBossAS-3.2.5 Final
Environment: Windows XP, JDK 1.4.2_04
Reporter: Millin Parikh
Assignee: Scott M Stark
Original Estimate: 2 days
Remaining: 2 days
I am using IIOP and my bean type is Statefull Beans. All Descriptors are set
properly.
Process Desctiption:
Followint in my beans business method which returns a(IRemote) Interface
which extended from Remote Interface.This new interface is Implemented By my
RMI class(RemoteImpl) extending PortableRemoteObject.
Problem Method:
public IRemote callme() throws RemoteException
{
RemoteImpl remoteimpl=new RemoteImpl(?program?);
return (IRemote) remoteimpl;
}
Above Business Method Throws server side error as Follows:
15:32:33,470 INFO [JkMain] Jk running ID=0 time=0/330 config=null
15:34:15,310 ERROR [jacorb]org.omg.CORBA.portable.UnknownException: vmcid:
0x0 minor code: 0 completed:
Maybe
at
org.jboss.iiop.rmi.marshal.strategy.SkeletonStrategy.writeException(SkeletonStrategy.java:164)
at
org.jboss.proxy.ejb.EjbObjectCorbaServant._invoke(EjbObjectCorbaServant.java:236)
at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
at org.jacorb.poa.RequestProcessor.process(Unknown Source)
at org.jacorb.poa.RequestProcessor.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-546) web-console applet doesn't work on linux browsers
[ http://jira.jboss.com/jira/browse/JBAS-546?page=history ] Scott M Stark resolved JBAS-546: Resolution: Cannot Reproduce Bug Works fine for me as well using jre 1.4.2_05. web-console applet doesn't work on linux browsers - Key: JBAS-546 URL: http://jira.jboss.com/jira/browse/JBAS-546 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: stefanf . It seems that the tree applet on the right side of the web-console web page doesn't work in linux web browsers. I've tried this in Konqueror, Opera and Mozilla and none of them work. Here's a stack trace of the error that occurs: Java VM version: 1.4.1_01 Java VM vendor: Sun Microsystems Inc. http://dev:8080/web-console/Invoker java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:542) at java.lang.Thread.getContextClassLoader(Thread.java:1189) at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:84) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78) at org.jboss.console.remote.Util.invoke(Util.java:77) at org.jboss.console.remote.AppletRemoteMBeanInvoker.invoke(AppletRemoteMBeanInvoker.java:50) at org.jboss.console.navtree.ConsoleTreeModel.loadTree(ConsoleTreeModel.java:104) at org.jboss.console.navtree.ConsoleTreeModel.init(ConsoleTreeModel.java:59) at org.jboss.console.navtree.AdminTreeBrowser.init(AdminTreeBrowser.java:63) at org.jboss.console.navtree.AppletBrowser.start(AppletBrowser.java:51) at org.kde.kjas.server.KJASAppletStub.startApplet(KJASAppletStub.java:254) at org.kde.kjas.server.KJASAppletContext.startApplet(KJASAppletContext.java:200) at org.kde.kjas.server.KJASProtocolHandler.processCommand(KJASProtocolHandler.java:207) at org.kde.kjas.server.KJASProtocolHandler.commandLoop(KJASProtocolHandler.java:86) at org.kde.kjas.server.Main.main(Main.java:178) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-421) Jboss CMR extra column name problem
[ http://jira.jboss.com/jira/browse/JBAS-421?page=history ] Scott M Stark reassigned JBAS-421: -- Assign To: Alexey Loubyansky (was: Scott M Stark) Jboss CMR extra column name problem Key: JBAS-421 URL: http://jira.jboss.com/jira/browse/JBAS-421 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Alexey Loubyansky Priority: Minor SourceForge Submitter: dheeraj_s . Hi : I have a very simple relationship. UserBean Login This is 1:1 relationship. I am trying to load UserBean from LoginBean. At the database level It is Login.UserId [FK] = User.Id In LoginBean I have setUserBean and getUserBean methods. I have written a EJB-QL, Where I fecth the Object of LoginBean. It compiles and installs very decently. However, when I try to invoke the EJB-QL. I get the following error in the log file. select id,username.,userBean from Login where username = ? and password = ? This is a wrong SQL as there is no userBean in the Login Table. I tried to use this in Jboss3.0.x plus on jboss3.2.0 with Tomcat. Can someone please explain, why Jboss is creating a worng SQL. Cheers Dheeraj -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1224) Make the JBoss server runnable from a read-only partition
[ http://jira.jboss.com/jira/browse/JBAS-1224?page=history ]
Scott M Stark resolved JBAS-1224:
-
Resolution: Done
This is already supported using the system properties that control the log dir
in the log4j.xml, data dir and tmp dir. See the admin guide for how the jboss
dist can be split up into different paths.
Make the JBoss server runnable from a read-only partition
-
Key: JBAS-1224
URL: http://jira.jboss.com/jira/browse/JBAS-1224
Project: JBoss Application Server
Type: Feature Request
Versions: JBossAS-3.2.6 Final
Reporter: SourceForge User
Assignee: Scott M Stark
SourceForge Submitter: didickman .
In an enterprise setting, JBoss would be installed
as /opt/jboss-3.2.x which would be a read-only area.
The problem with the current setup of JBoss is that it
expects to be able to write to /opt/jboss-3.2.x/server/
{all,default,minimal}. Making JBoss instances easily
accessible from a different area than /opt/jboss-
3.2.x/server/ is important in this environment and would
be a very useful improvement.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-489) Cannot startup jbossweb-jetty without javax.ejb.*
[ http://jira.jboss.com/jira/browse/JBAS-489?page=history ] Scott M Stark closed JBAS-489: -- Resolution: Out of Date Jetty is history. Cannot startup jbossweb-jetty without javax.ejb.* - Key: JBAS-489 URL: http://jira.jboss.com/jira/browse/JBAS-489 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: starksm . I'm testing a minimal web container configuration for netbooting and I'm seeing that the jbossweb-jetty.sar will not startup due to a linkage dependency on the javax.ejb.* classes. This most likely is coming from the distributed session stuff, but this should not cause the server to fail to startup. The configuration consists of the minimal/conf/jboss-service.xml descriptor and the following lib and deploy content: [EMAIL PROTECTED] JBoss]$ ls jboss-3.2.0/server/netboot/lib/ javax.servlet.jar jboss.jar jnpserver.jar log4j.jar [EMAIL PROTECTED] JBoss]$ ls jboss-3.2.0/server/netboot/deploy/ jbossweb-jetty.sar See the attached stack trace for the startup error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-555) java:comp not bound when java2ClassLoadingCompliance false
[ http://jira.jboss.com/jira/browse/JBAS-555?page=history ] Scott M Stark closed JBAS-555: -- Resolution: Out of Date java:comp not bound when java2ClassLoadingCompliance false -- Key: JBAS-555 URL: http://jira.jboss.com/jira/browse/JBAS-555 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: bonhamcm . Tested in both JBoss 3.2.0RC4 Tomcat 4.1.18 and JBoss 3.2.2beta Tomcat 4.1.24, Win2K, Sun JDK 1.4.1_02. When java2ClassLoadingCompliance is set to false in jboss-web.xml, the java:comp context cannot be accessed. It appears that that the ENC context is loaded by the FactoryURLClassLoader before the application has read the jboss-web.xml file to see that it should actually be loaded by the WebAppClassLoader since java2ClassLoadingCompliance is false. javax.naming.NameNotFoundException: comp not bound at org.jnp.server.NamingServer.getBinding (NamingServer.java:495) at org.jnp.server.NamingServer.getBinding (NamingServer.java:503) at org.jnp.server.NamingServer.getObject (NamingServer.java:509) at org.jnp.server.NamingServer.lookup (NamingServer.java:253) at org.jnp.interfaces.NamingContext.lookup (NamingContext.java:500) at org.jnp.interfaces.NamingContext.lookup (NamingContext.java:479) at javax.naming.InitialContext.lookup (InitialContext.java:347) at org.jboss.test.classloader.scoping.override.web.log4j113. ENCServlet.processRequest(ENCServlet.java:56) at org.jboss.test.classloader.scoping.override.web.log4j113. ENCServlet.doGet(ENCServlet.java:35) at javax.servlet.http.HttpServlet.service (HttpServlet.java:740) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalD oFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.CertificatesValve.invoke (CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke (StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:509) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipe lineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service (CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:594) at org.apache.coyote.http11.Http11Protocol$Http11Connect
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-785) Ear deploy breaks on windows 2000 if Filename too big
[ http://jira.jboss.com/jira/browse/JBAS-785?page=history ] Scott M Stark closed JBAS-785: -- Resolution: Won't Fix Its a win32 limitation for which no configuration workaround has been found. Ear deploy breaks on windows 2000 if Filename too big - Key: JBAS-785 URL: http://jira.jboss.com/jira/browse/JBAS-785 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: erdeni . I am working on windows 2000, jdk1.4.1_05 My ear deployment fails on windows 2000 (No problem on linux redhat 8). if the size of the filename inside the war is too big or if a class contains inner classes. It started happenning with the final release of 3.2.2 (I think it was fine with its RC's) I have tried 3.2.3RC1 it has the same problem 2003-11-13 15:47:08,931 INFO [org.jboss.deployment.EARDeployer] Init J2EE application: file:/C:/data/jboss/jboss- 3.2.3RC1/server/default/deploy/myapp.ear 2003-11-13 15:47:35,165 ERROR [org.jboss.web.tomcat.tc4.EmbeddedTomcatService] Problem in init java.io.FileNotFoundException: C:\data\jboss\jboss- 3.2.3RC1\server\default\tmp\deploy\tmp53007myapp.ear- contents\myapp-web.war\WEB- INF\classes\FailedFile.class (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init (FileOutputStream.java:176) at java.io.FileOutputStream.init (FileOutputStream.java:131) at org.jboss.util.file.JarUtils.unjar (JarUtils.java:277) at org.jboss.web.AbstractWebContainer.init (AbstractWebContainer.java:301) at org.jboss.deployment.MainDeployer.init (MainDeployer.java:696) at org.jboss.deployment.MainDeployer.init (MainDeployer.java:716) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:632) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor41.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymentScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentScanner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann er$ScannerThread.doScan (AbstractDeploymentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScann er.startService(AbstractDeploymentScanner.java:274) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:192) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:976) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:589) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-517) Java libraries not found when JBoss is run as NT service
[ http://jira.jboss.com/jira/browse/JBAS-517?page=history ] Scott M Stark resolved JBAS-517: Resolution: Won't Fix Java libraries not found when JBoss is run as NT service Key: JBAS-517 URL: http://jira.jboss.com/jira/browse/JBAS-517 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: vladchuk . JBoss version: 3.2.1 OS: Windows2000 Server SP3, WindowsXP Professional JDK: 1.4.1_02 When attempted to run as NT service using the command file provided in FAQ forum and javaservice.exe as service launcher JBoss invariably fails as follows: (this is the full content of the boot.log): java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/ConcurrentReaderHas hMap Please see the attached file for full stack trace. The 3.0.x version did not have this problem and every 3.2.x (including beta releases) exibited this behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-872) Problem with non-English characters in UTF-8 encoded queries
[ http://jira.jboss.com/jira/browse/JBAS-872?page=history ] Scott M Stark reassigned JBAS-872: -- Assign To: Alexey Loubyansky (was: Scott M Stark) Problem with non-English characters in UTF-8 encoded queries Key: JBAS-872 URL: http://jira.jboss.com/jira/browse/JBAS-872 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Alexey Loubyansky SourceForge Submitter: azzazzel . I'm resubmitting this issue since the the last time I did (see #887491) it was understood wrong, closed and marked as invalid by loubyansky without even making the effort to clarify it. Initial Comment (see #887491 for full text): It seems that all characters coded with more than one byte (2+ bytes) in UTF-8 encoded queries are incorrectly parsed by [EJB/JBoss]QLParser as seen in this log fragment: [...] If I pass parameter like '\u0105' instead of '' then it works. [...] Comment By: Alexey Loubyansky (loubyansky): Why is '#261' supposed to be understood? Either you provide unicode content as is (not the '#261' form) or you use unicode escapes as defined in the Java spec, i.e. '\u'. I very well know that #261 is not supposed to be understood! What I have typed in the TEXTAREA was character with Unicode code \u0105 also called LATIN SMALL LETTER A WITH OGONEK I guess it was converted to #261 by SF and I haven't even noticed it was! I bet if you type Russian characters in TEXTAREA they would also be displayed in #XXX; form. This subject was discussed previously on JBoss-user list and Alexey Loubyansky was also answering my e-mails there. (See: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg35226.html) I have also contacted Alexey Loubyansky and Dain Sundstrom since they are mentioned to be the authors of JBossQLParser.jjt and EJBQLParser.jjt. Alexey didn't answer, while Dain stated he does not work for JBoss any more. I was asked to open a bug report by Heiko Rupp on jboss-user list! Now once again to make it clear: I do not enter in my queries characters in the form #261 but naturally in UTF-8 encoding (as they are typed)! It does not work! It is incorrectly parsed! I believe it is because parser expects 1 byte long character (\u0105 has two bytes in UTF-8). As I said before setting JAVA_UNICODE_ESCAPE = false in JBossQLParser.jjt and EJBQLParser.jjt solves the problem! More specifically it causes that parser understands UTF-8 but does not understand Unicode escaped characters (in the form \u). I don't know how to set it in order to understand both! Can I please ask you, to have another look on this! Please contact me if you need more information on this subject! Milen Dyankov -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1303) Field replication for session data
[ http://jira.jboss.com/jira/browse/JBAS-1303?page=history ] Scott M Stark reassigned JBAS-1303: --- Assign To: Ben Wang (was: Scott M Stark) Field replication for session data -- Key: JBAS-1303 URL: http://jira.jboss.com/jira/browse/JBAS-1303 Project: JBoss Application Server Type: Feature Request Components: Web (Tomcat) service, EJBs, JBoss Cache service Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Reporter: Andrew Oliver Assignee: Ben Wang Original Estimate: 4 days Remaining: 4 days We should have an AOP-ized fine grained session replication system. Meaning if I stick a pojo into the session it should optionally break apart to its state and replicate accross the cluster through the deep object graph. Same deal for SFSBs. Thus Customer cust = new Customer(); cust.setName(George W. Bush); cust.setAddress(123 Don't call it Waco TX); cust.setCity(Craford); cust.setState(TX); session.setAttribute(customer,cust); cust.setAddress(1600 PA Ave); cust.setCity(Washington); cust.setState(DC); should only replicate address/city/state and not serialize the whole object -- I should not have to call set Attribute(). Furthermore if Address had been a setter on customer and I only changed street then only street would replicate. Lastly, it should be optional to transactionalize these for the scope of the replication (meaning I could say I really do want these transactional so that I send one message and not 3). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-940) Unecessary alias in SQL
[ http://jira.jboss.com/jira/browse/JBAS-940?page=history ] Scott M Stark reassigned JBAS-940: -- Assign To: Alexey Loubyansky (was: Scott M Stark) Unecessary alias in SQL --- Key: JBAS-940 URL: http://jira.jboss.com/jira/browse/JBAS-940 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Alexey Loubyansky Priority: Optional SourceForge Submitter: waggj . I am testing moving from 3.2.1 to 3.2.4 and have run into a problem involving use of aliases. 3.2.4 differs from 3.2.1 in that the sql generated for loading entity beans includes use of an alias which defaults to the table name with an additional id prepended. This is a problem to us because we use (at times) an informix 7.X database which only allows 18 characters for an identifier in SQL. We also have a table with a 16 character table name. So any use of this table (with the default settings) causes an exception. We can work round this because the maximum alias length can be set in standardjbosscmp-jdbc.xml to a small value and it all works. However, I believe this is a bug because I cannot understand why the use of the alias is necessary at all. Aliases in sql are really only necessary when joining tables to distinguish between columns with the same name in different tables. An entity bean would not normally include data from more than one table and so should not normally need an alias. We are running JBoss 3.2.1 and 3.2.4 on Windows XP using jdk 1.4.2_03 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-220) EJQQL row locking (FOR UPDATE request)
[ http://jira.jboss.com/jira/browse/JBAS-220?page=history ] Scott M Stark reassigned JBAS-220: -- Assign To: Alexey Loubyansky (was: Scott M Stark) EJQQL row locking (FOR UPDATE request) -- Key: JBAS-220 URL: http://jira.jboss.com/jira/browse/JBAS-220 Project: JBoss Application Server Type: Feature Request Components: CMP service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Alexey Loubyansky SourceForge Submitter: attachvishal . lets assume there are 3 entity beans (A,B,C) and all of them defined /row-locking as true. there is a cmr relationship between A and B and also A and C. If i write ejbql to look for Object(C) something like this SELECT OBJECT(C) FROM cnCustomerSchema A, IN (A.addressDetails) B , IN(A.phoneDetails) C WHERE A.cnCustomer = ?1 and B.current_Flg ='F' and B.occupied_Flg ='T' and B.cnAddress_Type = ?2 if i add FOR UPDATE at this end of this ejbql the ql will not get parsed . i think we should have provision to define FOR UPDATE in ejbQL? I know this will not be allowed here as it will not be valid query but we should be allowed to add FOR UPDATE to single table -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-577) No getter or setters found for idleThreads
[ http://jira.jboss.com/jira/browse/JBAS-577?page=history ] Scott M Stark closed JBAS-577: -- Resolution: Out of Date No getter or setters found for idleThreads -- Key: JBAS-577 URL: http://jira.jboss.com/jira/browse/JBAS-577 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark SourceForge Submitter: vardaru . I am trying to run JBoss-3.2.1 on my machine (winxp pro, jdk1.4.1_02 + turkish locale). I got the following error. When I change the locale to english It just disapears. Umit VARDAR ps. there are some case conversions in the code (in the file org.mortbay.util.jmx.ModelMBeanImpl.java). Usually this leads to such problems when the developer meant to make case conversion in Locale.US but didn't mention it in the methods like String.toUpperCase() etc. ps. In turkish locale i.toUpperCase is different than the I . ... 2003-06-07 15:46:12,076 WARN [org.jboss.jbossweb] WARNING: java.lang.IllegalArgumentException: No getter or setters found for idleThreads at org.mortbay.util.jmx.ModelMBeanImpl.defineAttribute (ModelMBeanImpl.java:398) at org.mortbay.util.jmx.ModelMBeanImpl.defineAttribute (ModelMBeanImpl.java:310) at org.mortbay.util.jmx.ThreadPoolMBean.defineManagedRes ource(ThreadPoolMBean.java:42) at org.mortbay.util.jmx.ThreadedServerMBean.defineManage dResource(ThreadedServerMBean.java:36) at org.mortbay.http.jmx.HttpListenerMBean.defineManagedR esource(HttpListenerMBean.java:31) at org.mortbay.http.jmx.SocketListenerMBean.defineManage dResource(SocketListenerMBean.java:32) at org.mortbay.util.jmx.ModelMBeanImpl.setManagedResourc e(ModelMBeanImpl.java:273) at org.mortbay.util.jmx.ModelMBeanImpl.mbeanFor (ModelMBeanImpl.java:155) at org.mortbay.http.jmx.HttpServerMBean.addComponent (HttpServerMBean.java:125) at org.mortbay.http.HttpServer.addComponent (HttpServer.java:1248) at org.mortbay.http.HttpServer.addListener (HttpServer.java:250) ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-363) FileURLConnection needs URL decode for JDK 1.4
[ http://jira.jboss.com/jira/browse/JBAS-363?page=history ]
Scott M Stark resolved JBAS-363:
Resolution: Done
Fix Version: JBossAS-3.2.7 Final
Support has been added to decode the path if the
org.jboss.net.protocol.file.decodeFilePaths is set to true. This is false by
default as I don't see any encoding problems when running with jboss in a path
with spaces. I would like to see how to reproduce the problem before making
this true by default.
FileURLConnection needs URL decode for JDK 1.4
--
Key: JBAS-363
URL: http://jira.jboss.com/jira/browse/JBAS-363
Project: JBoss Application Server
Type: Bug
Versions: JBossAS-3.2.6 Final
Reporter: SourceForge User
Assignee: Scott M Stark
Fix For: JBossAS-3.2.7 Final
SourceForge Submitter: andieveritt .
In the constructor of
org.jboss.net.protocol.file.FileURLConnection a new
File is created from the supplied URL. In JDK 1.4 the
result of URL.getPath() is URL encoded which means on
windows with a path with a space you get
'C:\Program%20Files\foo\bar' - which doesn't work.
I have tested a modified version of FileURLConnection
which URL decodes the result. This resolves the issue.
I have attached the modified version. The only change
is on Line 45:
- file = new File(url.getPath().replace('/',
File.separatorChar).replace('|', ':'));
+ file = new
File(java.net.URLDecoder.decode(url.getPath()).replace('/',
File.separatorChar).replace('|', ':'));
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-714) Automatically include everything in jboss/lib to classpath
[ http://jira.jboss.com/jira/browse/JBAS-714?page=history ] Scott M Stark resolved JBAS-714: Resolution: Done Fix Version: JBossAS-3.2.7 Final JBossAS-4.0.2RC1 This functionality is available using the --bootdir option. Automatically include everything in jboss/lib to classpath -- Key: JBAS-714 URL: http://jira.jboss.com/jira/browse/JBAS-714 Project: JBoss Application Server Type: Feature Request Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 SourceForge Submitter: rmcauble . This is a convenience to as not to have to explictly list out each jar in jboss/lib. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1328) Tack where UCLs are destroyed to throw a better exception than NPE
Tack where UCLs are destroyed to throw a better exception than NPE -- Key: JBAS-1328 URL: http://jira.jboss.com/jira/browse/JBAS-1328 Project: JBoss Application Server Type: Task Components: JMX Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Reporter: Scott M Stark Assigned to: Scott M Stark Priority: Minor Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 When a redeployment is done and references to a UCL class loader from the previous deployment exist, any attempt to use the UCL results in a NullPointerException because the association between the UCL and its repository have been cleared. A standard ClassNotFoundException with the trace of where the UCL was unregistered would be a better choice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1328) Tack where UCLs are destroyed to throw a better exception than NPE
[ http://jira.jboss.com/jira/browse/JBAS-1328?page=history ] Scott M Stark resolved JBAS-1328: - Resolution: Done Tack where UCLs are destroyed to throw a better exception than NPE -- Key: JBAS-1328 URL: http://jira.jboss.com/jira/browse/JBAS-1328 Project: JBoss Application Server Type: Task Components: JMX Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final Reporter: Scott M Stark Assignee: Scott M Stark Priority: Minor Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 When a redeployment is done and references to a UCL class loader from the previous deployment exist, any attempt to use the UCL results in a NullPointerException because the association between the UCL and its repository have been cleared. A standard ClassNotFoundException with the trace of where the UCL was unregistered would be a better choice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-275) 2 identical named mdbs cannot deploy
[ http://jira.jboss.com/jira/browse/JBAS-275?page=history ] Scott M Stark resolved JBAS-275: Resolution: Done Fix Version: JBossAS-3.2.7 Final JBossAS-4.0.2RC1 The generated local name now includes an identity hash component to unique the name. 2 identical named mdbs cannot deploy Key: JBAS-275 URL: http://jira.jboss.com/jira/browse/JBAS-275 Project: JBoss Application Server Type: Bug Versions: JBossAS-3.2.6 Final Reporter: SourceForge User Assignee: Scott M Stark Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1 SourceForge Submitter: charris . Two MDBs, both with the same ejb-name but *in different ejb-jars*, both produce MBeans with ObjectName jboss.j2ee:jndiName=local/MyMDBEJBName,service=EJB meaning that the second MDB will not deploy properly since the MBeanServer returns InstanceAlreadyExistsException. The ObjectNames are formed with the prefix /local to produce a dummy jndi name, but need to be more unique than this to avoid the clash. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1320) Security Hole Created by MDB Deployment
[ http://jira.jboss.com/jira/browse/JBAS-1320?page=history ] Scott M Stark resolved JBAS-1320: - Resolution: Done Fix Version: JBossAS-4.0.2RC1 JBossPOJOServer-1.0 Alpha The security context created by the JMSContainerInvoker is now cleared as well. Security Hole Created by MDB Deployment --- Key: JBAS-1320 URL: http://jira.jboss.com/jira/browse/JBAS-1320 Project: JBoss Application Server Type: Bug Components: Security Versions: JBossAS-3.2.6 Final Reporter: eugene75 Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-3.2.7 Final, JBossAS-4.0.2RC1, JBossPOJOServer-1.0 Alpha During the deployment of a message driven bean, the container creates a connection to the message queue using the user/pwd provided by the deployment descriptor. The authenticated subject created by this operation is bound to the current thread (via the security association class) using a ThreadLocal. The thread that deploys components existing in the deploy directory at startup is the main thread. This means that the main thread has a security association. This security association (meaning the Subject bound to the thread by a ThreadLocal) is then copied to every other thread created by JBoss, including the the HTTP processor threads, class loader threads, etc. The very first time the application is accessed using one of the HTTP processor threads, it has the security association create the jms login. Once the processor thread has processed one request, the security association is cleared and functions normally. A partial workaround is to not deploy the MDBs until after JBoss has finished starting up. This prevents the jms-connection user security association from being inherited by the HTTP processor threads. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1316) LazyResultSetLoadingTest testLazyResultSetLoading failure
[ http://jira.jboss.com/jira/browse/JBAS-1316?page=history ] Scott M Stark resolved JBAS-1316: - Resolution: Done After updating the tests I have been unable to reproduce the original failure so this does appear to solve the conflicts. LazyResultSetLoadingTest testLazyResultSetLoading failure - Key: JBAS-1316 URL: http://jira.jboss.com/jira/browse/JBAS-1316 Project: JBoss Application Server Type: Bug Components: CMP service Versions: JBossAS-3.2.7 Final Environment: [EMAIL PROTECTED] testsuite]$ $JAVA_HOME/bin/java -version java version 1.5.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08) Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing) Reporter: Scott M Stark Assignee: Alexey Loubyansky Priority: Blocker Fix For: JBossAS-3.2.7 Final This seems to be another case of test data conflicts that I only see when running all cmp2 test, and in this case only when using java5. ant -Dtest=cmp2 -Djunit.timeout=18 -Dnojars=t test Buildfile: build.xml test: [delete] Deleting: C:\cvs\JBoss3.2\jboss-3.2\testsuite\output\log\test.log [junit] Running org.jboss.test.cmp2.audit.test.AuditUnitTestCase [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.765 sec [junit] Running org.jboss.test.cmp2.cacheinvalidation.test.CacheInvalidation UnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.828 sec [junit] Running org.jboss.test.cmp2.cacheinvalidation.test.JDBC2PmCacheInval idationUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.703 sec [junit] Running org.jboss.test.cmp2.cmr.test.CMRPostCreatesWrittenUnitTestCase [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.563 sec [junit] Running org.jboss.test.cmp2.cmrstress.CMRStressTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.125 sec [junit] Running org.jboss.test.cmp2.cmrtransaction.test.CMRTransactionUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.437 sec [junit] Running org.jboss.test.cmp2.cmrtree.test.CascadeDeleteUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.609 sec [junit] Running org.jboss.test.cmp2.commerce.CompleteUnitTestCase [junit] Tests run: 31, Failures: 1, Errors: 0, Time elapsed: 5.281 sec [junit] Test org.jboss.test.cmp2.commerce.CompleteUnitTestCase FAILED ... testcase classname=org.jboss.test.cmp2.commerce.LazyResultSetLoadingTest name=testLazyResultSetLoading time=0.203 failure message=Expected 3 line items but got 53 type=net.sourceforge.junitejb.RemoteAssertionFailedErrorjunit.framework.AssertionFailedError: Expected 3 line items but got 53 at org.jboss.test.cmp2.commerce.LazyResultSetLoadingTest.testLazyResultSetLoading(LazyResultSetLoadingTest.java:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133) at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102) at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:683) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:144) at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at org.jboss.ejb.Container.invoke(Container.java:709) at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-24) Get 3.2 testsuite running under java 5
[ http://jira.jboss.com/jira/browse/JBAS-24?page=history ] Scott M Stark resolved JBAS-24: --- Resolution: Done All non-jboss failures have been resolved. There are 4 jmx tests failing due to jdk 1.5 jmx bugs. Suite: org.jboss.test.jbossmx.compliance.monitor.BasicTestCase Test:testStringBothNotification Type:failure Exception: junit.framework.AssertionFailedError Message: expected:1 but was:0 - Suite: org.jboss.test.jbossmx.compliance.monitor.BasicTestCase Test:testStringMatchNotification Type:failure Exception: junit.framework.AssertionFailedError Message: expected:1 but was:0 - Suite: org.jboss.test.jbossmx.compliance.monitor.BasicTestCase Test:testStringDifferNotification Type:failure Exception: junit.framework.AssertionFailedError Message: expected:1 but was:0 - Suite: org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase Test:testMalformed Type:failure Exception: junit.framework.AssertionFailedError Message: expected a MalformedObjectNameException for: domain:=,foo=bar - Get 3.2 testsuite running under java 5 -- Key: JBAS-24 URL: http://jira.jboss.com/jira/browse/JBAS-24 Project: JBoss Application Server Type: Task Versions: JBossAS-3.2.7 Final Reporter: Scott M Stark Assignee: Scott M Stark Fix For: JBossAS-3.2.7 Final This task tracks issues affecting the 3.2.7 release testsuite running correctly under java5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
