August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBESB-72) Description in Getting Started Guide for the Test Example

by Jason Lenhart (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-72?page=all ] Jason Lenhart closed JBESB-72. ------------------------------ Resolution: Done A more descript overview of the testJBossESB standalone has been committed. > Description in Getting Started Guide for the Test Example > --------------------------------------------------------- > > Key: JBESB-72 > URL: http://jira.jboss.com/jira/browse/JBESB-72 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 4.0 Alpha 1 > Reporter: Jason Lenhart > Assigned To: Jason Lenhart > Priority: Trivial > Fix For: 4.0 Beta 1 > > > Add a new section to the Getting Started guide to give an in depth overview of the test application. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3183) Integration with WebSphere MQ 5.x

by Weston Price (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3183?page=all ] Weston Price updated JBAS-3183: ------------------------------- Attachment: mq-xa.zip > Integration with WebSphere MQ 5.x > --------------------------------- > > Key: JBAS-3183 > URL: http://jira.jboss.com/jira/browse/JBAS-3183 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Environment: WebSphereMQ 5.3 with Extended TX client > Reporter: Luc Texier > Assigned To: Weston Price > Priority: Blocker > Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.1.CR1 > > Attachments: mq-trace.jar, mq-xa.zip > > > http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossA... > we need to make some changes to StdServerSession and StdServerSessionPool to integrate two workarounds in order to properly integrate with WSMQ 5.x and support their XA resource implementation and transaction handling -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3433) Canonical paths enforced inconsistently

by Ralph Apel (JIRA)

Canonical paths enforced inconsistently --------------------------------------- Key: JBAS-3433 URL: http://jira.jboss.com/jira/browse/JBAS-3433 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.4.GA Environment: Linux/Unix Reporter: Ralph Apel Assigned To: Dimitris Andreadis DeploymentInfo objects are created with file-URLs without previously canonicalizing the file's path. If the original URL wasn't canonical (e.g. with Linux/Unix symlinks involved), this discrepancy leads to failure of at least EjbUtil's resolution of ejb-link: The URL to be searched for among DeploymentInfos by the MBeanServer is constructed from the canonicalized path, but the DeploymentInfo which should be found has a non canonical file URL (i.e. without symlinks resolved). I have been able to provisionally solve this issue by patching EjbUtil to not invoke target = Strings.toURL(ourPath); (which directly or indirectly calls getCanonicalPath()) but a particular code fragment instead. This kind of solution surely isn't the right one. IMO, as the DeploymentInfo.url field is used as a key to the DeploymentInfo collections, this key should be always unique, i.e. canonicalized. My suggestion would be to change any DeploymentInfo instantiation AND any search for DeploymentInfo instances to use canonicalized file URLs. -- 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

19 years, 11 months

2
9
0 / 0

[JBoss JIRA] Assigned: (EJBTHREE-628) Redeployment doesn't work with E-EJB3

