[EJB/JBoss] - Re: transaction propagation
by asookazian
here is a reply from Ken Saks, spec lead of JSR 318:
anonymous wrote :
| On Mar 23, 2009, at 4:26 PM, Arbi.Sookazian(a)cox.com wrote:
|
|
| Hello,
|
| I would like to draw attention to this specific part of JSR 318, proposed final draft dated Feb 24, 2009, which is the same as in JSR 220, section 13.3.7.1:
|
| Specifying the TransactionAttribute annotation on the bean class means that it applies to all applicable business interface methods of the class.
|
|
|
| In EJB 3.1 (or later), I'm wondering if it will be possible to demarcate transaction attribute value (e.g. REQUIRED, REQUIRES_NEW, etc.) on private, protected, or package-private in a SFSB or SLSB (i.e. any method with less than public visibility). The current behavior in EJB 3.0 seems to be that the EJB container (in my case JBoss AS) ignores the transaction demarcation annotation on a private method and there is no warning from Eclipse, or exception/warning during deployment or runtime exception.
|
| I ran into this problem recently and it took me over *two days* to determine the root cause of the behavior in terms of transaction semantics and CMT in my SFSB. My workaround to this problem was to refactor the private method to a public method defined in the local interface implemented by a new SFSB. The REQUIRES_NEW transaction demarcation for the public method in the new SFSB is now honored by the ejb container.
|
| Why is it necessary to do this? We should be able to demarcate non-local interface methods or non-remote interface methods with transaction demarcation when using CMT.
|
|
|
| Hi Arbi,
|
|
| The behavior you're seeing is not specific to transaction attributes. All the special semantics associated with an EJB component invocation (method authorization, container exception handling, threading guarantees, container-managed transactions, etc.) only apply to invocations made through an EJB reference. When code already running within a business method invocation calls another method on the same class through the "this" pointer, the EJB container isn't involved. Such a method invocation is just a plain Java SE method call.
|
|
| If you want to invoke a business method on your bean from another business method on the same bean, you'll need to acquire an EJB reference to yourself. The easiest way is to call SessionContext.getBusinessObject().
|
|
|
|
| TestTransactionsLocal ejbRefToMyself = sessionCtx.getBusinessObject(TestTransactionsLocal.class)
| ejbRefToMyself.otherMethod();
|
|
| Regards,
|
|
| Ken
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220437#4220437
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220437
17 years, 1 month
[JBoss jBPM] - Re: Working with holidays
by kukeltje
anonymous wrote : I think it is boring and a common users can't do that..
Boring? hmmmm... subjective statement. But I agree that common users can't do that. But..... it was never meant for common users to change this file. So I do not see a real problem
anonymous wrote : I would you like to know if there's a another way to do that?
Yes there is. You can change the jBPM core so that it reads the file/data from somewhere else. Than in addition, you can develop a webapp that helps you changing this data. You can even make it configurable per process.
anonymous wrote : I think JBPM doesn't know how to deal with this situation.
Correct
anonymous wrote : Do you understand me?
Yes
anonymous wrote : Any idea how to solve it?
Yes, at least three
1: by writing an application that takes the definition, reads the duedates from the definition and recalculates all the new ones PER instance and stores that. That is assuming
- you can be sure the duedate should be changed (it was not changed in another way) and you know at what date it was set.
- you have the original date so you can recalculate (e.g. it was not based on a variable)
- .... some other 'hazards'
2: By changing the core of jBPM so it always calculates the duedate (expensive in queries!) based on the latest data
3: By changing the jBPM core so more info about duedates is stored and can be used
(Contributions always welcome ;-))
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220431#4220431
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220431
17 years, 1 month
[Security & JAAS/JBoss] - SSO ear deployment class cast exception
by adorandish
Problem:
I downloaded the source for the JBoss SSO and followed the instruction given in: http://www.jboss.org/community/docs/DOC-12304
Environment:
OS: Windows Vista
JDK: 1.6.0_11
JBoss: JBoss-5.0.1.GA
Error:
here is the error I get when I start the jboss:
| 14:33:31,801 ERROR [ProfileServiceBootstrap] Failed to load profile:
| org.jboss.deployers.spi.DeploymentException: Exception determining structure: AbstractVFSDeployment(jboss-federation-server.ear)
| at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
| at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:85)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:1000)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.determineDeploymentContext(MainDeployerImpl.java:440)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:390)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:300)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:303)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
| at org.jboss.Main.boot(Main.java:209)
| at org.jboss.Main$1.run(Main.java:547)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: java.lang.RuntimeException: Error determining structure: jboss-federation-server.ear
| at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:293)
| at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:73)
| at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:196
| at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:221)
| at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:77)
| ... 10 more
| Caused by: java.lang.ClassCastException: org.jboss.metadata.ear.jboss.JBoss50DTDAppMetaData cannot be cast to org.jboss.metadata.ear.spe
| at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:160)
| ... 14 more
| 14:33:31,818 INFO [ServerImpl] JBoss (Microcontainer) [5.0.1.GA (build: SVNTag=JBoss_5_0_1_GA date=200902232048)] Started in 10s:491ms
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220427#4220427
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220427
17 years, 1 month