July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3836) Conditional setting of -server may not be supported on sun jdk1.3

by Dimitris Andreadis (JIRA)

Conditional setting of -server may not be supported on sun jdk1.3 ----------------------------------------------------------------- Key: JBAS-3836 URL: http://jira.jboss.com/jira/browse/JBAS-3836 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-3.2.8.SP2 The change in JBAS-3458 conditionally sets -server. Although sun jdk1.3 seems to support -server, it fails with: Unrecognized option: -server (although the forum post refers erroneously to 4.0.5, the error appears in the 3.2 branch, too). -- 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

18 years

2
1
0 / 0

[JBoss JIRA] Updated: (JBAS-3154) Cleanup the remoting module in 3.2.x

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3154?page=all ] Dimitris Andreadis updated JBAS-3154: ------------------------------------- Fix Version/s: (was: JBossAS-3.2.8.SP2) Unschedule 3.2.8.SP2 tasks, since we are not going to produce another release from that branch. > Cleanup the remoting module in 3.2.x > ------------------------------------ > > Key: JBAS-3154 > URL: http://jira.jboss.com/jira/browse/JBAS-3154 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: JBossAS-3.2.8.SP1 > Reporter: Dimitris Andreadis > Assigned To: Tom Elrod > > Having removed the sources with proprietary licenses and files depending on them (all of them are tests), we need to further cleanup the remoting module in 3.2.x. As far I can tell, this is obsolete. There is only a remoting.sar installed in docs\example\remoting, who's META-INF descriptor needs renaming to jboss-service.xml to deploy properly (it does deploy with this change). > The files removed where: > src/main/test/classloading/InvokerTestCase.java > src/main/test/ComplexReturn.java > InvokerClientTest.java InvokerServerTest.java > InvokerTestCase.java OnewayInvokerServerTest.java > OnewayInvokerTestCase.java > src/main/test/classloading/server/InvokerServerNoClientTest.java > InvokerServerNoSecurityTest.java > InvokerServerNoServerTest.java > InvokerServerSecureTest.java > src/main/test/detection/DetectorUtil.java > src/main/org/jboss/remoting/transport/test/TransportTest.java > src/main/org/jboss/remoting/transport/mock/MockServerInvocationHandler.java MockTest.java > src/main/test/performance/TestServerInvocationHandler.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 - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5503) JUnitReport OutOfMemoryError failed many testsuite on hudson

by Jeff Zhang (JIRA)

JUnitReport OutOfMemoryError failed many testsuite on hudson ------------------------------------------------------------ Key: JBAS-5503 URL: http://jira.jboss.com/jira/browse/JBAS-5503 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: Backlog Environment: Linux, Windows Reporter: Jeff Zhang Priority: Minor Fix For: JBossAS-5.0.0.CR1 We can see JunitReport Task throw OutOfMemeoryError on hudson testsuite tests both on JDK5 and JDK6. Manually increase -Xmx in ANT_OPTS can resolve this problem -- 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

18 years

2
4
0 / 0

[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

18 years

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

18 years

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

18 years

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

18 years

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

18 years

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

18 years

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

18 years

3
4
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 July 2008