synchronized methods in instrumented class

[rkadayam]

After the aopc compilation process, the instrumented classes have two synchronized methods getInstanceAdvisor and setInstanceAdvisor. Unfortunately when the target happens to be a SessionBean it violates the J2EE specifications and so its not possible to deploy these instrumented EJBs to application servers such as Weblogic and maybe Websphere as well.

Is there a possible work-around for this bug ?

[bill.burke]

Are you saying that Weblogic and Websphere barf if you have declared a method as synchronized?

The synchronized methods are not on EJB business methods or callbacks, so I fail to see how it violates the specification.

All the specification says is:

"An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances".

JBoss 4.0.0 passes the J2EE 1.4 TCK. JBoss AOP runs within JBoss 4.0.

Bill

[rkadayam]

I'm pasting the exact error message from weblogic

weblogic.ejb20.compliance.ComplianceException: In EJB com.ascential.asb.service.test.greetingService.GreetingService, Enterprise Bean methods must not use thread synchronization primitives. The method named _setInstanceAdvisor(org.jboss.aop.InstanceAdvisor) is synchronized.

I was under the impression the spec restricted all public methods of the bean to not use the synchronized primitive and guess I'm wrong. But in any case would it not be equivalent to use some variable to synchronize on inside the body of the method ? Portability is quite high in our priorities and although we intensively use JBoss during development we end up with a lot of surprises when trying to port to weblogic or websphere.

Websphere 5.1 does not complain about this issue but about something else which I'm still trying to figure out is exactly what ?? :-)

Thanks
Rajiv

[rkadayam]

Does the J2EE 1.4 TCK certification encompass deployment of J2EE applications that are aop-compiled using JBoss-AOP ?

I'm hoping there will be a plausible resolution to this issue as it impacts our usage of JBoss AOP to a great extent.


Thanks
Rajiv

[bill.burke]

Yes, we will eventually fix this problem. It will take awhile because it requires changes to Javassist to suport synchronized blocks. The synchronization is needed otherwise you have problems with concurrent access to a POJO.

Bill

[starksm64]

No, the j2ee certification did not involve aspectized deployments using the jboss AOP framework.

[rkadayam]

Of course, J2EE TCK may not explicitly reference Aspects or AOP instrumentation. I even wonder if J2EE will ever talk about AOP as it may sound a little too invasive/disruptive to let bean developers to play with.

But does JBoss plan to implement the strict constraints of J2EE constructs especially the ones that related to thread manipulation mandated by the TCK and so prevent the deployment of J2EE application that may blatantly violate those constraints ? Something that both weblogic and websphere try to enfore today.

Or is it the case that the TCK does not require application servers to be so "precise" in behavior allowing JBoss to be more tolerant as it is right now ? Sorry, I have'nt really had time or patience to read through and digest all of the Specs.

This tolerant behavior is a double-edged sword, it definitely helps developers to maybe successfully accomplish certain features via a path that J2EE may not completely agree with. But it hampers productivity of developers who most commonly use JBoss for development but may have unknowingly violated some J2EE constraints only to realize much later in the game during the porting stage. I guess the answer could lie in those J2EE verfier tools and how diligently it is used and monitored. Also most of the time the disparate class-loader architectures end up being the culprits.

Bill - I appreciate your understanding of my problem and will await your resolution however soon you or your team would be able to provide a resolution.

thanks again
Rajiv

[bill.burke]

JBoss has passed certification awhile ago now.

The J2EE TCK tests do not test the behavior in question and there are no plans to implement any strict constraints or stricter verifier.

FYI, it seems Chiba has implemented synchronized blocks, so your fix is scheduled for the next AOP release.

Bill

[rkadayam]

Thanks very much !!

Rajiv