July 2010 - jboss-user - Jboss List Archives

Re: [jboss-user] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration

by Flavia Rainone

Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion "Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/554183#554183 -------------------------------------------------------------- Making myself clearer. > Flavia Rainone wrote: > > *public* BeanDeploymentArchive loadBeanDeploymentArchive(Class<?> beanClass) > { > // collection to mark the archives we have already searched > Collection<Archive> searchedArchives = *new* HashSet<Archive>(); > // collection to mark the classpaths we have already searched > Collection<Classpath> searchedClasspaths = *new* HashSet<Classpath>(); > // TODO -- why the search? beanClass' ClassLoader should be mapped to Archive? > // need to throw an IllegalArgumentException if the Archive is not reachable from > // the archives contained in the archives of this deployment > Archive archive = findArchive(beanClass, archives, searchedArchives, searchedClasspaths); > *if* (archive == *null*) > > > Currently, findArchive method, invoked by loadBeanDeploymentArchive as shown above, walks through the Archive graph in order to find an Archive associated with the requested beanClass (i.e., an Archive that is associated with the same ClassLoader that loaded beanClass). If the Archive is not reachable in the graph, it means that we need to throw IllegalArgumentException. Ales suggested to replace the findArchive call by a lookup in a ClassLoader -> Archive map. That way, all I would need to do is looking up for the archive that corresponds to the beanClass CL. This is faster than walking through the Archive graph, but I wouldn't be able to know whether the Archive is reachable from the current Deployment or not, so I wouldn't be able to throw the IllegalArgumentException to point that beanClass is not visible to the current Deployment. Which way should I go? Should I forego the "is beanClass visible to this Deployment" check and follow Ales's suggestion, or should I keep things the way they are? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554183#554183] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders

by Kabir Khan

Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Benchmarking classloaders" To view the discussion, visit: http://community.jboss.org/message/554175#554175 -------------------------------------------------------------- The new simpler scenario has a 100 jars with 10 packages and 15 classes per package, one loader per jar. The tests are called SiblingVFSXXXBenchmarkTestCase and they run as follows: Use Loader1 to load all its own classes and those from Loader2 Use Loader2 to load all its own classes and those from Loader3 ... For the exact classloading setups I make Loader 1 import the module/packages exported by Loader2 etc. I run the tests individually using e.g. mvn install -Dtest=SiblingVFSImportPackageLoaderBenchmarkTestCase Running each test individually, I get these average results over 7 runs || || *Deploy (ms)* || *Load Classes (ms)* || | *Big ball of mud* | 1439 | 4485 | | *Package* | 1321 | 4880 | | *Module* | 1461 | 4874 | The code lives in svn under https://svn.jboss.org/repos/jbossas/projects/cl-benchmark/trunk https://svn.jboss.org/repos/jbossas/projects/cl-benchmark/trunk Each family of tests uses its own AbstractTestSetCreator implementation which generates jars under their own directory, e.g. ThreeDeepTestSetCreator and SiblingTestCreator. The tests currently -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554175#554175] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [jBPM] - REST interface for JBPM

by Jon Kranes

