Re: [jboss-user] [JBoss Web Services CXF] - XTS tests broken in AS trunk after switch to CXF stack in 3.3.0
by Andrew Dinn
Andrew Dinn [http://community.jboss.org/people/adinn] replied to the discussion
"XTS tests broken in AS trunk after switch to CXF stack in 3.3.0"
To view the discussion, visit: http://community.jboss.org/message/547327#547327
--------------------------------------------------------------
Ok, I wrote a little byteman script to trace calls to EndpointAssociation.setEndpoint and EndpointAssociation.getEndpoint:
> # rules to track calls to getEndpoint and setEndpoint in CXF code
> #
>
> RULE trace setEndpoint
> CLASS EndpointAssociation
> METHOD setEndpoint
> IF TRUE
> DO trace("foo", "setEndpoint(" + $1.getName() + ")\n" + formatStack())
> ENDRULE
>
> RULE trace getEndpoint
> CLASS EndpointAssociation
> METHOD getEndpoint
> AT RETURN
> IF TRUE
> DO trace("foo", "getEndpoint() ==> " + $!.getName() + "\n" + formatStack())
> ENDRULE
When I ran my tests with this script installed I got a few cases where successive gets and sets were using different endpoints. Here is a dump of the (filtered and reformatted) trace output:
> setEndpoint(Interop11ATParticipantService)
> Stack trace for thread http-127.0.0.1-8080-3
> getEndpoint() ==> Interop11ATParticipantService
> Stack trace for thread default-workqueue-1 // n.b. worker 1 from participant executor
>
> setEndpoint(ActivationService)
> Stack trace for thread http-127.0.0.1-8080-4
> getEndpoint() ==> ActivationService
> Stack trace for thread http-127.0.0.1-8080-4
>
>
> setEndpoint(RegistrationService)
> Stack trace for thread http-127.0.0.1-8080-4
> getEndpoint() ==> RegistrationService
> Stack trace for thread http-127.0.0.1-8080-4
>
> setEndpoint(CompletionCoordinator)
> Stack trace for thread http-127.0.0.1-8080-4
> getEndpoint() ==> CompletionCoordinator
> Stack trace for thread default-workqueue-1
>
> setEndpoint(CompletionInitiator)
> Stack trace for thread http-127.0.0.1-8080-5
> getEndpoint() ==> CompletionInitiator
> Stack trace for thread default-workqueue-2 // n.b. worker 2 from initiator executor
>
> setEndpoint(Interop11ATInitiatorService)
> Stack trace for thread http-127.0.0.1-8080-6
> getEndpoint() ==> Interop11ATInitiatorService
> Stack trace for thread default-workqueue-2
>
>
>
> . . .
>
>
>
> setEndpoint(RegistrationService)
> Stack trace for thread http-127.0.0.1-8080-9
> getEndpoint() ==> RegistrationService
> Stack trace for thread http-127.0.0.1-8080-9
>
> setEndpoint(RegistrationService)
> Stack trace for thread http-127.0.0.1-8080-9
> getEndpoint() ==> RegistrationService
> Stack trace for thread http-127.0.0.1-8080-9
>
> setEndpoint(Interop11ATInitiatorService) // hmm, call is to initiator service
> Stack trace for thread http-127.0.0.1-8080-9
> getEndpoint() ==> Interop11ATParticipantService
> Stack trace for thread default-workqueue-1 // oops wrong worker and endpoint!
>
>
> setEndpoint(ActivationService)
> Stack trace for thread http-127.0.0.1-8080-9
> getEndpoint() ==> ActivationService
> Stack trace for thread http-127.0.0.1-8080-9
>
> setEndpoint(Interop11ATParticipantService) // hmm, call is participant service
> Stack trace for thread http-127.0.0.1-8080-5
> getEndpoint() ==> Interop11ATInitiatorService
> Stack trace for thread default-workqueue-2 // wrong worker and endpoint again!
>
> setEndpoint(ActivationService)
> Stack trace for thread http-127.0.0.1-8080-5
> getEndpoint() ==> ActivationService
> Stack trace for thread http-127.0.0.1-8080-5
>
> setEndpoint(Interop11ATParticipantService)
> Stack trace for thread http-127.0.0.1-8080-8
> getEndpoint() ==> Interop11ATParticipantService
> Stack trace for thread default-workqueue-3
> . . .
So, worker thread 1 was added under a call to the participant service and hence has this endpoint in its inherited therad local. However it appears to get reused to handle the initiator calls later. How so? I added some trace rules to see what exector was being used:
> . .
>
> setEndpoint(jboss.ws:context=interop11,endpoint=Interop11ATParticipantService)
> Stack trace for thread http-127.0.0.1-8080-3
> getExecutor() ==> org.apache.cxf.workqueue.AutomaticWorkQueueImpl@16c8373 [queue size: 0, max size: 256, threads: 0, active threads: 0, low water mark: 5, high water mark: 25]
> Stack trace for thread http-127.0.0.1-8080-3
> getEndpoint() ==> jboss.ws:context=interop11,endpoint=Interop11ATParticipantService
> Stack trace for thread default-workqueue-1
> . . .
>
> setEndpoint(jboss.ws:context=interop11,endpoint=Interop11ATInitiatorService)
> Stack trace for thread http-127.0.0.1-8080-6
> getExecutor() ==> org.apache.cxf.workqueue.AutomaticWorkQueueImpl@16c8373 [queue size: 0, max size: 256, threads: 1, active threads: 1, low water mark: 5, high water mark: 25]
> Stack trace for thread http-127.0.0.1-8080-6
> getEndpoint() ==> jboss.ws:context=interop11,endpoint=Interop11ATInitiatorService
> Stack trace for thread default-workqueue-2
> setEndpoint(jboss.ws:context=interop11,endpoint=Interop11ATParticipantService)
> Stack trace for thread http-127.0.0.1-8080-3
> getExecutor() ==> org.apache.cxf.workqueue.AutomaticWorkQueueImpl@16c8373 [queue size: 0, max size: 256, threads: 2, active threads: 0, low water mark: 5, high water mark: 25]
> Stack trace for thread http-127.0.0.1-8080-3
> getEndpoint() ==> jboss.ws:context=interop11,endpoint=Interop11ATParticipantService
> Stack trace for thread default-workqueue-3
I added some more trace rules to see what is going on inside getExecutor:
> RULE trace getExecutor
> CLASS ContextUtils
> METHOD getExecutor
> AT RETURN
> IF TRUE
> DO traceln("foo", "getExecutor() ==> " + $!)
> ENDRULE
>
>
>
> RULE trace getExecutor internal
> CLASS ContextUtils
> METHOD getExecutor
> AFTER CALL getNamedWorkQueue
> IF TRUE
> DO traceln("foo", "getExecutor called getNamedWorkQueue")
> ENDRULE
>
> RULE trace getExecutor internal 2
> CLASS ContextUtils
> METHOD getExecutor
> AFTER CALL getAutomaticWorkQueue
> IF TRUE
> DO traceln("foo", "getExecutor called getAutomaticWorkQueue")
> ENDRULE
>
> RULE trace getExecutor internal 3
> CLASS ContextUtils
> METHOD getExecutor
> AFTER CALL getInstance
> IF TRUE
> DO traceln("foo", "getExecutor called getInstance")
> ENDRULE
This first rule prints the return value on the stack ($!) when getExecutor is about to return i.e. at the point where the original handler thread is queueing the runnable to execute the handed off message. The trace output reveals that the same executor is being used for both endpoints.
This appears to be because an executor is created per service. When the service has multiple endpoints then threads added to the pool can inherit an endpont at create but later be given jobs to run which are associated with one of the other endpoints.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547327#547327]
Start a new discussion in JBoss Web Services CXF at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[EJB 3.0] - jboss.xml can't read properties set in system-properties.xml
by Fred Bricon
Fred Bricon [http://community.jboss.org/people/fbricon] created the discussion
"jboss.xml can't read properties set in system-properties.xml"
To view the discussion, visit: http://community.jboss.org/message/547322#547322
--------------------------------------------------------------
Hi,
I'm trying to listen to a pop3 inbox from a JBoss AS 5.1 server. A (seam) mail listener configured in ejbproject.jar/META-INF/jboss.xml
{code:xml}
<jboss>
<enterprise-beans>
<message-driven>
<ejb-name>SomeMailService</ejb-name>
<activation-config>
<activation-config-property>
<activation-config-property-name>mailServer</activation-config-property-name>
<activation-config-property-value>${mail.receiver.mailServer}</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>port</activation-config-property-name>
<activation-config-property-value>${mail.receiver.port}</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>debug</activation-config-property-name>
<activation-config-property-value>${mail.receiver.debug}</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>mailFolder</activation-config-property-name>
<activation-config-property-value>${mail.receiver.mailFolder}</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>storeProtocol</activation-config-property-name>
<activation-config-property-value>${mail.receiver.storeProtocol}</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>flush</activation-config-property-name>
<activation-config-property-value>${mail.receiver.flush}</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>userName</activation-config-property-name>
<activation-config-property-value>${mail.receiver.userName}</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>password</activation-config-property-name>
<activation-config-property-value>${mail.receiver.password}</activation-config-property-value>
</activation-config-property>
</activation-config>
<resource-adapter-name>mail-ra.rar</resource-adapter-name>
</message-driven>
</enterprise-beans>
{code}
The properties are defined in ${JBOSS_HOME}/server/default/conf/mail.receiver.properties and loaded via ${JBOSS_HOME}/server/default/deploy/system-properties.xml
{code:xml}
<mbean code="org.jboss.varia.property.SystemPropertiesService"
name="jboss:type=Service,name=SystemProperties">
<attribute name="URLList">
./conf/mail.receiver.properties
</attribute>
</mbean>
{code}
Upon server startup, properties are correctly loaded :
{code}
12:00:07,902 INFO [SystemPropertiesService] Loaded system properties from: file:/P:/opt/JBoss/jboss-as-5.0.1.GA-jdk6/server/default/conf/mail.receiver.properties
{code}
BUT, it seems the mailListener isn't aware of that fact :
{code}12:15:22,321 ERROR [MailActivation] Failed to execute folder check, spec=MailActivationSpec(mailServer=${mail.receiver.server}, storeProtocol=${mail.receiver.storeProtocol}, mailFolder=${mail.receiver.mailFolder}, pollingInterval=60000, messageSelector=null, userName=${mail.receiver.userName}, maxMessages=1, debug=false, starttls=false, port=0){code}
I've checked in another class, the system properties are actually loaded :
<code>System.err.println("${mail.receiver.mailFolder}:" + System.getProperty("mail.receiver.mailFolder"));</code> correctly returns INBOX
Setting properties via <attribute name="Properties"> in system-properties doesn't work either.
Passing properties from the command line work as expected ( -Dmail.receiver.server=someserver) -hopefully-
I'm missing something with system-properties.xml? Seems like a bug to me.
regards,
Fred Bricon
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547322#547322]
Start a new discussion in EJB 3.0 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[jBPM] - jBPM 4.3 - job is not released when the transaction is marked as rollback only
by Adam Laczynski
Adam Laczynski [http://community.jboss.org/people/adam.laczynski] created the discussion
"jBPM 4.3 - job is not released when the transaction is marked as rollback only"
To view the discussion, visit: http://community.jboss.org/message/547310#547310
--------------------------------------------------------------
Job is not released when the exception occurred during job execution and transaction is marked as rollback only because synchronization cannot be registered in transaction (according to javax.transaction.Transaction#registerSynchronization java doc: @exception RollbackException Thrown to indicate that the transaction has been marked for rollback only).
Following exception is thrown:
org.jbpm.api.JbpmException: couldn't register synchronization: test1
at org.jbpm.pvm.internal.tx.JtaTransaction.registerSynchronization(JtaTransaction.java:78)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.handleJobExecutionException(ExecuteJobCmd.java:111)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:92)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:42)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.executeInNewTx(JtaTransactionInterceptor.java:87)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:66)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.executeWithRetry(JtaRetryInterceptor.java:52)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.execute(JtaRetryInterceptor.java:45)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.jobexecutor.JobParcel.run(JobParcel.java:48)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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)
After that, job could be acquired again but only after the lockMillis (default 30 minutes).
IMO in such case the job has to be released because it delay job execution. To achieve it JobExceptionHandler (with small modification) has to be register before invoking job.execute(...) in org.jbpm.pvm.internal.cmd.ExecuteJobCmd:76. Exception could be passed to the handler in the catch block.
Environment where the problem occurs:
- WebLogic 10.2.3
- jbpm 4.3
- Oracle 10g
Does anybody have similar problem? Is it known issue?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547310#547310]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[jBPM Development] - Fork activities with assignment handlers
by Janarthanan K S
Janarthanan K S [http://community.jboss.org/people/janashanmug] created the discussion
"Fork activities with assignment handlers"
To view the discussion, visit: http://community.jboss.org/message/547291#547291
--------------------------------------------------------------
Hi
The fork activities does not end in join while using assignment-handlers in the tasks. Following is my jpdl. It seems the control does not goes beyond the task "Parallel Queue".
Is the way I handle the fork is correct?
-------------------------------------------------------------------------------
hello_world.assignee.jpdl.xml
-------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<process name="helloWorld" xmlns=" http://jbpm.org/4.3/jpdl http://jbpm.org/4.3/jpdl">
<start g="27,248,80,40">
<transition to="fork1"/>
</start>
<fork g="158,247,91,65" name="fork1">
<on continue="exclusive" event="printHelloEnd"/>
<transition g="182,486:" to="Parallel Queue"/>
<transition g="182,61:121,-15" name="world" to="printHelloWorld"/>
</fork>
<join g="513,267,61,49" name="join1" continue="exclusive">
<transition to="printHelloEnd"/>
</join>
<task g="224,457,211,57" name="Parallel Queue">
<assignment-handler class="cos.workflow.helloworld.HelloWorldAssignmentHandler"/>
<transition g="537,487:" to="join1"/>
</task>
<java class="cos.workflow.helloworld.Printer" g="468,42,138,40" method="printHelloWorld" name="printHelloWorld">
<transition g="13,-27" name="join" to="join1"/>
</java>
<java class="cos.workflow.helloworld.Printer" g="664,268,116,48" method="printHelloEnd" name="printHelloEnd">
<transition to="theEnd"/>
</java>
<end g="893,269,80,40" name="theEnd"/>
</process>
-------------------------------------------------------------------------------
cos.workflow.helloworld.Main
-------------------------------------------------------------------------------
public class Main {
public static void main(String[] args) {
// Build jBPM services
ProcessEngine processEngine = new Configuration().setResource("workflow.jbpm.cfg.xml").buildProcessEngine();
RepositoryService repositoryService = processEngine.getRepositoryService();
ExecutionService executionService = processEngine.getExecutionService();
// Deploy helloWorld process definition and start a process instance
repositoryService.createDeployment().addResourceFromClasspath("hello_world.assignee.jpdl.xml").deploy();
ProcessInstance processInstance = executionService.startProcessInstanceByKey("helloWorld");
TaskService taskService = processEngine.getTaskService();
String pid = processInstance.getId();
List < Task > taskList = taskService.findPersonalTasks("admin");
Task task = taskList.get(0);
taskService.completeTask(task.getId());
processInstance = executionService.findProcessInstanceById(pid);
}
}
-------------------------------------------------------------------------------
cos.workflow.helloworld.HelloWorldAssignmentHandler
-------------------------------------------------------------------------------
public class HelloWorldAssignmentHandler implements COSAssignmentHandler {
/**
*
*/
private static final long serialVersionUID = 1L;
String userId;
/* (non-Javadoc)
* @see org.jbpm.api.task.AssignmentHandler#assign(org.jbpm.api.task.Assignable, org.jbpm.api.model.OpenExecution)
*/
public void assign(Assignable assignable, OpenExecution execution)
throws Exception {
userId = "admin";
System.out.println("cos.workflow.helloworld.HelloWorldAssignmentHandler");
assignable.setAssignee(userId);
}
}
-------------------------------------------------------------------------------
cos.workflow.helloworld.Printer
-------------------------------------------------------------------------------
public class Printer {
public void printHelloWorld() {
System.out.println("<---------------->");
System.out.println(" HELLO WORLD!");
System.out.println("<---------------->");
}
public void printHelloEnd() {
System.out.println("<---------------->");
System.out.println(" HELLO END!");
System.out.println("<---------------->");
}
}
Thanks
Jana.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547291#547291]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[EJB 3.0] - Access across different EAR on the same JBoss instance with local interfaces.
by �ukasz Szymik
�ukasz Szymik [http://community.jboss.org/people/lszymik] created the discussion
"Access across different EAR on the same JBoss instance with local interfaces."
To view the discussion, visit: http://community.jboss.org/message/547290#547290
--------------------------------------------------------------
Hi Everybody,
I have question regarding access to session beans with local interface. I have application which is split into two separate EAR archives (let say EAR1 and EAR2). EAR1 is somehow gate to be accessed by remote client (Remote interface from client Java SE application). EAR2 is "service" provider which is accessed from EAR1. I am using JBoss AS 6 M3.
I was able to develop session bean placed in EAR1 which is accessing bean from EAR2 with use of local interfaces.
<code>
ctx = new InitialContext();
GreetingsLocal greetings = (GreetingsLocal) ctx.lookup("ServiceTierApp/GreetingsImpl/local");
return greetings.getGreeting("I am here: " + message);
</code>
Session beans are deployed in separate EAR files and still I am able to use them with local interfaces (so for both are deployed in the same JBoss instance).
Questions:
1) Is this standard feature of JBoss? ( I was not able to gain same local interface access across EARs with Glassfish v3)
2) Do we have control (configuration) of this behavior in JBoss?
3) Is there any similar way to gain cooperation across EARs in same JBoss instance? From the business point of view we have to split whole application into at least 2 ears apps.
Thanks in advance for any feedback.
Best regards
Lukasz
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547290#547290]
Start a new discussion in EJB 3.0 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Web Services] - Problem with WS Security encryption
by Stefano Ficcadenti
Stefano Ficcadenti [http://community.jboss.org/people/Samb1985] replied to the discussion
"Problem with WS Security encryption"
To view the discussion, visit: http://community.jboss.org/message/547289#547289
--------------------------------------------------------------
Thanks a lot !
Tracing security.auth I note that the issue was the syntax of second sql statement.
I correct it with: select userroles*,'Roles'* from "public"."UserRoles" where username = ? and now authentication with postgre sql database works well.
Now still remain the other problem of encryption in first post of this discussion.
The Web Service security implemented is as the chapter 9.5 (until 9.5.3 included of JBoss in Action), but I use a pojo java as client to consume and test the WS. I created the pojo with Eclipse Wizard to create a Web Service Client with JBossWS runtime (not Axis).
Then I add to client java all files indicated in chapter 9.5.3, but when I run it throw an exception that indicate wsse security required as it don't know the descriptor in META-INF.
So I found a discussion that indicate to use in client the follow code:
URL securityURL = Main.class.getResource("META-INF/jboss-wsse-client.xml");
((StubExt) port1).setSecurityConfig(securityURL.toExternalForm());
((StubExt) port1).setConfigName("Standard WSSecurity Client", "META-INF/standard-jaxws-client-config.xml");
But when I run it:
Exception in thread "main" java.lang.ClassCastException: $Proxy23 cannot be cast to org.jboss.ws.core.StubExt
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/547289#547289]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years