March 2010 - jboss-dev-forums - Jboss List Archives

[jBPM Development] New message: "Re: Perhaps a bug in createHistoryActivityInstanceQuery when process has a fork"

by Maciej Swiderski

JBoss development, A new message was posted in the thread "Perhaps a bug in createHistoryActivityInstanceQuery when process has a fork": http://community.jboss.org/message/529170#529170 Author : Maciej Swiderski Profile : http://community.jboss.org/people/swiderski.maciej Message: -------------------------------------------------------------- I played a bit with jBPM source today (from trunk) and extended the HistoryActivityInstanceQuery with processInstanceId. It seems to work fine, it is almost the same as for processDefinitionId filter. Need to write some more test cases for it, at the moment only one that is based on already prepared test cases for ActivityInstanceQuery. P.S. Good to hear that the use case described is non-negotiable - I thought I had only a weird idea Cheer, Maciej -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529170#529170

16 years, 1 month

1
0
0 / 0

[jBPM Development] New message: "Key for ProcessInstance cannot be changed during execution because of HashCode implementation"

by Robert Schmelzer

JBoss development, A new message was posted in the thread "Key for ProcessInstance cannot be changed during execution because of HashCode implementation": http://community.jboss.org/message/529153#529153 Author : Robert Schmelzer Profile : http://community.jboss.org/people/roschmel Message: -------------------------------------------------------------- Hi, i just upgraded from 3.2.3 to 3.2.8 and had the problem, that my process variables was not found anymore. After some debugging, I found out that the HashCode of my root token changed during execution because I set the ProcessInstance.key property during process execution as soon as I know my unique business key. The changes hashcode and equals for ProcessInstance and therefore also for Token. I think this is a major bug! At least it changes the behavoiur of existing processes. What do you think? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529153#529153

16 years, 1 month

1
0
0 / 0

[jBPM Development] New message: "Re: Perhaps a bug in createHistoryActivityInstanceQuery when process has a fork"

by Robert Moskal

JBoss development, A new message was posted in the thread "Perhaps a bug in createHistoryActivityInstanceQuery when process has a fork": http://community.jboss.org/message/529150#529150 Author : Robert Moskal Profile : http://community.jboss.org/people/rmoskal Message: -------------------------------------------------------------- Thanks for replying Maciej. Sometimes it is difficult to sift through all the information about JBPM. I can understand why it works the way it does from an implementation perspective, but seems that getting a complete process history is a non-negotiable use case for most clients. I will look through the history tables and see if there is enough information in them to reconstitute a complete process history. Thanks and regards, Robert Moskal Brooklyn, USA -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529150#529150

16 years, 1 month

1
0
0 / 0

[Security Development] New message: "Re: Auth Cache is not flushed after logout"

by Harry Yan

JBoss development, A new message was posted in the thread "Auth Cache is not flushed after logout": http://community.jboss.org/message/529142#529142 Author : Harry Yan Profile : http://community.jboss.org/people/seekerYan Message: -------------------------------------------------------------- sorry for the late response, just came back from vacation. Yes I did in the same order as you did, but it failed due to the invalid session after the webAuthentication.logout() was called. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529142#529142

16 years, 1 month

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Maven plugin for JBossWS JAX-WS tools"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Maven plugin for JBossWS JAX-WS tools": http://community.jboss.org/message/529134#529134 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- http://community.jboss.org/docs/DOC-13542#Maven_Plugin http://community.jboss.org/docs/DOC-13543#Maven_Plugin -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529134#529134

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "JBDEPLOY-243 or change deployment's relative order"

by Ales Justin

JBoss development, A new message was posted in the thread "JBDEPLOY-243 or change deployment's relative order": http://community.jboss.org/message/529119#529119 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > They want a -properties.xml to be deployed as a -service.xml > but for the -properties to go first in the REAL stage > so it can set the system properties before the mbeans > are created. Currently we don't order components -- with this new feature we will have to, otherwise we cannot order deployments with multiple matchings. e.g. both -properties.xml and -service.xml in the same sub-deployment > NOTE: The setting of the relative order should be always > done, like the init() call. e.g. if the metadata > comes from manangement console rather than from the file. Based on what would an init() pick-up metadata and set the relative order? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529119#529119

16 years, 1 month

1
0
0 / 0

[EJB 3.0 Development] New message: "lookup for remote bean - failure"

by Yaron Levy