Jon Kranes [http://community.jboss.org/people/jkranes] replied to the discussion "REST interface for JBPM" To view the discussion, visit: http://community.jboss.org/message/554174#554174 -------------------------------------------------------------- I just ran across this post and wish I had found it a few months ago, as I've already done much the same thing as you for my own project. My REST API is not nearly as complete, as I've been building it out on an as-needed basis as we have added features to the application. My intent was not to create a full REST version of JBPM but rather a REST API to a specific JBPM-based application. In practice however many of the REST API methods have turned out to be pretty much the same as yours -- i.e. straight passthroughs to underlying JBPM engine. I am also using JAXB but in a somewhat different manner. I am letting JAXB generate java classes from my schema and then using conversion code to translate between the JAXB generated classes and the JBPM classes. I am using Spring Framework 3.0 web MVC features, which integrate both the JAXB marshalling and also Jackson JAXB-aware JSON marshalling, so the application will switch from XML to JSON responses just by changing the 'Accept' header of the request. I will have a look at your implementation in more detail and see if there are any areas where we might share code or technical info. Thanks for posting your code! -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554174#554174] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Benchmarking classloaders" To view the discussion, visit: http://community.jboss.org/message/554172#554172 -------------------------------------------------------------- > A customer bundle uses a product delivered as OSGi bundles. The product has an API and an Implementation. The product uses some services from the compendium which are implemented by a number of util bundles. Voila - that's the test case structure. This doesn't sound like it would need 3-level hierarchy, but rather just 3 properly wired bundles at the same level. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554172#554172] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [jBPM] - How to check in jBPM 4.3 that java activity returned null?

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "How to check in jBPM 4.3 that java activity returned null?" To view the discussion, visit: http://community.jboss.org/message/554168#554168 -------------------------------------------------------------- Try latest version of jBPM - 4.4. I recall there were some issues related to problem you described and that should be fixed. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554168#554168] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [JBoss Messaging] - Queue\Topic not bound

by Sudhakar Pandey

Sudhakar Pandey [http://community.jboss.org/people/spandey1982] replied to the discussion "Queue\Topic not bound" To view the discussion, visit: http://community.jboss.org/message/554165#554165 -------------------------------------------------------------- Thanks Yong for your response. The issue got resolved after trying a fresh installation. After little more analysis, I found that we don't actually need the new JMSProvider and default JMSProvider is more than sufficient for me. Issue is resolved now. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554165#554165] Start a new discussion in JBoss Messaging at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [JBoss Messaging] - JBOSS 5.1 "MessageConsumer.receiveNoWait(...)" strange problem

by Tyronne Wickramarathne

Tyronne Wickramarathne [http://community.jboss.org/people/bershath27] replied to the discussion "JBOSS 5.1 "MessageConsumer.receiveNoWait(...)" strange problem" To view the discussion, visit: http://community.jboss.org/message/554162#554162 -------------------------------------------------------------- http://community.jboss.org/wiki/JBMReceiveNoWait http://community.jboss.org/wiki/JBMReceiveNoWait -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554162#554162] Start a new discussion in JBoss Messaging at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [Beginner's Corner] - The AJP connector, started by default on port 8109

by Roberto Marcenaro

Roberto Marcenaro [http://community.jboss.org/people/rmarcenaro] replied to the discussion "The AJP connector, started by default on port 8109" To view the discussion, visit: http://community.jboss.org/message/554158#554158 -------------------------------------------------------------- Thank you very much for your solution. But if you need to be configured ServiceBindingManager, could force the port 8009 and have enabled ServiceBindingManager? Thanks in advance, Rto. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554158#554158] Start a new discussion in Beginner's Corner at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

[jBPM] - How to check in jBPM 4.3 that java activity returned null?

by Constantine Kulak

Constantine Kulak [http://community.jboss.org/people/ity75303] created the discussion "How to check in jBPM 4.3 that java activity returned null?" To view the discussion, visit: http://community.jboss.org/message/554156#554156 -------------------------------------------------------------- Hello, is there any way to store null value in a variable and then check it for being empty? I'm trying to do it like this: <java method="someMethod" name="Java" var="variable"> <transition to="Decision" /> </java> <decision name="Decision"> <transition to="Variable is empty"> <condition expr="#{empty variable}" /> </transition> <transition to="Default" /> </decision> here xxx.Test.someMethod returns null, and +decision+ throws an exception: org.jbpm.api.JbpmException: script evaluation error: javax.el.PropertyNotFoundException: Cannot find property variable org.jbpm.pvm.internal.script.ScriptManager.evaluate(ScriptManager.java:130) org.jbpm.pvm.internal.script.ScriptManager.evaluate(ScriptManager.java:118) org.jbpm.pvm.internal.script.ScriptManager.evaluateExpression(ScriptManager.java:90) org.jbpm.pvm.internal.model.ExpressionCondition.evaluate(ExpressionCondition.java:41) org.jbpm.jpdl.internal.activity.DecisionConditionActivity.findTransitionUsingConditions(DecisionConditionActivity.java:61) org.jbpm.jpdl.internal.activity.DecisionConditionActivity.execute(DecisionConditionActivity.java:46) org.jbpm.jpdl.internal.activity.DecisionConditionActivity.execute(DecisionConditionActivity.java:42) org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60) org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:656) org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:616) org.jbpm.pvm.internal.model.ExecutionImpl.start(ExecutionImpl.java:217) org.jbpm.pvm.internal.cmd.StartProcessInstanceCmd.execute(StartProcessInstanceCmd.java:61) org.jbpm.pvm.internal.cmd.StartProcessInstanceCmd.execute(StartProcessInstanceCmd.java:37) org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42) org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54) org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53) org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40) org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55) org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43) org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceById(ExecutionServiceImpl.java:58) org.jbpm.integration.console.ProcessManagementImpl.newInstance(ProcessManagementImpl.java:151) org.jboss.bpm.console.server.FormProcessingFacade.startProcessWithUI(FormProcessingFacade.java:202) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:117) org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:260) org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:232) org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:166) org.jboss.resteasy.core.DispatcherUtilities.getJaxrsResponse(DispatcherUtilities.java:142) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:173) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:93) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:68) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.jboss.bpm.console.server.util.GWTJsonFilter.doFilter(GWTJsonFilter.java:59) So I guess it doesn't create a variable if null is returned. To overcome this I'm returning List instead of a single object and check whether it is empty or not, but it looks ugly. Is there any better way to check for null values returned by +java+ activity? Thanks in advance for your suggestions. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554156#554156] Start a new discussion in jBPM at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 months

1
0
0 / 0

Re: [jboss-user] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration

by Flavia Rainone

Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion "Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/554152#554152 -------------------------------------------------------------- This is about the TODO comment that Ales added to DeploymentImpl: public BeanDeploymentArchive loadBeanDeploymentArchive(Class<?> beanClass) { // collection to mark the archives we have already searched Collection<Archive> searchedArchives = new HashSet<Archive>(); // collection to mark the classpaths we have already searched Collection<Classpath> searchedClasspaths = new HashSet<Classpath>(); // TODO -- why the search? beanClass' ClassLoader should be mapped to Archive? // need to throw an IllegalArgumentException if the Archive is not reachable from // the archives contained in the archives of this deployment Archive archive = findArchive(beanClass, archives, searchedArchives, searchedClasspaths); if (archive == null) I put a temporary answer right below the TODO as you can see. It is undeniable that Ales' suggested approach is much simpler and faster than searching for the Archive in the graph. The problem is that we need to throw the IllegalArgumentException whenever the Archive is not reachable. I'm wondering if that exception is really necessary, as IMHO the gains of following Ales suggestion outweight the fact that we are not checking for Archive visibility. So, in order for this exception to happen, we would need to assume that Weld is asking for a bean loaded by a ClassLoader that is not visible to the ClassLoader that loaded the current deployment. Would this scenario ever happen? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/554152#554152] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 9 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-user July 2010