by William DeCoste (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-628?page=all ] William DeCoste reassigned EJBTHREE-628: ---------------------------------------- Assignee: William DeCoste > Redeployment doesn't work with E-EJB3 > ------------------------------------- > > Key: EJBTHREE-628 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-628 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC7 - FD > Reporter: Christian Bauer > Assigned To: William DeCoste > > I'm executing the following sequence: > EJB3StandaloneBootstrap.boot(null); > EJB3StandaloneBootstrap.deployXmlResource("META-INF/jboss-beans.xml"); > EJB3StandaloneDeployer deployer = EJB3StandaloneBootstrap.createDeployer(); > deployer.getArchivesByResource().add("META-INF/persistence.xml"); > deployer.create(); > deployer.start(); > deployer.stop(); > deployer.destroy(); > deployer.create(); > deployer.start(); > This fails on the second start() with this: > 12:34:17,397 INFO MCKernelAbstraction:84 - installing bean: jboss.j2ee:jar=classes,name=PlaceItemBean,service=EJB3 with dependencies: > 12:34:17,399 INFO MCKernelAbstraction:87 - AbstractDependencyMetaData@44fc5e {dependency=persistence.units:jar=classes.jar,unitName=caveatemptorDatab ase} > 12:34:17,688 ERROR AbstractKernelController:350 - Error installing to Start: name=jboss.j2ee:jar=classes,name=PlaceItemBean,service=EJB3 state=Create > javax.naming.NamingException: Could not bind user transaction for ejb name PlaceItemBean into JNDI under jndiName: /UserTransaction [Root exception is javax.naming.NameAlreadyBoundException] > at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:650) > at org.jboss.ejb3.EJBContainer.initializePool(EJBContainer.java:595) > at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:526) > at org.jboss.ejb3.SessionContainer.start(SessionContainer.java:82) > at org.jboss.ejb3.stateful.StatefulContainer.start (StatefulContainer.java:73) > 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:585) > at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke (ReflectionUtils.java:55) > at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke (ReflectMethodInfoImpl.java:107) > at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch (BasicMethodJoinPoint.java:66) > at org.jboss.kernel.plugins.dependency.KernelControllerContextActions.dispa tchJoinPoint(KernelControllerContextActions.java:100) > at org.jboss.kernel.plugins.dependency.KernelControllerContextActions $LifecycleAction.installAction(KernelControllerContextActions.java:582) > at org.jboss.kernel.plugins.dependency.KernelControllerContextActions $KernelControllerContextAction.install (KernelControllerContextActions.java:175) > at org.jboss.dependency.plugins.AbstractControllerContextActions.install (AbstractControllerContextActions.java:51) > at org.jboss.dependency.plugins.AbstractControllerContext.install (AbstractControllerContext.java:226) > at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:593) > at org.jboss.dependency.plugins.AbstractController.incrementState (AbstractController.java:346) > at org.jboss.dependency.plugins.AbstractController.resolveContexts (AbstractController.java:438) > at org.jboss.dependency.plugins.AbstractController.resolveContexts (AbstractController.java:379) > at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:225) > at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:151) > at org.jboss.kernel.plugins.dependency.AbstractKernelController.install (AbstractKernelController.java:79) > at org.jboss.kernel.plugins.dependency.AbstractKernelController.install (AbstractKernelController.java:73) > at org.jboss.ejb3.MCKernelAbstraction.install (MCKernelAbstraction.java:91) > at org.jboss.ejb3.Ejb3Deployment.registerEJBContainer (Ejb3Deployment.java:439) > at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:486) > at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.start (EJB3StandaloneDeployer.java:460) > at org.hibernate.ce.auction.test.runtime.IntegrationTest.cleanup (IntegrationTest.java:73) > at org.hibernate.ce.auction.test.foo.TestOne.afterTest(TestOne.java:18) > 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:585) > at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:552) > at org.testng.internal.Invoker.invokeConfigurationMethod (Invoker.java:318) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:152) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:483) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:778) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:105) > at org.testng.TestRunner.privateRun(TestRunner.java:682) > at org.testng.TestRunner.run(TestRunner.java:566) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:220) > at org.testng.SuiteRunner.run(SuiteRunner.java:146) > at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:86) > at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:123) > Caused by: javax.naming.NameAlreadyBoundException > at org.jnp.server.NamingServer.bind(NamingServer.java:144) > at org.jnp.interfaces.NamingContext.bind(NamingContext.java:567) > at org.jnp.interfaces.NamingContext.bind(NamingContext.java:532) > at org.jboss.util.naming.Util.bind(Util.java:102) > at org.jboss.util.naming.Util.bind(Util.java:89) > at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:647) -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-711) Provide an arbitrary identifier for stored ProcessInstances

by Ryan Campbell (JIRA)

Provide an arbitrary identifier for stored ProcessInstances ----------------------------------------------------------- Key: JBPM-711 URL: http://jira.jboss.com/jira/browse/JBPM-711 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1 Reporter: Ryan Campbell Assigned To: Tom Baeyens Fix For: jBPM 3.1.2 When a process instance is created and then saved, an id is returned. If there is a server crash before that id is returned and saved, there is no way to know if the process was created. We would like to have mapping between our own arbitrary ids for a process instance so that we can recover a process instance. ie, recreate it if it was not created successfully. -- 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

19 years, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (JBPM-704) Manifest/Documentation of 3rd Party Jars

by Ryan Campbell (JIRA)

Manifest/Documentation of 3rd Party Jars ---------------------------------------- Key: JBPM-704 URL: http://jira.jboss.com/jira/browse/JBPM-704 Project: JBoss jBPM Issue Type: Feature Request Components: Documentation Affects Versions: jBPM 3.1 Reporter: Ryan Campbell Assigned To: Tom Baeyens Fix For: jBPM 3.1.2 Provide a listing of 3rd pary jars shipped with jBPM. -- 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

19 years, 11 months

2
4
0 / 0

[JBoss JIRA] Commented: (JBRULES-341) language support for 'from'

