Optimistic Locking in EJB3
by Karsten Ohme
Hi,
I have some questions regarding optimistic locking.
1) Can it happen in my container managed bean?
2) How can I deal with it? Can I find out if my container just started
the transaction? Can I repeat the transaction it in this case?
3) As far as I would guess optimistic locking does not lock the
database, so concurrent transaction can be executed on the same data
without delay regardless if they write or read? I.e if a whole
transaction will last 5 seconds where multiple services are involved,
within these 5 seconds also other transactions from the same bean can be
started and handled?
Regards,
Karsten
18 years, 2 months
[Security & JAAS/JBoss] - Single sign-on (SSO) access is not limited to security domai
by bkraz
Hi, I have been trying to fix a problem with single sign-on (SSO) security in JBoss 4.0.4 GA. The issue is that I cannot restrict some applications from taking part in the SSO domain. No matter what settings I use, once a user successfully authenticates in an SSO application, he has access to ALL JBoss apps, even if they are listed in a different security domain. Here are the details:
Single sign-on is activated with the following in deploy/jbossweb-tomcat55.sar/server.xml:
All liferay components are in this security domain:
<jboss-web>
<security-domain>java:/jaas/PortalRealm</security-domain>
...
</jboss-web>
I have a few applications (xforms) that I want to participate in the SSO domain. These work perfectly.
I have another application (/axis) in a different security domain, which is still accessible to SSO users.
<jboss-web>
<security-domain>java:/jaas/axis</security-domain>
</jboss-web>
In conf/login-config.xml:
<application-policy name = "axis">
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">props/axis-users.properties</module-option>
<module-option name="rolesProperties">props/axis-roles.properties</module-option>
</login-module>
</application-policy>
and
<application-policy name = "PortalRealm">
<login-module code ="com.liferay.portal.security.jaas.PortalLoginModule"
flag = "required">
<module-option name="userClassNames">com.liferay.portal.security.jaas.PortalPrincipal</module-option>
<module-option name="roleClassNames">com.liferay.portal.security.jaas.PortalRole</module-option>
</login-module>
</application-policy>
The above block is not necessary to make Liferay security work. I added it myself, but it did not change any noticeable behavior.
I intend to make /axis only available to those with a specific username and password, however JBoss currently allows all Liferay users to have access to axis despite it being in a different security domain. I have had problems with the java:/blah/blah naming convention, and I have seen a few posts indicating this might be an issue. Does anyone have a suggestion for how I might limit SSO access to certain apps? Thanks! -Ben
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124962#4124962
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124962
18 years, 2 months
[Clustering/JBoss] - StateTransferTimeout appears to be ignored
by dcolwell
I have deployed JBoss 4.2.1GA across a two node cluster. It's configured for asynchronous, non-transactional replication of user session data using UDP. Application state is exclusively servlet based with no EJBs. After starting up the first node I fire up the second and have observed it pause from 1 to 10 minutes after logging:
Fetching state (will wait for 30000 milliseconds)
The next line in my server.log file appears successful, just long:
state was retrieved successfully (in 189067 milliseconds)
The 30000 millis is configured by setting a StateTransferTimeout attribute, but different values appear to be equally ignored. Does anyone have thoughts on what may be causing this? The amount of user data potentially active on the first node is rather small (< 100k) if any.
Thanks much!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124957#4124957
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124957
18 years, 2 months
[JBoss jBPM] - ClassNotFound for IntegrationConfigurator on server restart
by meghanai_99
Hello,
I have checked out BPEL 1.1 GA cvs code and deployed jbpm-bpel.ear on JBoss 4.0.5GA. I can open the BPEL console and deploy hello.zip from examples folder. The process is deployed fine and I call it using SoapUI client.
However when I restart my server I get this error -
| 14:34:37,548 ERROR [[/hello]] Error configuring application listener of class org.jbpm.bpel.integration.server.Integrati
| onConfigurator
| java.lang.ClassNotFoundException: org.jbpm.bpel.integration.server.IntegrationConfigurator
| at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1355)
| at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1201)
| at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3711)
| at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211)
| at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
| at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
| at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
| 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:585)
| at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
| at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.apache.catalina.core.StandardContext.init(StandardContext.java:5052)
| 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:585)
| at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
| at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:297)
| at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:103)
| at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:371)
| at org.jboss.web.WebModule.startModule(WebModule.java:83)
| at org.jboss.web.WebModule.startService(WebModule.java:61)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor2.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:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at sun.reflect.GeneratedMethodAccessor9.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:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
|
And then at the end of the log trail I get a message that it could not deploy hello.war file.
I can redeploy the zip file using console and call it again. Any idea what could be causing this behavior?
Thank you,
Meghana
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124952#4124952
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124952
18 years, 2 months
[Installation, Configuration & DEPLOYMENT] - URIList for 5.0 question
by PeterJ
In 4.2.x (and earlier), the URIList property of the DeploymentScanner MBean is well documented. Playing with the URIList property of the VFSDeploymentScanner bean in 5.0 beta3, I have noticed several differences in behavior. Are these differences expected or unintentional?
1) Adding an archive name (a URI that does not end in a slash), causes various exceptions ("org.jboss.deployers.spi.DeploymentException: Error deploying MANIFEST.MF: The virtual file is closed" if the URI points to a file, and "java.lang.IllegalStateException: File cannot contain children: FileHandler(a)2286508[path=WEB-INF/web.xml context=file:/F:/opt/jbia/deploy/hello.war/ real=file:/F:
/opt/jbia/deploy/hello.war/WEB-INF/web.xml]" if the URI points to an exploded directory).
2) If there are multiple directory entries (URIs that end with a slash), all of them get scanned during startup for applications to deploy (as expected), but only the first entry gets scanned by the hot deployer while the app server is running, which makes for interesting behavior if "${jboss.server.home.url}deploy/" is not the first entry!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124951#4124951
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124951
18 years, 2 months
