July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-652) ReplicaetdHashMapTest fails

by Bela Ban (JIRA)

ReplicaetdHashMapTest fails --------------------------- Key: JGRP-652 URL: http://jira.jboss.com/jira/browse/JGRP-652 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Vladimir Blagojevic Fix For: 2.7 [email from Robert Newson] The ViewDeliveryDemo was testing a new feature, it was not the code I sent to Vlad or the code we discussed for the atlanta test. The ViewDeliveryDemo works fine for me once I suppress sending messages after block() as per your change. The test I'm struggling with is the ReplicatedMapDemo which I gave to Vlad several days before writing the ViewDeliveryDemo, sorry for any confusion, but the atlanta lab were testing before I wrote the VDD, so I'm not sure how we got muddled. I've reattached the demo in question. Also, I can confirm that I've written a separate test to demonstrate the losslessness of MessageDispatcher with a zero timeout. It seems to work, though on occasion a VM will block indefinitely on the cast (even though the other boxes are still receiving replies from it), probably a coding error on my part, but fyi. For clarity, the only test the Atlanta lab should run is ReplicatedMapDemo and with these arguments (5 N 50) where N is the total number of nodes. For more stress, increase the first and last parameter (the first is number of maps, the second the number of entries). All boxes should print "PASSED" within some reasonable number of retries (the retry number indicates how long it took for all the puts everywhere to arrive, it polls). It should be started on all boxes concurrently and needs to be run a number of times. I find that it seldom reaches "PASSED" on all boxes though, curiously can reach passed on some but not others (even though map.put() is synchronous)... I have a workaround where I multiplex my own maps over a single, non-multiplexed channel, which works but is far from ideal. -- 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

16 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-5742) some date in <jta-data-source> cause the persistence unit to silently fail without any meanfull Exception

by spamolovko spamolovko (JIRA)

some date in <jta-data-source> cause the persistence unit to silently fail without any meanfull Exception --------------------------------------------------------------------------------------------------------- Key: JBAS-5742 URL: http://jira.jboss.com/jira/browse/JBAS-5742 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.2.GA Environment: Windows XP SP2, Sun JDK 1.5.0_15, Sun JRE 1.5.0_15, JBoss 4.2.2 GA. Reporter: spamolovko spamolovko Sometimes and usually when redeploy application that application can not locate persistent unit. if have <jta-data-source>java:VeryLongNameWith22Characters</jta-data-source>, cause the persistence unit deployment to silently fail without any meanfull Exception. The same with <jta-data-source>java:/VeryLongNameWith22Characters</jta-data-source>. Also problem appear when application is redeploing. Can work before deploy, can not work after deploy. Solve: restart full server, application and datasource should be placed before restart. Real solve: use sorter names. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5645) JBossWeb losing POST data during FORM Authentication

by Anil Saldhana (JIRA)

JBossWeb losing POST data during FORM Authentication ---------------------------------------------------- Key: JBAS-5645 URL: http://jira.jboss.com/jira/browse/JBAS-5645 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Anil Saldhana Assigned To: Remy Maucherat Fix For: JBossAS-5.0.0.CR1 TestCase: org.jboss.test.web.test.FormAuthUnitTestCase Test: testPostDataFormAuth Somehow the form authenticator restore request is losing the post data that was submitted as part of the request before the form authentication kicked in. Remy, please validate 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

5
21
0 / 0

[JBoss JIRA] Created: (JBAS-5736) Starting server with predeployed MDB POJO fails

by Dominik Pospisil (JIRA)

Starting server with predeployed MDB POJO fails ----------------------------------------------- Key: JBAS-5736 URL: http://jira.jboss.com/jira/browse/JBAS-5736 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.CR1 Reporter: Dominik Pospisil Attachments: mdbtest.tgz Starting the server with predeployed JEE5 ear with MDP POJO fails. Deploying the application on running server works fine. Errors logged: 10:39:58,520 ERROR [ExceptionUtil] ConnectionFactoryEndpoint[jboss.messaging.connectionfactory:service=ConnectionFactory] createFailoverConnectionDelegate [p2-klj49eif-1-ip839eif-dlwwwk-100j3] java.lang.RuntimeException: javax.naming.NameNotFoundException: securityManagement not bound at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:199) 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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy79.authenticate(Unknown Source) at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:225) at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:165) at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108) at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java) at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:847) at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101) at org.jboss.remoting.Client.invoke(Client.java:1685) at org.jboss.remoting.Client.invoke(Client.java:589) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:167) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeTarget(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111) at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:81) at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_11112467.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_11112467.java) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java) at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205) at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:101) at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:95) at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setupDLQConnection(AbstractDLQHandler.java:137) at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setup(AbstractDLQHandler.java:83) at org.jboss.resource.adapter.jms.inflow.dlq.JBossMQDLQHandler.setup(JBossMQDLQHandler.java:48) at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDLQ(JmsActivation.java:401) at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:339) at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:692) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: javax.naming.NameNotFoundException: securityManagement not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:542) at org.jnp.server.NamingServer.getBinding(NamingServer.java:550) at org.jnp.server.NamingServer.getObject(NamingServer.java:556) at org.jnp.server.NamingServer.lookup(NamingServer.java:296) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.lookupSecurityManagement(JBossASSecurityMetadataStore.java:330) at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:195) ... 42 more -- 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

16 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1977) Check URL encoding process with JSF

by Thomas Heute (JIRA)

Check URL encoding process with JSF ----------------------------------- Key: JBPORTAL-1977 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1977 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Reporter: Thomas Heute Assigned To: Julien Viet Fix For: 2.7 Final We need to check the URL encoding process with usage of JSF. The JSF API is not clear about it, it seems that the different implementations may not even interpret them the same way. JSFInvocation is now encoding the URL received from ViewHandler.getActionURL() -- 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