by Michael Neale (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-341?page=comments#action_12341061 ] Michael Neale commented on JBRULES-341: --------------------------------------- eg: Foo(bar = 2) from query("select * from database where field1 = :price", price) Foo(bar = 2) from service("queryName", x, a, b) > language support for 'from' > --------------------------- > > Key: JBRULES-341 > URL: http://jira.jboss.com/jira/browse/JBRULES-341 > Project: JBoss Rules > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assigned To: Michael Neale > Fix For: 3.1-m1 > > -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-703) Incompatibility with Sybase jConnect 5.5.latest

by Ryan Campbell (JIRA)

Incompatibility with Sybase jConnect 5.5.latest ----------------------------------------------- Key: JBPM-703 URL: http://jira.jboss.com/jira/browse/JBPM-703 Project: JBoss jBPM Issue Type: Sub-task Affects Versions: jBPM 3.1 Environment: Sybase 12.5 Reporter: Ryan Campbell Assigned To: Tom Baeyens Fix For: jBPM 3.1.2 When storing data in the jBPM context with size greater than 255 bytes, the data is truncated at some point. This issue only occurs with the jConnect 5.5 drivers, and not with the jTds opensource drivers. -- 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

19 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBSEAM-331) NPE in PageContext.getCurrentReadableMap() and PageContext.getCurrentWritableMap(), using others PhaseListeners

by Luiz Augusto Ruiz (JIRA)

NPE in PageContext.getCurrentReadableMap() and PageContext.getCurrentWritableMap(), using others PhaseListeners --------------------------------------------------------------------------------------------------------------- Key: JBSEAM-331 URL: http://jira.jboss.com/jira/browse/JBSEAM-331 Project: JBoss Seam Issue Type: Patch Components: JSF Environment: JBoss 4.0.4-GA, JBoss Seam 1.0.1-GA, Ajax4Jsf 1.0 rc4 Reporter: Luiz Augusto Ruiz SeamPhaseListener.afterPhase() invokes Lifecycle.setPhaseId(null) after the phase INVOKE_APPLICATION(5). If exists other PhaseListener that is called after SeamPhaseListener, and use a variable, when the methods PageContext.getCurrent [Readable/Writeble] Map() are called the Null Pointer Exception occurs. The patch checks for null PhaseId before use it. ---------------------------- private Map getCurrentReadableMap() { PhaseId phaseId = Lifecycle.getPhaseId(); if (null == phaseId) { return nextPageMap; } return phaseId.compareTo(PhaseId.INVOKE_APPLICATION) > 0 ? nextPageMap : previousPageMap; } private Map getCurrentWritableMap() { PhaseId phaseId = Lifecycle.getPhaseId(); if (null == phaseId) { return nextPageMap; } return phaseId.compareTo(PhaseId.INVOKE_APPLICATION) < 0 ? previousPageMap : nextPageMap; } ------------------------------------- -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JGRP-244) long connect time in application that frequently closes and opens new channel

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-244?page=all ] Bela Ban resolved JGRP-244. --------------------------- Resolution: Done > long connect time in application that frequently closes and opens new channel > ----------------------------------------------------------------------------- > > Key: JGRP-244 > URL: http://jira.jboss.com/jira/browse/JGRP-244 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2 > Environment: SLES 9 > Reporter: Bruce Schuchardt > Assigned To: Bela Ban > Fix For: 2.4 > > > I have an application that has one long-lived jgroups member and four other processes that often close their channel and create a new one. Most of the time these new connections are formed in a dozen milliseconds or so, but sometimes they're taking over 20 seconds. The apps are using TCPGOSSIP with multicast turned off. > I turned on tracing and saw that the coordinator's UNICAST was having some trouble. It got a message from a departed member that it stored up and dispatched later when the departed member's address was reused by a new channel. > a) A member left the view and UNICAST removed its connection for the member and added it to previous_members. > b) Another message then arrived from the member, and UNICAST created a new connection for it. The message had seqno 4, and was put in the AckReceiverWindow and not passed up. > c) A few seconds later, a process created a new channel and it got the same ID as the one the coordinator's UNICAST just dealt with. > d) The new channel sent three UNICAST messages to the coordinator. On the third message, the coordinator's UNICAST removed #3 and the old #4 and passed them both up. > e) The new channel sent message #4, a JOIN_REQ, and UNICAST discarded it > The new channel eventually goes through discovery again and gets into the group, but it adds quite a bit to channel startup time, and I'm a little worried that there might be a case where a much higher seqno gets trapped in the receiver window like this. > I fixed this for my needs by changing UNICAST.handleDataReceived to reject a previous_member message if the seqno is higher than the default initial seqno, but I suppose that might wreak havoc with some other algorithms. > private void handleDataReceived(Object sender, long seqno, Message msg) { > if(trace) > log.trace(new StringBuffer().append(local_addr).append(" <-- DATA(").append(sender).append(": #").append(seqno)); > if(previous_members.contains(sender)) { > // we don't want to see messages from departed members > if (seqno > DEFAULT_FIRST_SEQNO) { > if (trace) > log.trace("discarding message " + seqno + " from previous member " + sender); > return; > } > if(trace) > log.trace("removed " + sender + " from previous_members as we received a message from it"); > previous_members.removeElement(sender); > } > Entry entry; > synchronized(connections) { -- 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

19 years, 11 months

1
0
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 2006