August 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1682) Add a test to ensure Stateless and message driven beans work fine in the absence of a pool

by jaikiran pai (JIRA)

Add a test to ensure Stateless and message driven beans work fine in the absence of a pool ------------------------------------------------------------------------------------------ Key: AS7-1682 URL: https://issues.jboss.org/browse/AS7-1682 Project: Application Server 7 Issue Type: Task Components: EJB Reporter: jaikiran pai Assignee: jaikiran pai Fix For: 7.0.2.Final Starting AS 7.0.1, we allow users to disable pooling for Stateless and Message driven beans. We need a test to ensure it works fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1275) Multiple moves win a step (moves without direct tabu property relations)

by Geoffrey De Smet (JIRA)

Multiple moves win a step (moves without direct tabu property relations) ------------------------------------------------------------------------ Key: JBRULES-1275 URL: http://jira.jboss.com/jira/browse/JBRULES-1275 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Currently only one move can win a step. If moves are evaluated not on their score, but on "the difference in score", it probably won't be a bad idea to take a low number of improving moves that have not tabu property's in common and do a step of all of them instead of just one, especially in the beginning. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1328) SelectorConfig, AccepterConfig en other Config's aren't Serializable if they have a direct Selector/Accepter instance configured

by Geoffrey De Smet (JIRA)

SelectorConfig, AccepterConfig en other Config's aren't Serializable if they have a direct Selector/Accepter instance configured -------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-1328 URL: http://jira.jboss.com/jira/browse/JBRULES-1328 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Because AbstractAccepter references LocalSearchSolver references the drools RuleBase references stuff that isn't Serializable... -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2553) CompositeSelector should support weighting the selection of each sub selector.

by Geoffrey De Smet (JIRA)

CompositeSelector should support weighting the selection of each sub selector. ------------------------------------------------------------------------------ Key: JBRULES-2553 URL: https://jira.jboss.org/browse/JBRULES-2553 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.1.0.M2 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Minor Fix For: FUTURE Before the simulated annealing support refactor, this was possible, now it's not because the new CompositeSelector weights them all the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-9023) EJB Timers

by David Lloyd (JIRA)

EJB Timers ---------- Key: JBAS-9023 URL: https://issues.jboss.org/browse/JBAS-9023 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.Beta3 Parent task for EJB Timer implementation items. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

5
8
0 / 0

[JBoss JIRA] Created: (SECURITY-610) The continuation of SPNEGO requests causes a 'Login failure' error to be reported.

by Darran Lofthouse (JIRA)

The continuation of SPNEGO requests causes a 'Login failure' error to be reported. ---------------------------------------------------------------------------------- Key: SECURITY-610 URL: https://issues.jboss.org/browse/SECURITY-610 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2.2.0 The continuation from the login module now causes the following error to be logged: - 12:46:42,245 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--10.36.4.52-8080-1) Login failure: javax.security.auth.login.LoginException: Continuation Required. at org.jboss.security.negotiation.spnego.SPNEGOLoginModule.login(SPNEGOLoginModule.java:174) [jboss-negotiation-2.2.0.SNAPSHOT.jar:2.2.0.SNAPSHOT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24] at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) [:1.6.0_24] at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_24] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_24] at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_24] at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_24] at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_24] at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.1.jar:4.0.1] at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.1.jar:4.0.1] at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.1.jar:4.0.1] at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT] at org.jboss.security.negotiation.NegotiationAuthenticator.authenticate(NegotiationAuthenticator.java:187) [jboss-negotiation-2.2.0.SNAPSHOT.jar:2.2.0.SNAPSHO Bringing Kerberos to the domain management security is going to require some of the same behaviour as we have in the SPNEGOLoginModule - it may make sense to pull this common behaviour out of the login module anyway for consistency - this would also remove the exception being logged here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (SECURITY-129) Client Delegation

by Darran Lofthouse (JIRA)

Client Delegation ----------------- Key: SECURITY-129 URL: http://jira.jboss.com/jira/browse/SECURITY-129 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Web browser can delegate to the server being called so same credentials can be used for further calls. Delegation using GSSAPI, WS-Kerberos, credential propagation for EJB calls etc.. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
13
0 / 0

[JBoss JIRA] Created: (SECURITY-572) Support for situation when first OID is Kerberos OID instead of SPNEGO OID

by Marek Posolda (JIRA)

