[JBoss JIRA] Created: (JBAS-6854) ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] (main) XML error parsing: WEB-INF/context.xml, org.jboss.xb.binding.JBossXBException: Failed to parse source: Store not found as a child of Manager
by karthik m (JIRA)
ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] (main) XML error parsing: WEB-INF/context.xml, org.jboss.xb.binding.JBossXBException: Failed to parse source: Store not found as a child of Manager
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-6854
URL: https://jira.jboss.org/jira/browse/JBAS-6854
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.GA
Reporter: karthik m
2009-05-01 18:48:17,546 ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] (main) XML error parsing: WEB-INF/context.xml
org.jboss.xb.binding.JBossXBException: Failed to parse source: Store not found as a child of Manager
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:183)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextConfig.java:571)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.init(JBossContextConfig.java:542)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5436)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4148)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:367)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146)
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:460)
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
at org.jboss.web.deployers.WebModule.start(WebModule.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
at $Proxy36.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:146)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:104)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:547)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (EJBTHREE-1813) @Resource does not inject simple environment entries
by Andrew Lee Rubinger (JIRA)
@Resource does not inject simple environment entries
----------------------------------------------------
Key: EJBTHREE-1813
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1813
Project: EJB 3.0
Issue Type: Bug
Components: core
Reporter: Andrew Lee Rubinger
Assignee: Andrew Lee Rubinger
Given:
<!-- Override the one-way hash MessageDigest algorithm -->
<env-entry>
<env-entry-name>messageDigestAlgorithm</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>SHA</env-entry-value>
</env-entry>
All that should be required for injection is @Resource upon a field of same name within the bean class:
@Resource
private String messageDigestAlgorithm;
Spec 16.4.1.1:
The Bean Provider uses the Resource annotation to annotate a field or method of the bean class as a
target for the injection of a simple environment entry. The name of the environment entry is as described
in Section 16.2.2; the type is as described in Section 16.4.
WARN message in logs is:
17:37:00,963 WARN [ResourceHandler] Not injecting messageDigestAlgorithm, no matching enc injector env/org.jboss.ejb3.examples.ch05.encryption.EncryptionBean/messageDigestAlgorithm found
ENC is:
+- EJBContext (class: javax.ejb.EJBContext)
+- TransactionSynchronizationRegistry[link -> java:TransactionSynchronizationRegistry] (class: javax.naming.LinkRef)
+- UserTransaction (class: org.jboss.ejb3.tx.UserTransactionImpl)
+- env (class: org.jnp.interfaces.NamingContext)
| +- messageDigestAlgorithm (class: java.lang.String)
| +- ciphersPassword (class: java.lang.String)
| +- org.jboss.ejb3.examples.ch05.encryption.EncryptionBean (class: org.jnp.interfaces.NamingContext)
| | +- context[link -> java:comp/EJBContext] (class: javax.naming.LinkRef)
+- ORB[link -> java:/JBossCorbaORB] (class: javax.naming.LinkRef)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBREM-1119) CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down
by Ron Sigal (JIRA)
CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down
--------------------------------------------------------------------------------------
Key: JBREM-1119
URL: https://jira.jboss.org/jira/browse/JBREM-1119
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.1 (Flounder), 2.2.2.SP12
1. a. org.jboss.remoting.callback.ServerInvokerCallbackHandler is referenced by org.jboss.remoting.ServerInvoker and by the org.jboss.remoting.ConnectionNotifier, if any, created by ServerInvoker.
b. ServerInvokerCallbackHandler is passed to org.jboss.remoting.ServerInvocationHandler.addListener(), so the application ServerInvocationHandler could also maintain a pointer to ServerInvokerCallbackHandler.
If the application calls org.jboss.remoting.Client.removeListener(), then ServerInvoker will clean up its references to ServerInvokerCallbackHandler, and it will call ServerInvocationHandler.removeListener(), giving the application a chance to remove the reference it holds.
However, if the connection from the client breaks, none of these things happen.
2. There needs to be a ServerInvokerCallbackHandler method that can be called by the application, by, for example, a ConnectionListener, which will cause the references to be removed by ServerInvoker and the applications ServerInvocationHandler.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBREM-1125) Test for IllegalStateException when calling Timer.schedule()
by Ron Sigal (JIRA)
Test for IllegalStateException when calling Timer.schedule()
------------------------------------------------------------
Key: JBREM-1125
URL: https://jira.jboss.org/jira/browse/JBREM-1125
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.1 (Flounder), 2.2.2.SP11
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.2.2.SP12, 2.5.2 (Flounder)
When a java.util.Timer has not more TimerTasks in its queue, it can shut itself down, so that subsequent calls to Timer.schedule() will throw a java.lang.IllegalStateException. Therefore, all calls to Timer.schedule() should be inside a try/catch block that will catch IllegalStateExceptions and create a new Timer. Most of these calls in Remoting are already protected, but there are a couple that are not. In particuler,
branch 2.2:
========
* org.jboss.remoting.detection.AbstractDetector.startHeartbeat()
* org.jboss.remoting.util.TimerUtil.schedule()
branch 2.x:
========
* org.jboss.remoting.detection.AbstractDetector.startHeartbeat()
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Commented: (JBAS-2820) ClientLoginModule improperly clears SecurityAssociation stack in logout()
by William Newman (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-2820?page=com.atlassian.jira.plug... ]
William Newman commented on JBAS-2820:
--------------------------------------
I am seeing this problem in 4.2.2.GA.
> ClientLoginModule improperly clears SecurityAssociation stack in logout()
> -------------------------------------------------------------------------
>
> Key: JBAS-2820
> URL: https://jira.jboss.org/jira/browse/JBAS-2820
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: JBossAS-4.0.4RC1
> Reporter: Luigi Putanesca
> Assignee: Scott M Stark
> Priority: Critical
> Fix For: JBossAS-3.2.8.SP1, JBossAS-4.0.4.CR2, JBossAS-5.0.0.Beta1
>
>
> I found a problem with how the ClientLoginModule handles the SecurityAssociation stack. The problem appears under the following conditions:
> 1. restoreloginidentity = true
> 2. method calls are made through session bean interfaces. (this causes the stack to be pushed and later popped).
> 3. there are multiple logins before a logout.
> Summary:
> Basically what happens is I login a user, call a session bean, login a second user, logout the second user, exit the session bean and expect to revert to original user. The original user should still be logged in but it isn't. The problem is this: the ClientLoginModule.logout() method always clears the SecurityAssociation stack and then restores the login identity by logging in again. This leaves stack out of sync and when the session bean call exits, the stack is popped again and the user removed when it really should still be there.
> Here is a sequence of what happens with the stack during my scenario:
> 1. Starting point. (Stack.size = 0)
> 2. Login 1st user.User is set to SecurityAssociation and pushed to stack. (Stack.size = 1)
> 3. Make call to session bean. User is pushed to stack again by AuthenticationInterceptor. (Stack.size = 2)
> 4. Login 2nd user. User is set to SecurityAssociation and pushed to stack. (Stack.size = 3)
> 5. Logout 2nd user. Stack is cleared. (Stack.size = 0) (THIS IS THE PROBLEM)
> 6. 1st user is reset to SecurityAssociation and pushed to stack by the ClientLoginModule. (Stack.size = 1)
> 7. exit call to session bean. 1st User is popped from stack by AuthenticationInterceptor. (Stack.size = 0)
> 8. No user is logged in.
> What should be happening is in Step 5, the stack should be popped not cleared. The end result in Step 8 should be one user in the stack. The only way I should end up with an empty stack is if I call logout again, which I didn't.
> Here is the fix I put into the ClientLoginModule:
> public boolean abort() throws LoginException {
> /* Changed here. Only clear if not restoring identity. */
> if (restoreLoginIdentity) {
> SecurityAssociation.popSubjectContext();
> }
> else {
> SecurityAssociation.clear();
> }
> return true;
> }
> public boolean logout() throws LoginException {
> /* Changed here. Only clear if not restoring identity. */
> if (restoreLoginIdentity) {
> SecurityAssociation.popSubjectContext();
> }
> else {
> SecurityAssociation.clear();
> }
> Set principals = subject.getPrincipals();
> principals.remove(loginPrincipal);
> return true;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBAS-6852) JBoss looses authentication information
by Brian unknown (JIRA)
JBoss looses authentication information
---------------------------------------
Key: JBAS-6852
URL: https://jira.jboss.org/jira/browse/JBAS-6852
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.3.GA
Environment: Windows xp
Reporter: Brian unknown
Assignee: Carlo de Wolf
I created a loginContext to log in a user, which worked fine at first. It gave me a subject with principles. But after the method finished, JBoss lost the authentication info, so that next time I tried to access a secured jsp it redirected me to the log in page. I tested it with a form submitting to j_security_check, and it worked fine. It seems to only be a problem when submitting to a custom method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBRULES-2010) multibyte characters in drl fails with "no viable alternative at character"
by Yusuke Yamamoto (JIRA)
multibyte characters in drl fails with "no viable alternative at character"
---------------------------------------------------------------------------
Key: JBRULES-2010
URL: https://jira.jboss.org/jira/browse/JBRULES-2010
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.0.0.M5, 5.0.0.M4, 5.0.0.M3, 5.0.0.M2, 5.0.0.M1, 4.0.7
Reporter: Yusuke Yamamoto
Assignee: Mark Proctor
When multi-byte characters are used for rule name, field name, or function name, compiler reports "no viable alternative at character".
Additionally, multi-byte characters are normalized into "_" and compiler fails to differenciate names when their length are same.
------
org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=日本語ルール２, agendaGroup=MAIN, salience=0, no-loop=false]
org/drools/compiler/Rule_________0.java (3:43) : The type Rule_________0 is already defined
at org.drools.rule.Package.checkValidity(Package.java:424)
at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:394)
at org.drools.compiler.MultibyteDRLTest.executeTestFor(MultibyteDRLTest.java:90)
at org.drools.compiler.MultibyteDRLTest.testmultibyteRuleName2(MultibyteDRLTest.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
-------
This issue is reproducible both on Drools 4.0.7 and 5.0.0.
Drools Version: 5.0.0.CR1 , 4.0.7
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBRULES-2008) multibyte characters in dsl fails with "no viable alternative at character"
by Yusuke Yamamoto (JIRA)
multibyte characters in dsl fails with "no viable alternative at character"
----------------------------------------------------------------------------
Key: JBRULES-2008
URL: https://jira.jboss.org/jira/browse/JBRULES-2008
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.0.0.M5, 5.0.0.M4, 5.0.0.M3, 5.0.0.M2, 5.0.0.M1
Environment: Drools 5.0.0.CR1
Reporter: Yusuke Yamamoto
Assignee: Mark Proctor
Drools compiler fails to compile DSLs containing multibyte characters in them, says "no viable alternative at character".
----------
line 3:6 no viable alternative at character '出'
line 3:7 no viable alternative at character '力'
java.lang.NullPointerException
at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:451)
at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:481)
at org.drools.compiler.MultibyteDSLTest.testMultibyteDSL(MultibyteDSLTest.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
----------
http://lists.jboss.org/pipermail/rules-users/2009-March/008293.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months