[JBoss Portal Users] - WSRP integration between Liferay and JBoss
by aimvrakesh
Dear Portal gurus!,
I have been struggling to enable WSRP communication between Liferay and JBoss portal servers. I have tried using JBoss as the producer and Liferay consumer but get the following exception below, and WSRP portlet I was using was JSP Sample Portlet from the Jboss:-
16:43:25,475 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
javax.xml.rpc.soap.SOAPFaultException: Could not render portlet '/portal-jsp-sam
ples.JSPPortlet'. java.lang.IllegalArgumentException: Requires a non-null, non-e
mpty wsrp portlet name
at org.jboss.portal.wsrp.WSRPExceptionFactory.createSOAPFaultException(W
SRPExceptionFactory.java:126)
I would greatly appreciate if you could help in resolving this issue or if you could point me towards any instructions on getting this working.
Sincerely,
R
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254785#4254785
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254785
15 years, 4 months
[JBoss Remoting Users] - Re: port problem on windows embedded pos
by gymoese
I'm seeing something similar. We have a JBoss AS (4.3.2) running the server part of our application and several remote clients communicating with the server via. JMS (JBoss messaging 1.4.4 GA) + several stateless session beans.
If I configure the jboss remoting service to use SSL then I get the same problem as posted above, but ONLY if I configure my JBoss AS with a hostname and not an IP addr. during startup with the -b option.
The server and the client are running on the same machine and everything works nicely if I configure my server with -b <IP-Addr> but not with -b - and yes I'm 100% sure it resolves correctly (o;
What I have noticed is that the serverBindPort of the SslBiSocket configuration seems to be ignored once the serverBindAddress part is a hostname that needs to be resolved.
I have the port configured to default which is 5457 and that is also the port which is used when I used an IP address in my binding, however if I specify the hostname for my machine then the port is just randomly picked and this seems to be causing the problem.
BTW. it seems a bit strange that when I run my hostname set using the -b then it is printed as resolved in the logs.
Starting JBoss with -b "EXI_PEG-W01.headquarters.excitor.dk" will provide the following log line:
Connector sslbisocket://172.16.15.144:40044 has leasing enabled....
First of all you can see that the port is not 5457 as configured and secondly the bindadr. has already been resolved and the resolved adr. is what is sent to the client which is not at all smart - at least that is how it seems to work (o;
If you look at i.e. the WebService service it prints:
... codebase: http://EXI_PEG-W01.headquarters.excitor.dk:8083/
Where the hostname maintains unresolved, might just be a log detail?
Anyway, if I start my JBoss server with -b 172.16.15.144 then, as stated above, everything works fine and I get the following in the log:
Connector sslbisocket://172.16.15.144:5457 has leasing enabled...
Now the correct 5457 port is used!
Actually I can make it run with the hostname set if I just hardcode the 172.16.15.144 in the remoting-sslbisocket-service.xml - not really an option though (o;
Hopefully this can be somewhat usefull when someone goes bughunting (o:
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254781#4254781
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254781
15 years, 4 months
[jBPM Users] - Re: workflow design about wait states
by mmusaji
Would love to write a blog entry about this, get more involved with jboss and jbpm is my ultimate aim. I need to know what I'm talking about first! ;) Unfortunately... with work pressures etc its not always possible. We'll see...
Taking the "async" out it works fine, I can see the nodes and assert which one they should be in. When the custom nodes run in async, the unit test runs to completion quicker than the actual workflow completes (or vice versa not sure). So when I do:
| Execution execution = processInstance.findActiveExecutionIn("validate one request");
| assertNotNull(execution ); //FAILS
| String executionId = execution .getId();
| executionService.signalExecutionById(executionId);
|
The assertion fails. In my custom class I have the following line
| public void execute(ActivityExecution execution {
| //my code....
| execution.waitForSignal();
| }
|
|
| public void signal(ActivityExecution execution,
| String signalName,
| Map<String, ?> parameters) {
| execution.take(signalName);
| }
|
|
and they all implement ExternalActivityBehaviour. I have no idea what state these are in now.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254772#4254772
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254772
15 years, 4 months
[Security] - Jaas + multiple web apps authentication
by marianokm
Hi Everyone:
Im developing multiple web applications and i've a question about JAAS and SecurityDomanins.
My scenario:
a. I've defined a Security domain called "blah-domain".
b. I've configured the proper login-config (with the proper login-modules)
c. I've configured my security domain against openLdap.
d. I've 12 webApps.
e. Each one of them on separate .war file.
f. Each one of them has his own jboss-web.xml file pointing to the "same" mentioned security domain.
So far so good! and all is working properly.
What is happening?
a. Although each webapp is configured against the same security domain (blah-domain), every time i move from one war to another, a login dialog box is performed and the user must type his username/pwd again.
b. The user should be prompted with credentials once and remember this information no matter if i move from war to war (at lease what i expect)
Question
a. Does anybody knows how to solve this problem ?
Thanks in advance!
Kind Regards!
MarianoK.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254771#4254771
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254771
15 years, 4 months
[jBPM Users] - Re: Signaling executions for processes that containt tasks d
by LMarinkov
Here is the error for the AvgDurationTest class. Sorry the log that i posted was for the unit test that i wrote. But the error in both tests is the same!
-------------------------------------------------------------------------------
| Test set: org.jbpm.test.history.AvgDurationTest
| -------------------------------------------------------------------------------
| Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.764 sec <<< FAILURE!
| testAvgDuration(org.jbpm.test.history.AvgDurationTest) Time elapsed: 2.717 sec <<< ERROR!
| org.hibernate.NonUniqueResultException: query did not return a unique result: 2
| at org.hibernate.impl.AbstractQueryImpl.uniqueElement(AbstractQueryImpl.java:844)
| at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:835)
| at org.jbpm.pvm.internal.hibernate.DbSessionImpl.findTaskByExecution(DbSessionImpl.java:383)
| at org.jbpm.jpdl.internal.activity.TaskActivity.signal(TaskActivity.java:116)
| at org.jbpm.jpdl.internal.activity.TaskActivity.signal(TaskActivity.java:102)
| at org.jbpm.pvm.internal.model.op.Signal.perform(Signal.java:68)
| at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:637)
| at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:597)
| at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:398)
| at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:61)
| at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:35)
| at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
| at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
| at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:46)
| at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
| at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.signalExecutionById(ExecutionServiceImpl.java:84)
| at org.jbpm.test.history.AvgDurationTest.executeProcess(AvgDurationTest.java:79)
| at org.jbpm.test.history.AvgDurationTest.testAvgDuration(AvgDurationTest.java:54)
| 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 junit.framework.TestCase.runTest(TestCase.java:164)
| at org.jbpm.test.BaseJbpmTestCase.runTest(BaseJbpmTestCase.java:80)
| at junit.framework.TestCase.runBare(TestCase.java:130)
| at junit.framework.TestResult$1.protect(TestResult.java:106)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.framework.TestResult.run(TestResult.java:109)
| at junit.framework.TestCase.run(TestCase.java:120)
| at junit.framework.TestSuite.runTest(TestSuite.java:230)
| at junit.framework.TestSuite.run(TestSuite.java:225)
| 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.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
| at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
| 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
| at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254770#4254770
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254770
15 years, 4 months