Support for situation when first OID is Kerberos OID instead of SPNEGO OID -------------------------------------------------------------------------- Key: SECURITY-572 URL: https://issues.jboss.org/browse/SECURITY-572 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2.0.3.GA Environment: JBoss EPP 5.1.GA with SPNEGO support, JBoss Negotiation 2.0.3, commons-http-client 3.1 used as HTTP client Reporter: Marek Posolda Assignee: Darran Lofthouse Fix For: Negotiation_2.0.4 Currently first byte of SPNEGO token is used to recognize if it's new token NegTokenInit and another 3 bytes are used to recognized length. From byte 5 is starting sequence for recognizing OID. Currently NegotiationAuthenticator is able to handle situations where this OID is SPNEGO OID (1.3.6.1.5.5.2) but it's not able to correctly handle situations where first OID is Kerberos OID (1.2.840.113554.1.2.2). Problem is that if Kerberos is used, then the rest of sequence format is different then for SPNEGO and IOException is thrown in method NegTokenInitDecoder.decodeNegTokenInitSequence because the sequence type is not expected value (any of 0xa0, 0xa1, 0xa2, 0xa3). I think that support for Kerberos OID is not critical and I am not sure if it's really the issue, but guys here https://issues.apache.org/jira/browse/HTTPCLIENT-523 are saying that it's working correctly with IIS but not with JBoss Negotiation. For simulating of situation can be used commons-httpclient3 with integration of NegotiateScheme: http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/src/contrib... Or you can simulate it by sending this Negotiate token in HTTP header: Authorization : Negotiate YIID7QYJKoZIhvcSAQICAQBuggPcMIID2KADAgEFoQMCAQ6iBwMFAAAAAACjggEEYYIBADCB/aADAgEFoQ8bDUxPQ0FMLk5FVFdPUkuiJzAloAMCAQChHjAcGwRIVFRQGxRzZXJ2ZXIubG9jYWwubmV0d29ya6OBuzCBuKADAgEDoQMCAQOigasEgajWrIRyQlCHtxXO//EMI/6C9zBChS00QtgZLctUa0qjb14RZFFj5pyruAB7SrqnxuD7JROJpwsVZG7FDpFu47Y3ZXyWjq8C1px+V4CULGgOt3Aufyh8DVRGeuhxYQ17APR5pC418Wo/u/VIJvLco7VZaAlGEF0xyJ8thtBM8Oz88urPpVxOl+7mUd2XirkqReL5ITdsEOjnZ4Q8duYKDPq9GdVcvf7MFyikggK5MIICtaADAgEBooICrASCAqjngVyeX24XzPtoMsnO0W2DoiX+SfpshcbZOVN0ne98Zxhnq3gxxiHiiI3voWTqtAiXe9E/Ti+wPuFI1g4jXsOjY8V4GGfDxihxGSMa9vu45JvLr+MPL40EwmFaD6fRpU+DA80ZhS+1THhTKT2w28pJS45fgSM2igmXQYk0hfv/Q7xIYBmNJXMZ2ZgyY8dek5dflg9zjuZetR6RSYJtu7Q+c/w3t/yHYLtcrz98aD+Q4EjBtf4I3EpP+c5NSkpouSvRy8u4yPNgOyvM8CdXuABveVdl+/DX100ucJc9uXAL+lPMdk+YMo8rAoEWae3km5LDfd3JncPB50OKwjNzejvi5e+5OYG17TpTx88sGMl0JLQ5mgrUBMPMG/c2sje4mhmTa8nO8SdqP6Fa1HVYPZNgDskSvTQzM0zsLRU0tyuge41hB8J6AOje1rGvpLBKMdMbXqnD08aC0N1qL1b5TmNk2jcWyJaGAi1pxzyNDwFTL5LUr7e+bIHrX2nd3g328pdDfZCBiqvrInXR+7phnKYinit22O4ktQQRuS9bybZR+ECAVrnCXspPieIvPLZYrzEDgp3NXYlUUzyWuNBN/obXAHiXhE0LMtnDvSs/MQYHTjGAahoKVjxNWDSmRylGD49dAI/N+cNnB/1NruSTLd5voahGYrnDmoouWafa4oaARZqq48lSAgaMhfPoMfYaBSWS9mWYltBEsTUAQO3sNg0Sx0d0jtQzQG/37mxKCF5F/rAeeI5NQcRrXV1RZzkY7UPyaiIwelt/ZOo2tJqgkSIKQwPBlH/GGlRvrCse3f2Eg/FoSKUMTHkjl433BiG4J9+5Isgchgl6XfolW4d7b5Ztqg0zi+k0ydTzpeK1h9mYbJ1ML2rdlHTXNEnF0fmwz+4SGk09bG/Rqw== Another thing is handling of IOException, which is not logged anywhere, but I will create another JIRA issue for it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (AS7-1271) Fired object messages violate classloaders

by John Ament (JIRA)

Fired object messages violate classloaders ------------------------------------------ Key: AS7-1271 URL: https://issues.jboss.org/browse/AS7-1271 Project: Application Server 7 Issue Type: Bug Reporter: John Ament JMS allows you to fire an object message. In this case, I have a object of type in my deployment. It fires fine. I bind a message consumer to a queue in AS7. the object message coming in results in a classloader violation: 22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) at java.lang.Class.forName0(Native Method) [:1.6.0_22] at java.lang.Class.forName(Class.java:247) [:1.6.0_22] at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22] at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:] at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22] at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22] at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:] at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46) at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22] at java.lang.Thread.run(Thread.java:662) [:1.6.0_22] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

13
29
0 / 0

[JBoss JIRA] Created: (JBAS-8734) API change in deployment scanner's add cause failed deployments

by Rob Stryker (JIRA)

API change in deployment scanner's add cause failed deployments --------------------------------------------------------------- Key: JBAS-8734 URL: https://issues.jboss.org/browse/JBAS-8734 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers Affects Versions: 6.0.0.CR1 Reporter: Rob Stryker Assignee: Ales Justin Priority: Critical When using the deployment scanner mbean to pass in a new URL that the JBossAS should scan for deployments, a path format which worked fine in JBoss 5 and below no longer works. Specifically, passing in a URL such as the one below: file:/home/rob/apps/eclipse/workspaces/main_code/runtime%20space%20workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1292215199516/deploy/Dyn888.war/ When passing this string into the addURL mbean, the following error in the jboss console results: 14:52:54,927 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/Dyn888 14:52:54,930 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=jboss.web.deployment:war=/Dyn888 state=Create mode=Manual requiredState=Installed: java.net.URISyntaxException: Illegal character in path at index 56: file:/home/rob/apps/eclipse/workspaces/main_code/runtime space workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1292215199516/deploy/Dyn888.war/ at java.net.URI$Parser.fail(URI.java:2809) [:1.6.0_14] at java.net.URI$Parser.checkChars(URI.java:2982) [:1.6.0_14] Despite that I pass in a string with clear %20 blocking out the spaces, the deployment scanner does not seem to recognize this and errors. This format of a string has no problem working in AS 5.1 however. This is blocking JBossTools server integration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

10
31
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2011