[JBoss Seam] - Re: how to leave a long running conversation and start a new
by ajay.gupta
Folks,
We faced a similar situation a few days ago. The user could click on a hyperlink in a page to go to a different page which was required to open in a new non-nested conversation. Before redirecting to the new page, the application was required to process the edits the user had made on the screen, save those changes and not end the conversation (instead, leave the conversation since the user could come back to the first page by back buttoning from the 2nd page).
The solution we went with was:
1. On the JSP page, use <h:commandLink> to post the form data back to the server so that the POST will propagate conversation.
2. Process the form submit using standard JSF phases.
3. Determine which page to redirect the user to.
4. In phase V, return the navigation constant corresponding to the 2nd page.
5. In pages.xml, use:
<page view-id="/first-page.jsp">
<rule if-outcome="shouldRedirect">
<raise-event type="leaveConversation" />
<redirect view=id="/secondPage.jsp">
6. Define an event listener for leaveConversation event. In the @Observer method for this event, do as follows:
i. Conversation.leave().
ii. Get conversation entry for the Conversation object and call unlock() on it.
This worked perfectly. I know this is not an ideal solution.
We would like to suggest that Seam team support ability for specification of a tag like <leave-conversation> in pages.xml (similar to <begin-conversation> and <end-conversation>). That will be the ideal solution to this problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129799#4129799
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129799
18 years, 2 months
[JBoss jBPM] - Re: BPEL GA on Oracle: ElementType causing problem while run
by alex.guizar＠jboss.com
For the sake of isolating the error, can you reduce the column length to 2000 (the max size for a RAW column), repackage and redeploy the application?
If downsizing causes the data to exceed the column length, locate the following entry in jbpm.cfg.xml and set it to a value greater than 0. Note that changing this setting has the side effect of enlarging small byte chunks (say, 100-200 bytes) so use it with care.
<!-- see java.util.zip.Deflater for details on the compression level -->
| <int name="jbpm.bpel.element.deflate.level" value="0" singleton="true" />
Anywhere you see length="4000" in the mapping documents, we mean "arbitrary length". For both jPDL and BPEL we'd have really liked to use BLOB/CLOB instead of VARBINARY/VARCHAR column, but support for the former varies greatly from vendor to vendor.
In 1.1.Beta3, the length was not specified, which resulted in the database picking a default length. In some cases the default was as small as 255 chars/bytes, which was unacceptable. Unfortunately, it is hard to pick a value that works for all databases, drivers, versions, etc.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129790#4129790
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129790
18 years, 2 months
[Security & JAAS/JBoss] - Dynamic login config broken in JBoss 5 Beta4
by javidjamae
Dynamic login config does not work in Beta4, but I verified that the same code / configuration worked in Beta3.
The exception is:
| 17:05:55,015 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=DynamicLoginConfig state=Create mode=Manual requiredState=Installed
| org.jboss.deployment.DeploymentException: Failed to find authConf as resource: META-INF/dynamic-login-config.xml
| at org.jboss.security.auth.login.DynamicLoginConfig.startService(DynamicLoginConfig.java:236)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
| at $Proxy5.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:255)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:659)
| at org.jboss.system.ServiceController.start(ServiceController.java:431)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:150)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:108)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:65)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:853)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:874)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:794)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:498)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:506)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:246)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:131)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:408)
| at org.jboss.Main.boot(Main.java:208)
| at org.jboss.Main$1.run(Main.java:534)
| at java.lang.Thread.run(Thread.java:595)
| 17:05:55,031 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/jboss-5.0.0.Beta4/server/security/deploy/dynamicloginconfig-service.xml state=PostClassLoad
| er mode=Manual requiredState=Real
| org.jboss.deployment.DeploymentException: Failed to find authConf as resource: META-INF/dynamic-login-config.xml
| at org.jboss.security.auth.login.DynamicLoginConfig.startService(DynamicLoginConfig.java:236)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
| at $Proxy5.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:255)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:659)
| at org.jboss.system.ServiceController.start(ServiceController.java:431)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:150)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:108)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:65)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:853)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:874)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:794)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:498)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:506)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:246)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:131)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:408)
| at org.jboss.Main.boot(Main.java:208)
| at org.jboss.Main$1.run(Main.java:534)
| at java.lang.Thread.run(Thread.java:595)
|
Is this a known issue?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129789#4129789
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129789
18 years, 2 months
[JBossCache] - Cache Persistence granularity
by debbanerjee
We are using jboss cache(version: jbosscache-core-2.1.0.CR2, tree cache) within a Java service. Our cache has very few nodes (around 3). Each of those nodes can have lots of data (>100K entries). We are using BDB-J for cache persistence, using the BDBJECacheLoader. Our data is non-transactional: we are caching Directory (LDAP server) data. So we are runinng with isolation level none.
Reviewing the documentation, and looking at the test results the following seems to be true:
When I update a map entry in a node then the entire map is written to disk. I had expected only that specific entry would be written out to disk. Clearly this will not satisfy our performance requirements since a map entry update would trigger a super-large disk write.
Can this be confirmed? If so are there workarounds where only that single entry is updated in the above use case? Do I need to write a custom CacheLoader instance to get this to behave performantly?
Thanks
--Deb
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129788#4129788
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129788
18 years, 2 months
[EJB 3.0] - Re: EJB3 & SSL not working in JBoss 5 Beta3?
by javidjamae
It seems like I'm doing everything the same, but I get the following error on the server:
| 14:36:15,468 ERROR [ServerThread] Worker thread initialization failure
| java.lang.reflect.InvocationTargetException
| at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
| at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:720)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:368)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
| Caused by: java.net.SocketException: Socket Closed
| at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201)
| at java.net.Socket.setSoTimeout(Socket.java:988)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:1971)
| at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:168)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
| at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
| ... 7 more
I also see this error on the client:
| [echo] java -Djavax.net.ssl.keyStrore=c:\jbia-src\ch07\target/keystore/client.truststore -Djavax.net.ssl.keyStorePassword=clientpass com.manning.jbia.Client
| [java] Exception in thread "main" org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [sslso
| cket://127.0.0.1:3843/]
| [java] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:559)
| [java] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
| [java] at org.jboss.remoting.Client.invoke(Client.java:1634)
| [java] at org.jboss.remoting.Client.invoke(Client.java:548)
| [java] at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| [java] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| [java] at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| [java] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| [java] at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
| [java] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| [java] at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
| [java] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| [java] at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:108)
| [java] at $Proxy1.greet(Unknown Source)
| [java] at com.manning.jbia.Client.main(Client.java:27)
| [java] Caused by: java.lang.reflect.InvocationTargetException
| [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| [java] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| ...
| (rest is same as on server)
|
This is how I started my server:
| $ ./run.sh -Djavax.net.ssl.keyStore=../server/enterprise/conf/server.keystore -Djavax.net.ssl.keyStorePassword=serverpass -c enterprise
|
Here is my mbean:
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.remoting:type=Connector,transport=sslsocket3843,handler=ejb3">
| <attribute name="InvokerLocator">sslsocket://${jboss.bind.address}:3843</attribute>
| <attribute name="Configuration">
| <config>
| <handlers>
| <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
| </handlers>
| </config>
| </attribute>
| </mbean>
|
Here is my bean:
| @RemoteBindings({@RemoteBinding(clientBindUrl = "sslsocket://0.0.0.0:3843", jndiBinding="StatelessSSL")})
| @Stateless
| public class GreeterBean implements Greeter {
| @PersistenceContext
| private EntityManager em;
|
| public void greet(String message) {
| Greeting greeting = new Greeting(message);
| em.persist(greeting);
| }
|
| @SuppressWarnings("unchecked")
| public List<Greeting> getAllGreetings() {
| return em.createQuery("from Greeting").getResultList();
| }
| }
|
And here is my client:
| public class Client {
| public static void main(String[] args) throws Exception {
| InitialContext ctx = new InitialContext();
|
| Greeter greeter = (Greeter) ctx.lookup("StatelessSSL");
| greeter.greet("Hello, world!");
| greeter.greet("Hola, mundo!");
| greeter.greet("Salam, donya!");
| greeter.greet("Bonjour, monde!");
| greeter.greet("Ciao, mondo!");
|
| List<Greeting> greets = greeter.getAllGreetings();
| for (Greeting greeting : greets) {
| System.out.println(greeting.getGreeting());
| }
| }
| }
|
I'm running in cygwin under windows XP. Just for good measure, I made sure to disable the Windows Firewall, but that didn't make a difference. Any clues?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129778#4129778
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129778
18 years, 2 months