[JNDI and Naming] - JNDI Lookup in multi-classloader environment
by praveenbalaji
Software Version: JBoss Client from JBoss 4.2.2 drop.
I'm trying to do a JNDI lookup of a JMS Connection Factory in my component. This is a plain Java component. I am trying to do a JNDI lookup from a plain Java object. Several of my componnets can run in the same JVM under different classloaders. I'm loading jboss client jars in each of these component classloaders such that each classloader has its own copy of client jars. Each component does a JNDI lookup for the same named object.
The second (and consequent) component that does a lookup fails with a ClassCastException. The second component is looking up an object created by the first component. Though the classname matches, the classloader is different and hence the ClassCastException.
| caused by: javax.naming.NamingException: Could not dereference object [Root exception is java.lang.ClassCastException: org.jboss.naming.LinkRefPair]
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1298)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:763)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| ...
| ...
| at sun.rmi.transport.Transport$1.run(Transport.java:153)
| at java.security.AccessController.doPrivileged(Native Method)
| at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
| at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
| at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.ClassCastException: org.jboss.naming.LinkRefPair
| at org.jboss.naming.LinkRefPairObjectFactory.getObjectInstance(LinkRefPairObjectFactory.java:66)
| at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
| at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1273)
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1290)
| ... 70 more
|
|
I looked at the JBoss source and the object returned by the lookup at org.jnp.interfaces.NamingContext.lookup(javax.naming.Name) (line 667) is fetching the offending object.
Is there a way to provide isolation at component level in the client code? I see there is a way to do it for components (enterprise applications) running under the J2EE container as stated at http://www.jboss.org/community/wiki/classloadingconfiguration
Please note that unfortunately for me, it is not an option for me to load the jboss client jars under the JRE's ext classloader which is the ancestor of all my component classloaders. I have to provide isolation at the component level.
Thanks
Praveen
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255132#4255132
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255132
16 years, 7 months
[JBoss Portal Users] - Re: How to obtain the current portlet instance?
by ebephil
It took more two afternoons, but I found a solution.
The trick is to use the PortalObjectContainer to obtain the current PortalObject from the current PortalNode.
Anyway, here's my code:
| private Instance getCurrentInstance() {
| PortalNodeImpl node = Navigation.getCurrentNode();
| if (node.getType() != PortalNode.TYPE_WINDOW) {
| return null;
| }
| PortalObjectId id = node.getObjectId();
| Window window = (Window) getPortalObjectContainer().getObject(id);
| PortletContent pc = (PortletContent) window.getContent();
| return getInstanceContainer().getDefinition(pc.getInstanceRef());
| }
|
| @Override
| public boolean writePref(String prefKey, String newPrefValue) {
| Instance currentInstance = getCurrentInstance();
|
| if (null == currentInstance) {
| logger.error("<-- writePref() Current Instance is null, stopping.");
| return false;
| }
|
| try {
| List<PropertyChange> changeList = new ArrayList<PropertyChange>();
| PropertyChange change = PropertyChange.newUpdate(prefKey,
| newPrefValue);
| changeList.add(change);
|
| PropertyChange[] changeArray = changeList
| .toArray(new PropertyChange[changeList.size()]);
|
| logger.info("--> save()", " setting properties");
| currentInstance.setProperties(changeArray);
|
| } catch (PortletInvokerException e) {
| logger.error(e.toString());
| return false;
| } catch (Exception e) {
| logger.error(e.toString());
| return false;
| } catch (Throwable t) {
| logger.error(t.toString());
| return false;
| }
|
| return true;
| }
|
You need to inject the InstanceContainer and PortalObjectContainer via the jboss-portlet.xml:
| <portlet-app>
| ...
| <service>
| <service-name>PortalObjectContainer</service-name>
| <service-class>org.jboss.portal.core.model.portal.PortalObjectContainer</service-class>
| <service-ref>portal:container=PortalObject</service-ref>
| </service>
| <service>
| <service-name>InstanceContainer</service-name>
| <service-class>org.jboss.portal.core.model.instance.InstanceContainer</service-class>
| <service-ref>:container=Instance</service-ref>
| </service>
| ...
| </portlet-app>
|
Then you can access them in your beans, I do it by injecting them via faces-config.xml:
| <faces-config>
| ...
| <managed-bean>
| <managed-bean-name>portletPreferencesHelper</managed-bean-name>
| <managed-bean-class>package.foo.PortletPreferencesHelperJBossImpl</managed-bean-class>
| <managed-bean-scope>session</managed-bean-scope>
| <managed-property>
| <property-name>instanceContainer</property-name>
| <value>#{applicationScope.InstanceContainer}</value>
| </managed-property>
| <managed-property>
| <property-name>portalObjectContainer</property-name>
| <value>#{applicationScope.PortalObjectContainer}</value>
| </managed-property>
| </managed-bean>
| ...
| </faces-config>
|
And now I finally have InstancePreferences capsuled in a Bean. Btw: Reading the PortletPreferences works the usual way. As I never write user-level PortletPreferences, the Portal always falls back to the InstancePreferences.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255118#4255118
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255118
16 years, 7 months
[jBPM Users] - Re: workflow design about wait states
by mmusaji
I've added...
| processInstance = executionService.findProcessInstanceById(processInstanceId);
|
| Execution executionInFour = processInstance.findActiveExecutionIn("custom four");
| assertNotNull(executionInFour);
| processInstance = executionService.signalExecutionById(executionInFour.getId());
|
...to my unit test.
Now I'm not getting any exceptions and the output looks like this:
| 15:14:34,393 FIN | [BaseJbpmTestCase] === starting testProcess =============================
| 15:14:34,518 FIN | [BaseJbpmTestCase] using ProcessEngine 78236
| log4j:WARN No appenders could be found for logger (org.hibernate.cfg.Environment).
| log4j:WARN Please initialize the log4j system properly.
| 15:14:35,675 FIN | [ProcessDefinitionImpl] creating new execution for process 'process'
| 15:14:35,675 FIN | [DefaultIdGenerator] generated execution id process.277
| 15:14:35,675 FIN | [ExecuteActivity] executing activity(16408563)
| 15:14:35,675 FIN | [ExecuteActivity] executing activity(custom one)
| Executing
| custom one
| 15:14:35,690 FIN | [Signal] signalling activity(custom one), signalName=null
| 15:14:35,690 FIN | [ExecuteActivity] executing activity(fork)
| 15:14:35,706 FIN | [DefaultIdGenerator] generated execution id process.277.custom two
| 15:14:35,706 FIN | [ExecutionImpl] created execution[process.277.custom two]
| 15:14:35,706 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 15:14:35,706 INF | [JobExecutorThread] starting...
| 15:14:35,706 INF | [JobExecutorThread] starting...
| 15:14:35,706 INF | [JobExecutorThread] starting...
| 15:14:35,706 INF | [DispatcherThread] starting...
| 15:14:35,706 FIN | [DefaultIdGenerator] generated execution id process.277.custom three
| 15:14:35,706 FIN | [ExecutionImpl] created execution[process.277.custom three]
| 15:14:35,706 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 15:14:35,722 FIN | [AcquireJobsCmd] locking jobs []
| 15:14:35,722 FIN | [GetNextDueDateCmd] getting next due date...
| 15:14:35,722 FIN | [GetNextDueDateCmd] next due date is null
| 15:14:35,722 FIN | [DispatcherThread] skipped wait because new message arrived
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 15:14:35,722 FIN | [AcquireJobsCmd] locking jobs [390]
| 15:14:35,722 FIN | [DispatcherThread] pushing jobs on the queue [390]
| 15:14:35,722 FIN | [DispatcherThread] added jobs [390] to the queue
| 15:14:35,722 FIN | [JobExecutorThread] took job(s) [390] from queue
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 15:14:35,722 FIN | [AcquireJobsCmd] locking jobs [391]
| 15:14:35,722 FIN | [DispatcherThread] pushing jobs on the queue [391]
| 15:14:35,722 FIN | [DispatcherThread] added jobs [391] to the queue
| 15:14:35,722 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 15:14:35,737 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[390]...
| 15:14:35,737 FIN | [AcquireJobsCmd] locking jobs []
| 15:14:35,737 FIN | [GetNextDueDateCmd] getting next due date...
| 15:14:35,737 FIN | [GetNextDueDateCmd] next due date is null
| 15:14:35,737 FIN | [DispatcherThread] DispatcherThread will wait for max 600ms on org.jbpm.pvm.internal.jobexecutor.JobExecutor@cd4544
| 15:14:35,737 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[390]...
| 15:14:35,784 FIN | [JobExecutorThread] took job(s) [391] from queue
| Executing
| custom two
| Executing
| custom two
| 15:14:35,784 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[391]...
| 15:14:35,784 FIN | [ExecuteActivity] execution[process.277.custom two] executes activity(custom two)
| 15:14:35,784 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 15:14:35,784 FIN | [ExecuteJobCmd] executed job ExecuteActivityMessage[390]
| 15:14:35,800 FIN | [ExecuteActivity] execution[process.277.custom two] executes activity(custom two)
| 15:14:35,800 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 15:14:35,800 FIN | [ExecuteJobCmd] executed job ExecuteActivityMessage[390]
| 15:14:35,800 FIN | [ExecuteActivity] execution[process.277.custom three] executes activity(custom three)
| 15:14:35,800 FIN | [JobExecutorMessageSession] sending message ExecuteActivityMessage
| 15:14:35,800 FIN | [ExecuteJobCmd] executed job ExecuteActivityMessage[391]
| 15:14:35,800 FIN | [DispatcherThread] DispatcherThread woke up
| 15:14:35,800 FIN | [AcquireJobsCmd] start querying first acquirable job...
| Executing
| custom three
| 15:14:35,815 FIN | [AcquireJobsCmd] locking jobs [393, 394]
| 15:14:35,815 FIN | [DispatcherThread] pushing jobs on the queue [393, 394]
| 15:14:35,815 FIN | [DispatcherThread] added jobs [393, 394] to the queue
| 15:14:35,815 FIN | [AcquireJobsCmd] start querying first acquirable job...
| 15:14:35,815 FIN | [AcquireJobsCmd] locking jobs []
| 15:14:35,815 FIN | [JobExecutorThread] took job(s) [393, 394] from queue
| 15:14:35,815 FIN | [GetNextDueDateCmd] getting next due date...
| 15:14:35,815 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[393]...
| 15:14:35,815 FIN | [GetNextDueDateCmd] next due date is null
| 15:14:35,815 FIN | [DispatcherThread] DispatcherThread will wait for max 600ms on org.jbpm.pvm.internal.jobexecutor.JobExecutor@cd4544
| 15:14:35,815 FIN | [ExecuteActivity] execution[process.277.custom two] executes activity(join)
| 15:14:35,815 FIN | [ExecuteJobCmd] executed job ExecuteActivityMessage[393]
| 15:14:35,831 FIN | [ExecuteJobCmd] executing job ExecuteActivityMessage[394]...
| 15:14:35,831 FIN | [ExecuteActivity] execution[process.277.custom three] executes activity(join)
| 15:14:35,831 FIN | [ExecutionImpl] execution[process.277.custom two] ends
| 15:14:35,831 FIN | [ExecutionImpl] execution[process.277.custom three] ends
| 15:14:35,831 FIN | [ExecuteActivity] executing activity(custom four)
| Executing
| custom four
| 15:14:35,831 FIN | [ExecuteJobCmd] executed job ExecuteActivityMessage[394]
| 15:14:35,862 FIN | [ExecuteJobCmd] job 390 no longer exists
| 15:14:35,862 FIN | [ExecuteJobCmd] job 391 no longer exists
| 15:14:35,862 FIN | [Signal] signalling activity(custom four), signalName=null
| 15:14:35,862 FIN | [ExecuteActivity] executing activity(end)
| 15:14:35,893 FIN | [DbSessionImpl] deleting history process instance process.277
| 15:14:35,909 FIN | [DbSessionImpl] deleting process instance process.277
| 15:14:35,909 FIN | [DeleteDeploymentCmd] deleting deployment 124
| 15:14:35,940 FIN | [BaseJbpmTestCase] === ending testProcess =============================
|
Still uncertain if my process has ended correctly. Attempting to put this in to my "proper" workflow with more custom nodes is still showing errors.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255110#4255110
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255110
16 years, 7 months
[jBPM Users] - Query HistoryService for task assignee and name?
by LMarinkov
I am using jBPM 4.1 and tried to write a unit test that queries the history service using the task assignee and name.
First i looked at the sources of jBPM and searched for tests that are performing a similar query. Unfortunately the only test related to history task assignee was org.jbpm.test.history.HistoryTaskAssigneeTest shown below and the test didn't use the assignee information to perform the query:
/*
| * JBoss, Home of Professional Open Source
| * Copyright 2005, JBoss Inc., and individual contributors as indicated
| * by the @authors tag. See the copyright.txt in the distribution for a
| * full listing of individual contributors.
| *
| * This is free software; you can redistribute it and/or modify it
| * under the terms of the GNU Lesser General Public License as
| * published by the Free Software Foundation; either version 2.1 of
| * the License, or (at your option) any later version.
| *
| * This software is distributed in the hope that it will be useful,
| * but WITHOUT ANY WARRANTY; without even the implied warranty of
| * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
| * Lesser General Public License for more details.
| *
| * You should have received a copy of the GNU Lesser General Public
| * License along with this software; if not, write to the Free
| * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
| * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
| */
| package org.jbpm.test.history;
|
| import org.jbpm.api.Execution;
| import org.jbpm.api.history.HistoryActivityInstance;
| import org.jbpm.test.JbpmTestCase;
|
|
| /**
| * @author Tom Baeyens
| */
| public class HistoryTaskAssigneeTest extends JbpmTestCase {
|
| public void testHistoryTaskAssignee() {
| deployJpdlXmlString(
| "<process name='TaskAssignee'>" +
| " <start>" +
| " <transition to='review' />" +
| " </start>" +
| " <task name='review' " +
| " assignee='johndoe'>" +
| " <transition to='wait' />" +
| " </task>" +
| " <state name='wait'/>" +
| "</process>"
| );
|
| executionService.startProcessInstanceByKey("TaskAssignee");
|
| HistoryActivityInstance historyActivityInstance = historyService
| .createHistoryActivityInstanceQuery()
| .uniqueResult();
|
| }
|
| }
|
The current implementation of the HistoryTaskQuery allows querying using the assignee but not the name of the task. To find out the name for the task i decided to make a HistoryActivityInstanceQuery using the executiondid that will be delivered by the HistoryTaskQuery. To my surprise this didn't work. The HistoryActivityInstanceQuery delivered 3 HistoryActivityInstances instead of 1. So it is not possible to figure out the name of the task that was performed by the assignee. The unit test is shown below:
package com.cg.wfl.jbpm.examples.wfl_examples.history;
|
| import java.util.List;
|
| import org.jbpm.api.Execution;
| import org.jbpm.api.history.HistoryActivityInstance;
| import org.jbpm.api.history.HistoryTask;
| import org.jbpm.test.JbpmTestCase;
|
| public class HistoryTaskAssigneeTest extends JbpmTestCase {
| public void testHistoryTaskAssignee() {
| deployJpdlXmlString(
| "<process name='TaskAssigneeTest'>" +
| " <start>" +
| " <transition to='a' />" +
| " </start>" +
| " <task name='a' assignee='mary'>" +
| " <transition name='toB' to ='b' />" +
| " </task>" +
| " <task name='b' assignee='alex'>" +
| " <transition name='toC' to ='c' />" +
| " </task>" +
| " <task name='c' assignee='mary'>" +
| " <transition name='toEnd' to ='end' />" +
| " </task>" +
| " <end name='end' />" +
| "</process>"
| );
| Execution execution = executionService.startProcessInstanceByKey("TaskAssigneeTest");
|
| String taskId = taskService.createTaskQuery().uniqueResult().getId();
| taskService.completeTask(taskId);
| taskId = taskService.createTaskQuery().uniqueResult().getId();
| taskService.completeTask(taskId);
| taskId = taskService.createTaskQuery().uniqueResult().getId();
| taskService.completeTask(taskId);
|
| assertNull("execution "+execution.getId()+" should not exist",
| executionService.findExecutionById(execution.getId()));
|
| List<HistoryTask> historyTasks = historyService.createHistoryTaskQuery().
| assignee("mary").list();
| assertEquals(2, historyTasks.size());
|
| historyTasks = historyService.createHistoryTaskQuery().
| assignee("alex").list();
| assertEquals(1, historyTasks.size());
|
| // Try to find out the name of the task for the first task with assignee mary
| String executionId = historyTasks.get(0).getExecutionId();
| List<HistoryActivityInstance> historyActivities = historyService.createHistoryActivityInstanceQuery().
| executionId(executionId).list();
| // The expectation is 1 entry in the list, but the list contains 3 entries
| // It is not possible to link the HistoryTask to the HistoryActivityInstance
| // using the executionId!
| assertEquals(1, historyActivities.size());
| }
| }
|
I found also the following jira issues that references task history details and hope that the problem with the task name will be also considered.
https://jira.jboss.org/jira/browse/JBPM-2442
Any help or comments are welcomed.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255107#4255107
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255107
16 years, 7 months
[jBPM Users] - command service
by sravyts
This might be a very easy question to solve , but I can't find the solution (or maybe I'm completely missing the ball here...)
I'm trying to create my own custom query (MyQuery which extends AbstractQuery).
Now is my problem: how can I execute this query?
I was thinking calling processEngine.execute(query) (since AbstractQuery implements the Command interface), but I can't succeed in getting a processEngine (I'm using spring integration)
If I autowire processengine I get the following error:
| Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [org.jbpm.api.ProcessEngine] is defined: expected single matching bean but found 2: [jbpmConfiguration, processEngine]
|
This is my spring configuration:
| <bean id="jbpmConfiguration" class="org.jbpm.pvm.internal.cfg.SpringConfiguration">
| <constructor-arg value="org/mypackage/jbpm.cfg.xml" />
| </bean>
|
| <bean id="processEngine" factory-bean="jbpmConfiguration" factory-method="buildProcessEngine" />
| <bean id="repositoryService" factory-bean="processEngine" factory-method="getRepositoryService" />
| <bean id="executionService" factory-bean="processEngine" factory-method="getExecutionService" />
| <bean id="historyService" factory-bean="processEngine" factory-method="getHistoryService" />
| <bean id="taskService" factory-bean="processEngine" factory-method="getTaskService" />
| <bean id="identityService" factory-bean="processEngine" factory-method="getIdentityService" />
|
| <bean id="queryExecutor" class="org.mypackage.QueryExecutor" />
|
|
|
And QueryExecutor :
| public class QueryExecutor
| {
| @Autowired
| ProcessEngine processEngine
|
| public List query(MyQuery query){
| return processEngine.execute(query);
| }
| }
|
Is there another way for executing commands using spring integration?
Or aren't we supposed to execute commands?
Wkr,
Sofie
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255093#4255093
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255093
16 years, 7 months