JBoss development, A new message was posted in the thread "lookup for remote bean - failure": http://community.jboss.org/message/529105#529105 Author : Yaron Levy Profile : http://community.jboss.org/people/reyaron Message: -------------------------------------------------------------- Hi, My problem is that for some reason, the path to my remote bean is being duplicated by the http://java.sun.com/javase/6/docs/api/javax/naming/InitialContext.html as you can see also in the exception: /my-app-ear-name/GeneralDao/my-app-ear-name/GeneralDao/remote why is that happening? How can I avoid this? I work with jboss-5.1.0.GA , http://www.javaranch.com/ 6.0.12 the way I do the lookup: Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); properties.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); properties.put(Context.PROVIDER_URL, "127.0.0.1:1099"); context = new InitialContext(properties); Object bean = context.lookup("my-app-ear-name/GeneralDao/remote"); The exeption: javax.naming.NamingException: Could not dereference object [Root exception is java.lang.RuntimeException: Exception while trying to locate proxy factory in JNDI, at key ProxyFactory/my-app-ear-name/GeneralDao/my-app-ear-name/GeneralDao/remote] at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1508) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:824) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) at javax.naming.InitialContext.lookup(InitialContext.java:392) at com.mycompany.util.TestServiceLocator.getRemote(TestServiceLocator.java:47) at com.mycompany.util.TestServiceLocator.getRemoteBean(TestServiceLocator.java:60) at com.mycompany.GeneralDaoTest.testMergeFindRemove(GeneralDaoTest.java:17) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.RuntimeException: Exception while trying to locate proxy factory in JNDI, at key ProxyFactory/my-app-ear-name/GeneralDao/my-app-ear-name/GeneralDao/remote at org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory.getProxyFactoryFromJNDI(ProxyObjectFactory.java:249) at org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory.getObjectInstance(ProxyObjectFactory.java:157) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1483) at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1500) ... 28 more Caused by: javax.naming.NameNotFoundException: ProxyFactory not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) at org.jnp.server.NamingServer.getObject(NamingServer.java:785) at org.jnp.server.NamingServer.lookup(NamingServer.java:396) at sun.reflect.GeneratedMethodAccessor280.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) 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) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142) at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) at org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory.getProxyFactoryFromJNDI(ProxyObjectFactory.java:240) my remote bean declaration: @Stateless public class GeneralDao implements GeneralDaoIfc, GeneralDaoIfcRemote{ .... } GeneralDaoIfcRemote: @Remote public interface GeneralDaoIfcRemote { ... } -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529105#529105

16 years, 1 month

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: Default remove timeout"

by jaikiran pai

JBoss development, A new message was posted in the thread "Default remove timeout": http://community.jboss.org/message/529066#529066 Author : jaikiran pai Profile : http://community.jboss.org/people/jaikiran Message: -------------------------------------------------------------- > jaikiran wrote: > > https://jira.jboss.org/jira/browse/EJBTHREE-2030 This is now fixed in EJB3 trunk. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529066#529066

16 years, 1 month

1
0
0 / 0

[JCA Development] New message: "Re: JBJCA-272 - Standalone validator tool"

by Jesper Pedersen

JBoss development, A new message was posted in the thread "JBJCA-272 - Standalone validator tool": http://community.jboss.org/message/529045#529045 Author : Jesper Pedersen Profile : http://community.jboss.org/people/jesper.pedersen Message: -------------------------------------------------------------- Proper separation of concerns -- see JBJCA-291. All resource adapters deployed will pass through the validator (of course if it is enabled). So that would be all the resource adapters in the test suite. The validator can also be used from the command line, and through Ant and Maven once implemented. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529045#529045

16 years, 1 month

1
0
0 / 0

[JCA Development] New message: "Re: JBJCA-272 - Standalone validator tool"

by Vicky Kak

JBoss development, A new message was posted in the thread "JBJCA-272 - Standalone validator tool": http://community.jboss.org/message/529042#529042 Author : Vicky Kak Profile : http://community.jboss.org/people/vickyk Message: -------------------------------------------------------------- Yes I could get things working when I run it from the top lovel directory. I do see couple of jboss-jca-validator related jars i.e jboss-jca-validator.jar and jboss-jca-validator-cli.jar. I don't think we should have two jars especially when the cli related jar is just having a Main class. Why not to have the Main class which is part of the cli related jar in the validator jar? Also where can we get the RAR's which are validated against the validator tool. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529042#529042

16 years, 1 month

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-dev-forums March 2010