16 years, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAOP-609) Add $implements/ing support to has

by Flavia Rainone (JIRA)

Add $implements/ing support to has ----------------------------------- Key: JBAOP-609 URL: http://jira.jboss.com/jira/browse/JBAOP-609 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR14 Reporter: Flavia Rainone -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5715) -ds.xml not trimming whitespace in jboss5

by Adrian Brock (JIRA)

-ds.xml not trimming whitespace in jboss5 ----------------------------------------- Key: JBAS-5715 URL: http://jira.jboss.com/jira/browse/JBAS-5715 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-5.0.0.CR1 Reporter: Adrian Brock Assigned To: Jesper Pedersen Fix For: JBossAS-5.0.0.CR2 See JBAS-5173 Here's an example where it is being used: org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentMetaData /** The connectionDefinition */ @XmlElement(name="connection-definition") @XmlJavaTypeAdapter(CollapsedStringAdapter.class) // HERE! protected String connectionDefinition; But this should be on every String. -- 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

16 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-5728) Upgrade jboss remoting to v2.2.2.SP8 (from v2.2.2.SP5)

by Ron Sigal (JIRA)

Upgrade jboss remoting to v2.2.2.SP8 (from v2.2.2.SP5) ------------------------------------------------------ Key: JBAS-5728 URL: http://jira.jboss.com/jira/browse/JBAS-5728 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal EAP 4.2/4.3 are currently shipping with Remoting 2.2.2.SP7 and testing with 2.2.2.SP8 for the next CP releases. We could just update to 2.2.2.SP7, but I think JBREM-949 in 2.2.2.SP8 is important to JBossMessaging. Many of the other bug reports arose in support cases: JBREM-962, JBREM-965, JBREM-981 Reported by Galder: JBREM-954, JBREM-960 Reported by Ovidiu: JBREM-972, JBREM-973 ======================================================================================================== Release Notes - JBoss Remoting - Version 2.2.2.SP8 - Text format Bug * [JBREM-949] - CLONE [JBREM-947] - ConnectionValidator hangs when server dies * [JBREM-954] - InterruptedException should not be rethrown as CannotConnectionException * [JBREM-960] - Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect * [JBREM-962] - Remote classloading does not work with Isolated EARs * [JBREM-965] - Fix PortUtil.getRandomStartingPort() * [JBREM-981] - CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator * [JBREM-1003] - Verify IPv6 addresses are handled correctly, part 2 Feature Request * [JBREM-972] - CLONE [JBREM-971] - Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded * [JBREM-973] - CLONE [JBREM-970] - Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted Release * [JBREM-948] - Release 2.2.2.SP8 Task * [JBREM-950] - Assure version compatibility with earlier versions of Remoting * [JBREM-995] - Apply unit test timing fixes * [JBREM-1001] - Update Remoting Guide * [JBREM-1002] - Allow ServerThread to keep running after SocketTImeoutException, part 2 * [JBREM-1004] - Run manual servlet unit tests -- 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

16 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1357) Root nodes of marshalled regions won't be loaded correclty from cache loaders

by Galder Zamarreno (JIRA)

Root nodes of marshalled regions won't be loaded correclty from cache loaders ----------------------------------------------------------------------------- Key: JBCACHE-1357 URL: http://jira.jboss.com/jira/browse/JBCACHE-1357 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.1.SP9 Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Yesterday while looking at a support case, I discovered an awkward behavior when it came to root region based marshalling nodes and cache loaders. Let's say you have a cache configured with a cache loader and have a region marshaled called starting at /me. I have created an MBean so that I can register/unregister classloader and activate/deactivate the region upon deployment/undeployment of the classes I wanna put under /me. Now, let's say that I put a k,v in /me which will get stored in the cache loader. If I know touch the deployment archive to force a redeployment and check the contents of the cache, they're empty. If I try to get the k I put under /me, it'll return nothing. Why? Simple: The cache instance is configured to preload from root (/) but when the region is activated, /me node is created. When the preloading phase comes, a check is made to see whether the node needs to be loaded: private boolean mustLoad(DataNode n, Object key) { if (log.isTraceEnabled()) { log.trace("mustLoad called with key=" + key + " and datanode=" + n); } return n == null || (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key))); } The problem is that nothing will be preloaded for at least the /me node, because the node is not null, and it's not TreeCache.UNINITIALIZED. Any child nodes under the region node do not have issues like this. This is likely a bug: maybe when the region is activated, the node should probably be created as TreeCache.UNINITIALIZED? I think this would work). It's true that you could say that putting data at the root node of the region is not a good idea regardless, but I think deep down this is a bug. p.s. This is at least present in 1.4.x, need to check trunk. Manik: I agree this is a bug. Could you raise a JIRA for this? Also agree with your solution, that when a region is activated and if a node needs to be created, it should be uninitialized. If you create a unit test, could you add it to trunk as well? -- 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

16 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-57) Change annotated class lookup in AnnotationEnvironment

by Ales Justin (JIRA)

Change annotated class lookup in AnnotationEnvironment ------------------------------------------------------ Key: JBDEPLOY-57 URL: http://jira.jboss.com/jira/browse/JBDEPLOY-57 Project: JBoss Deployers Issue Type: Feature Request Affects Versions: JBDEPLOY-2.0.0.Beta18 Reporter: Ales Justin Assigned To: Ales Justin Fix For: JBDEPLOY-2.0.0.CR1 In order to make things fully lazy - http://jira.jboss.com/jira/browse/JBAS-5558 current classIsAnnotated method on AnnotationEnvironment is not suited for this. Changing it to look like other methods, lazy via Element 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 6 months

1
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2008