[Installation, Configuration & DEPLOYMENT] - Isolation with shared libraries instances?
by jguyard
Hi all,
this is my first time posting here.
First of all, I've read almost everything here: http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Se...
I'm working with JBOSS 4.2.3 and my current mission is to deploy the same ear twice in the same jboss server instance.
I had isolation problems (ClassCastException,...), so I decided to start with something very easy and write this TestCase:
I have a ear containing a servlet. This servlet, when requested, prints the fully qualified name of a singleton and his memory address. So here is what I have (TestCase2.ear is a duplication of TestCase1.ear with a different context-root for requesting them seperatly):
server
| |
| --- deploy
| | |
| | --- ear-deployer.xml (isolated parameter setted to true)
| | |
| | --- TestCase1.ear
| | | |
| | | --- TestCase1.war
| | | |
| | | --- WEB-INF
| | | |
| | | --- classes
| | | | |
| | | | --- myServlet.class
| | | |
| | | --- lib
| | | |
| | | --- mySingleton.jar
| | --- TestCase2.ear
| | | |
| | | --- TestCase2.war
| | | |
| | | --- WEB-INF
| | | |
| | | --- classes
| | | | |
| | | | --- myServlet.class
| | | |
| | | --- lib
| | | |
| | | --- mySingleton.jar
RESULT: The servlets print the same fully qualifiedName but different memory addresses. Until now everything is how I expected.
______________________________________________________
Then this is the second test:
server
| |
| --- deploy
| | |
| | --- ear-deployer.xml (isolated parameter setted to true)
| | |
| | --- TestCase1.ear
| | | |
| | | --- TestCase1.war
| | | |
| | | --- WEB-INF
| | | |
| | | --- classes
| | | |
| | | --- myServlet.class
| | |
| | --- TestCase2.ear
| | | |
| | | --- TestCase2.war
| | | |
| | | --- WEB-INF
| | | |
| | | --- classes
| | | |
| | | --- myServlet.class
| | |
| --- lib
| | |
| | --- mySingleton.jar
RESULT: The servlets print the same fully qualifiedName, the same classloader (UnifiedClassLoader3) AND the same memory addresses. This is very troublesome because this is not what I was waiting.
I fully understand why they are loaded by the same UCL. For me, every jars in the lib directory of the server are shared libraries. But I don't understand why instances are shared between ears.
Is this some kind of bug? Or is there another "shared lib directory" to do what I try to do?
Regards,
J. Guyard
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201829#4201829
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201829
17 years, 6 months
[Remoting] - EJB3 was not found in the Dispatcher
by vink
I'm using Jboss 4.2.2.GA. I'm getting the following exception when calling deployed SLSB from my client;
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
at $Proxy0.listSamples(Unknown Source)
at my.client.SampleClient.main(SampleClient.java:33)
Caused by: org.jboss.aop.NotFoundInDispatcherException: Object with oid: jboss.j2ee:jar=Sample.ejb3,name=SampleImpl,service=EJB3 was not found in the Dispatcher
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:85)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:206)
at org.jboss.remoting.Client.invoke(Client.java:1708)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
at $Proxy0.listSamples(Unknown Source)
at my.client.SampleClient.main(SampleClient.java:33)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
... 2 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201827#4201827
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201827
17 years, 6 months
[JBoss jBPM] - Variable and Looking Up Token
by bradsdavis
I have a pattern I am trying to use to asynchronously signal a process to continue. Unfortunately, because I need to do this between clusters and to a particular queue, I am not able to leverage the "async" attribute in this case.
So, I am trying to figure out how to reference a token, and correlate back to that token when I receive a message in a MDB.
Currently, I took the Token ID and used that to correlate. However, I get ID not found exception when I do the lookup in the MDB.
I am using 3.2.3; I have data on the token that I could use to look the token up through hibernate, but would need some information related to how to query the token when referencing the variables mapped to its instance.
Thanks,
Brad
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201818#4201818
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201818
17 years, 6 months
[JBoss Cache: Core Edition] - Re: TcpDelegatingCacheLoader
by lovelyliatroim
Hi Manik,
Just seen your entry here to resolved
[ https://jira.jboss.org/jira/browse/JBCACHE-1451?page=com.atlassian.jira.p... ]
Had a look at your fix here
http://fisheye.jboss.org/browse/JBossCache/core/trunk/src/main/java/org/j...
Is that the fixed version??
If so you there is a bug.
Let me explain
| protected Map<Object, Object> _get(Fqn name) throws Exception
| {
| synchronized (this)
| {
| out.reset();
|
| out.writeByte(TcpCacheOperations.GET);
| out.writeObject(name);
| out.flush();
| Object retval = in.readObject();
| if (retval instanceof Exception)
| {
| throw (Exception) retval;
| }
| return (Map) retval;
| }
| }
|
|
Lets take this sample here, your locking is better but you make the mistake in throwing the IOException to the calling method. Once you throw it you loose your lock and when catching the IOException you dont synch on the restart, so picture this
T1 gets lock,
T2 waits for lock
T1 Times out or server socket is down and throws exception
T2 now has lock and times out
T2 throws exception
T1 calls restart from invokeWithRetries
T3 acquires lock and writes but doesnt read
T2 calls restart from invokeWithRetries
T3 now attempts to read response
You need to clean up in the _get() while you still have the lock
Something like this
| protected Map<Object, Object> _get(Fqn name) throws Exception
| {
| synchronized (this){
| try {
|
| out.reset();
|
| out.writeByte(TcpCacheOperations.GET);
|
| out.writeObject(name);
| out.flush();
| Object retval = in.readObject();
| if(log.isDebugEnabled()){
| log.debug("Path=" +name +" Return Val"+name);
| }
|
| if (retval instanceof Exception)
| {
| throw (Exception) retval;
| }
| return (Map) retval;
| } catch (IOException e) {
| log.info("IOEXception occurred. Will attempt to re-create connection",e);
| try{
| restart();
| }catch(IOException ex){
| log.error("Failed to reconnect to remote server, it might be down??"+ex);
| }
| }
| }
|
| return null;
| }
|
That way only one thread calls the restart and once reset it should be ok for the next thread.
Next thing i see is the start method
| public void start() throws IOException
| {
| try
| {
| sock = new Socket(config.getHost(), config.getPort());
| sock.setSoTimeout(config.getReadTimeout());
| out = new ObjectOutputStream(new BufferedOutputStream(sock.getOutputStream()));
| out.flush();
| in = new ObjectInputStream(new BufferedInputStream(sock.getInputStream()));
| }
| catch (ConnectException ce)
| {
| log.info("Unable to connect to TCP socket on interface " + config.getHost() + " and port " + config.getPort());
| throw ce;
| }
| }
|
I would change this also, I know i wrote it originally but I would change it to something like this
| public void start() throws IOException
| {
| log.info("Attempting to start a connection to server");
|
| InetSocketAddress address = new InetSocketAddress(config.getHost(),config.getPort());
| sock = new Socket();
| sock.setSoTimeout(config.getReadTimeout());
| sock.connect(address, config.getReadTimeout());
| out = new ObjectOutputStream(new BufferedOutputStream(sock.getOutputStream()));
| out.flush();
| in = new ObjectInputStream(new BufferedInputStream(sock.getInputStream()));
| }
|
|
Reason being I dont like this
| sock = new Socket(config.getHost(), config.getPort());
|
This constructor from the API says that
anonymous wrote :
| Creates a stream socket and connects it to the specified port number at the specified IP address.
|
Now at this stage we have no timeout set, so does that mean we dont timeout and can wait to establish a connection for no matter how long it takes??? Other way is safer, we set the timeout before we make the connection.
Just my 2 cents on it, hope it helps. Ignore me if I am looking at the wrong file but would appreciate if you posted the right link for me so I can look at the fix for it.
Regards,
LL
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201814#4201814
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201814
17 years, 6 months
[JBoss jBPM] - JbpmContext usage & best practices
by srLucas
Hi!,
I am using JBPM + Spring (springmodules0.8a) + Struts to create an application.
I would like to know what are the best practices regarding the jbpmContext and how to create it/reuse it.
This is my spring configuration
| <bean id="dc-workflow"
| class="org.springmodules.workflow.jbpm31.definition.ProcessDefinitionFactoryBean">
| <property name="definitionLocation"
| value="classpath:dc/processdefinition.xml"/>
| </bean>
|
| <bean id="jbpmConfiguration"
| class="com.ea.dc.core.CustomLocalJbpmConfigFactoryBean">
| <property name="sessionFactory" ref="sessionFactory"/>
| <property name="configuration" value="classpath:jbpm.cfg.xml"/>
| <!-- property name="configuration" value="classpath:jbpm.cfg.xml"/ -->
| <property name="processDefinitions">
| <list>
| <ref local="dc-workflow"/>
| </list>
| </property>
| <property name="processDefinitionsResources">
| <list>
| <value>classpath:dc/processdefinition.xml</value>
| </list>
| </property>
| </bean>
|
| <!-- jBPM template -->
| <bean id="jbpmTemplate" class="org.springmodules.workflow.jbpm31.JbpmTemplate">
| <constructor-arg index="0" ref="jbpmConfiguration"/>
| <constructor-arg index="1" ref="dc-workflow"/>
| </bean>
and then I am injecting those beans to a service of mine...
now, whenever I want to do something with the workflow, I do something like:
/** Moves the process forward.
| *
| * @param jobId the process instance id
| * @param transitionId the transition id to select
| */
| public void moveForward(final Long jobId, final String transitionName){
| JbpmContext jbpmContext = getContext();
|
| try {
| ProcessInstance instance = jbpmContext.getProcessInstanceForUpdate(jobId);
|
| instance.signal(transitionName);
| } finally {
| // make sure we save everything
| jbpmContext.close();
| }
| }
as shown in the documentation...
the thing is... I am closing the context every time I leave a service method...
isn't it better to leave it open? Is this a good practice?
I was thinking about using something similar to openSessionInView for the jbpmContext (though I'm not sure how to do it)... will that be better?
Any ideas/pointers would be great!
Thanks a lot,
Lucas
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201813#4201813
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201813
17 years, 6 months
[JBoss Portal] - Re: JBoss Portal WSRP <-> Sharepoint interoperability
by uiterlix
There's no specific reason for using 2.6.7, so I could give 2.7 a try.
I can't post the SOAP messages since the action I'm trying to perform doesn't result in a SOAP call from sharepoint to jboss portal.
Let me elaborate:
Sharepoint renders my portlet correctly. On this portlet there's a button that should result in a processAction call (which actually works when running this portlet over wsrp in another jboss portal). The HTML rendered in sharepoint for this button looks as follows:
The strange this is when looking at the same HTML fragment for the same portlet but then installed as a WSRP portlet in a JBoss portal, the form action url looks different since jboss actually rewrites the URL to something meaningful to itself, but sharepoint doesn't seem to since this URL is exactly the same as the actionurl as obtained from the renderresponse.
Any ideas? It seems like a sharepoint problem, but I can't find any resolution on the internet, although it seems a pretty common integration scenario to me.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201810#4201810
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201810
17 years, 6 months