|
Alex |
|
|
Technology
[
avasseur
]
16:26, Friday, 13 January 2006
It's interseting to follow the different strategies around Open Source these days. I have been myself leading a project for some time with Jonas Bonér in the AOP field, and we more than once had potential corporate users willing to be helped or supported (thus charged) with some more formal ways than classic user mailing lists and "fix it yourself / wait for the community to fix it" attitude. BEA's blended strategy of certifying and supporting 24/7 major open source components (like Spring) is well echoed by several facts these last weeks. First some post on TheServerSide "Developping J2EE without xxx? Why?", xxx beeing your perhaps favorite open source framework, (xxx and yyy abstracted for the purpose of this blog article). Some various comments from this thread: More interesting, a recent quote from HP Software head Todd DeLaughter (translated from French): Obviously it would then be intersting to look at the cost of Open Source, beyond the FOSS zero acquisition cost. It's not secret that JBoss is now selling software (not free, with trial copy and commercial license) and doing marketing around it - see the last JBoss newsletter and the messages around JBoss ON "JBoss Operating Network", the what sounds to be administration solution of JBoss app servers (see f.e. here). Deploying stuff on an Open Source stack is end to end is definitely not free at the end. FOSS is just one view on one single phase in a project: development. Left aside the training cost for the young developers themselves. Obviously, we then should take into account support prices, and possible performance gaps between each stacks, meaning all in all you'll need more CPU and hosting power here and there to run your beast. And CPU is never free. I'd be pleased to see the debate around the Java community shift from programming practices and tech buzzwords (IoC AOP ligthweight whatever is best implemented here things) to some from the trench real project end to end considerations. So FOSS - free as in free beer? Really? The world is obviously more complex than that.
[
avasseur
]
10:57, Friday, 23 December 2005
Last week I had the pleasure to discuss some more with the Spring team at JavaPolis, and I was thus given a quick informal update on what they are heading at in Spring 2.x, especially on the AOP side, discussing with Rod and Rob. Spring AOP in Spring 1.x has been easy to use - though missing a good pointcut language. This simplicity is well described in a recent article on dev2dev by Eugene, and I had debated this issue and tried to solve it with Spring pointcuts on steroids with AspectWerkz. In Spring 2.x, with the help of newly appointed excellent Adrian Coyler as chief scientist, my AspectJ lead peer, Spring AOP will unleash AspectJ and @AspectJ that I spent quite some time on this year as per our engagement to merge best of breed AspectWerkz with AspectJ. But going beyond, Spring 2.x also introduces a way to define aspects in your spring bean xml files directly f.e.: <aop:aspect id="countAgeCalls" ref="countingAdvice"> <aop:pointcut id="setCalls" expression="execution(* *..ITestBean.set*(..))"/> <aop:advice pointcut="execution(* *..ITestBean.set*(..))" method="myBeforeAdvice" kind="before"/> <aop:advice pointcut-ref="setCalls" method="myAfterAdvice" kind="after"/> <aop:advice pointcut-ref="setCalls" method="myAroundAdvice" kind="around"/> </aop:aspect> This is actually a really nice feature that I started playing with 2 years ago when implementing AspectWerkz with Jonas. So there is not much innovation there. There might actually be some issues and hard work going forward. By having aspects defined this way, the AspectJ runtime that is used when your are using the excellent AJDT Eclipse Plugin for AspectJ will not take those into account (whilst regular @AspectJ ones are fully supported). This means there 'll be definitely a need to open-up some more AJDT and have some extension point in it so that the Spring IDE can leverage it and have the AJDT crosscutting view display the Spring xml defined aspect. Wups - xml defined aspect I have said - just like this June 2003' Jonas article introduces, back in AspectWerkz 0.6.3 Maturity - finally!
[
avasseur
]
18:06, Wednesday, 22 June 2005
I thought it would be interesting to post what kind of session and BOF I am planning to attend during JavaOne 2005 next week. There are indeed interesting trends going on, and needless to say I don't really want to hear that the EJB (3) XML deployment descriptors are back or that kind of things. Instead, AOP, Annotations and distributed architectures will get my interest.
See you there !
[
avasseur
]
12:14, Wednesday, 1 June 2005
As a person largely involved in the Java Open Source landscape, I have been observing radical changes during the last 5 years in this area, and the 5 years birthday of Struts makes me comment it some. Five years ago, I was starting my own Struts clone for PHP to try to bring an MVC model to the rather new PHP OO stack I was using on a customer site. This project ended up pretty much nowhere (e-php on SF) since, well..., I could luckily do something way more interesting. At that time, I also remember sales folks arguing that a Java developer had to have "fluent in Struts" in their resume to actually be a good Java Joe developer (before that you had to have "fluent in Javascript" in their mind, so we had made a big progress for the IT consultants thanks to Struts ;-) ) Most of the (good) Java Joe developers where using Apache projects from the Jakarta line mainly as their sole Open Source use in corporate projects, and Tomcat was pretty much the sole Open Source container that you could find in production. At that time JBoss started to change the game by grabbing several Open Source fames and projects on board (Tomcat, and then Hibernate to name the most famous). Next in the pie, Eclipse went bigger and bigger, and Open Source projects that were used and presented in conferences were more and more backed by someone that could afford it. AOP and IoC started to gain in popularity, and Spring was doing its first moves. It became common to see "fluent in Hibernate" in job description, and I remember the first time I actually noticed it was in february 2003. I have been pushing the AOP ball since that time as part of my BEA job, and Open Source was more and more playing with sharks. AspectWerkz was backed by BEA, AspectJ revealed to be largely backed by IBM as an Eclipse technology project, and sucessfull projects that you could hear about in conferences where almost all backed by a shark - be it a big open source community like Apache, Eclipse, ObjectWeb that can afford its own events, or by a commercial vendor like BEA, IBM or JBoss. Back in 2004 the Spring fame became a shark by its own thanks to a well shapped service model around Rod' Interface21, that obviously adressed (and still adresses) Java Joe developer needs. Last year I was wondering when I would see a "fluent in Spring" requirement in an IT job description, and it happened this morning, on the same line as "Tomcat, JBoss, Hibernate" for a "challenging J2EE architect opportunity" (interested?). I have the feeling that Open Source will not be anymore this hectic group of people working for free for the fun of it as that sound to be back in 2000. Open Source is becoming more and more a distribution channel or a big thing to take into account when thinking about return on investment. If you look closely at some open source projects, you 'll also realize that it is rather common that 80% if not more of the workload is handled by a group of people sitting on the same open space. The recent deal (backed by concrete M$) done around Geronimo (project that was already backed by Apache) is yet another evidence. Open Source is playing with sharks, so you'd better love that. And if you do want to kickstart an Open Source project, you'd better think which shark will play with you if you want your jewel idea to sustain. As a last evidence, almost every single IT service company in France finally spinned of an official department dedicated to Open Source, bridging the gap with "SSLL" models (french acronym for open source service provider, doing consulting only on OSS stacks) . I have noticed this trend those last few months (Devoteam, Atos to name a few). Open Source is not anymore the thing you use to maximize revenues, or to make sure you recruit uptodate brains. It's the thing you have to play with straight within your strategy, no matter if you are a software vendor or an IT service company. So what will be the next Open Source moves in the Java are(n)a ? (note: dates in that post are those I remember and might be approximations. Aside, the job opportunities I am talking about are all for the French market, so you may expect some delta)
[
avasseur
]
16:50, Thursday, 14 April 2005
In this post I present an implementation a subset of the EJB 3 specification (JSR-220) : the EJB interceptors. As of today no EJB 3 preview brings an implementation that seamlessly integrates with AOP, despite the concept similarities. Should we consider EJB interceptor as AOP ? As you may know, the EJB 3 specification (JSR-220) defines Interceptors for EJBs (stateless, statefull and message-driven). If it might be a good idea to spread an answer for the need of addressing cross-cutting concerns in J2EE and EJBs in particular, it might be a bad idea to do it for those of us (more and more numerous) familiar with AOP implementations like AspectJ and AspectWerkz, especially because huge limitations of what the specification allows us to do with those interceptors - at first sight and excluding any vendor specific extension. The most anti-AOP concept in the specification is that the EJB that wants interceptor have to declare it explicitly using a @javax.ejb.Interceptor or @javax.ejb.Interceptors class level annotation - which breaks the obliviousness of aspects. That in favor of making things explicit, which might be good for J2EE users. Further on, the EJB bean itself can have a method that intercept its own business method ie the bean is the aspect (that sounds like marketing isn'it ?). Well. That's a specification and is interesting in the sense that it democratize a technology. So what can we do to democratize AOP as part of the EJB 3 specification ? @javax.ejb.Stateless
@javax.ejb.Interceptor("test.ejb3.MyInterceptor")
public class MyEJBIsTheAspect {
// business method
public int businessSum(int i, int j) {
return i + j;
}
// interceptor method within the bean (the bean is the aspect)
@javax.ejb.AroundInvoke
public Object interceptMySelf(InvocationContext ctx) throws Exception {
System.out.println("--> MyEJBIsTheAspect.interceptMySelf");
System.out.println(" method: " + ctx.getMethod());
for (int i = 0; i < ctx.getParameters().length; i++) {
Object o = ctx.getParameters()[i];
System.out.println(" args["+i+"]: " + o);
}
return ctx.proceed();
}
}State of the art (not that much..) in JBoss and Oracle AS EJB 3 preview After having a look at JBoss EJB 3 and OracleAS EJB 3 previews, I was even more disapointed. Both of them are using a reflective based approach to invoke the interceptors. This means that the performance of the interceptor will be bad, and that a Heisenberg effect will be inevitable and actually fairly big (no wonder that ones will use interceptor to gather performance metrics and thus as soon as you observe the bean, you are observing a different things than what actually happens). Ones may say this is a microscopic view. It is. But when thinking about EJB 2 stories in the past a sound idea would be to make sure we don't waste resources where we can avoid it. And thinking about JBoss history around AOP, that's rather suprising that the EJB 3 interceptors are not cleanly integrated in their AOP framework. I personnaly consider that we have enough technology around to make it far better, and far more consistent with AOP. Given the impact that AOP will continue to have, ones would better figuring out how to do that now with EJB 3 - assuming that EJB 3 succeeds. AspectWerkz extensible container value proposal to EJB 3 interceptors I decided to give it a try with the AspectWerkz extensible container. As Jonas Bonér described it in a TSS article, AspectWerkz can be considered as a generic AOP runtime platform, in which ones can hook in any kind of AOP/AOP like programming model. AspectWerkz aspects are one, AspectJ aspects are another, and we have implementations for Spring AOP and AOP Alliance aspects. An AspectModel answers three essential properties: what is the life cycle of the aspect, how to invoke it and how the programming model exposes the closure with wich the user proceed. It happens that the EJB 3 interceptor can be seen as a very simple AOP programming model in two ways:
public interface javax.ejb.InvocationContext { public Object getBean(); public Method getMethod(); public Object[] getParameters(); public void setParameters(Object[]); public Context getEJBContext(); public java.util.Map getContextData(); public Object proceed() throws Exception; } The value proposal I am bringing here with the AspectWerkz extensible container is the following:
AspectWerkz extensible container details To better understand how things will looks like, you need some background in AspectWerkz: The first key part is "org.codehaus.aspectwerkz.transform.inlining.spi.AspectModel". We will provide two implementations of it. One for interceptor class (the interceptor class is the aspect), and one for bean as interceptor (the bean is the aspect). The second key part is in integrating the EJB interceptor closure "InvocationContext" that defines the "proceed()" method with the more general idea of "Joinpoint.proceed()" of the runtime. In short, this means that the interceptor will be entirely part of the aspect chain, and if there is a transaction aspect to handle EJB transaction boundaries, they will share the very same chain - as ones expects - thus making it easy for the implementation to organize precedence rules (as define in section 3.5.1 of JSR 220 for example). As we already wrote this transaction aspect for EJB 3 in a previous AspectWerkz TSS tutorial, that's rather a simple idea and basic requirement. The runtime will take care of aggregating the models depending on which aspect apply to which join point, each aspect having its specific AspectModel and each AspectModel implementation being responsible for generating what it needs: // a closure to deal with the join points // ie models org.codehaus.aspectwerkz.joinpoint.JoinPoint interface // to fit with the transaction aspect, or any other aspect // and javax.ejb.InvocationContext to fit EJB3 interceptors class jitEJB3Closure implements JoinPoint, InvocationContex { // the closure hosts state, optimization makes it more complex than that // the target of the join point ie the intercepted ejb // which is also third aspect: remember the bean is the aspect ! private MyEJBIsTheAspect target; // first aspect in the chain, statically compiled private TXAspect aspect_0; // second aspect: the interceptor class private MyInterceptor aspect_1; // details skipped that makes those fields initalized as they should. // as defined in javax.ejb.InvocationContext public Method getMethod() {...} // as defined in JoinPoint public Class getTargetClass {...} // other methods as per each aspect model affecting the join point ... // generic proceed() method as defined in JoinPoint and InvocationContext public Object proceed() throws Throwable { // sort of a loop to proceed with the advice chain // case first round: TX aspect // TX aspect // as defined in the "AspectWerkzAspectModel implements AspectModel" aspect_0.manageTX(this) // "this" is considered as the JoinPoint instance ... // case second round: interceptor class // as defined in the yet to be written // "EJBInterceptorModel implements AspectModel" aspect_1.someNameOfYourChoice(this) // "this" is considered as the InvocationContext instance ... // case third round: the bean is the aspect // as defined in the yet to be written // "EJBIsTheAspectModel implements AspectModel" target.interceptMyself(this) // "this" is considered as the InvocationContext instance ... } } That may sound a bit of gory details, but that's actually simple once you get the idea of this closure acting for multiple AspectModel in mind. The code is actually 15O lines for the interceptor class model (EJBInterceptorModel) and 25 lines for the bean is the aspect model (EJBIsTheAspectModel) thanks to some inheritance. It mainly deals with
What about the deployment ? I presented the runtime, but there is an interesting topic as well: the deployment. AspectWerkz pioneered the aop.xml to define which aspects are affecting the system. Obviously, we don't want that for EJB interceptor. We need to use the AspectWerkz API to register what we need in the system. The interesting concept here is that we will transform what the EJB specification defines thanks to annotation (@javax.ejb.Interceptor, @javax.ejb.Interceptors, @javax.ejb.AroundInvoke) in real AOP pointcut that the AOP container understand. That is where a vendor may easily hook in an extension (ie introduce a new annotation for example) to refine the interceptor class life cycle, or to introduce a pointcut. I am defining a class that will expose an API that will hide the AOP registration from the user or from the other parts of our spec. implementation. public class EJBInterceptorDeployer { public static void deploy(String ejbClassName, ClassLoader loader) { // step 1 - interceptor class // read the ejbClass @Interceptor and @Interceptors class level annotation // for each interceptor class name found as value of those annotation // get the @AroundInvoke method information // deploy an aspect // using the EJBInterceptorModel // to the pointcut : "execution(!@javax.ejb.AroundInvoke !static * " + ejbClassName + ".*(..))" // // step 2 - @AroundInvoke method of the bean itself // find the @AroundInvoke method if any // deploy an aspect // using the EJBIsTheAspectModel // to the same pointcut } // method making use of AspectWerkz aspect deployment API } The thing to note about the deployer is that it is not using reflection. It is f.e. using our BackPort175 implementation to read the EJB annotations from the bytecode. If we were not doing so, we would trigger the EJB class loading while our system is not yet defined, and the weaver would not be able to do the job when using load-time weaving approaches. What about running the system ? In the sample application, I am deploying the EJB using the EJBInterceptorDeployer presented in the previous section. In a full blown container I would hook the call to it when the application or EJB deployer would register the EJB in the system. The nice thing is that I can run my EJB and still have the interceptors when running as a standalone application by using AspectWerkz load time weaving, and a simple static block to declare which class is an EJB. The sample application can be run with (for ones familiar with AspectWerkz, there is no aop.xml..) java -javaagent:lib\aspectwerkz-jdk5-2.0.jar test.ejb3.Sample public class Sample { static { EJBInterceptorDeployer.deploy("test.ejb3.MyEJBIsTheAspect", Sample.class.getClassLoader()); } public static void main(String args[]) throws Throwable { // some one would do a lookup or inject for that when in the container MyEJBIsTheAspect myEjb = new MyEJBIsTheAspect(); System.out.println("Calling the EJB"); int i = myEjb.businessSum(1, 2); System.out.println("got : " + i); } } AW EJB3 - Deploying test.ejb3.MyInterceptor for test.ejb3.MyEJBIsTheAspect AW EJB3 - Deploying test.ejb3.MyEJBIsTheAspect for test.ejb3.MyEJBIsTheAspect Calling the EJB --> MyInterceptor.interceptStandalone method: public int test.ejb3.MyEJBIsTheAspect.businessSum(int,int) args[0]: 1 args[1]: 2 --> MyEJBIsTheAspect.interceptMySelf method: public int test.ejb3.MyEJBIsTheAspect.businessSum(int,int) args[0]: 1 args[1]: 2 got : 3 Conclusion Though at first glance I found the interceptor part of the EJB 3 specification fairly odd, and was a bit sad that some important AOP concepts like precedence and aspect life cycle, as well as expressiveness of the pointcut language are completely sacrified, I must admit that it might help ones familiarize with AOP concepts. It took 1h to implement the EJB 3 interceptor spec and have it perfectly integrated with AOP - unlike so far exposed EJB 3 previews by JBoss and Oracle (though those are actual preview, while this article is more a technology focus and positionning). It took 15 minutes more to implement a pointcut extension thru a new @org.codehaus.aspectwerkz.ejb3.AroundInvokeAOP annotation, that allows me to reuse the expressiveness of the pointcuts ie a vendor extension: public class MyInterceptor { @AroundInvoke @AroundInvokeAOP("execution(* *.businessSum(..))") public Object interceptStandalone(InvocationContext ctx) throws Exception { System.out.println("--> MyInterceptor.interceptStandalone"); System.out.println(" method: " + ctx.getMethod()); for (int i = 0; i < ctx.getParameters().length; i++) { Object o = ctx.getParameters()[i]; System.out.println(" args["+i+"]: " + o); } return ctx.proceed(); } } Some more time would allow me to have further features, like f.e. supporting cflow and args pointcut, so that an interceptor may look like an advice as it looks like in AspectWerkz aspects, with static access to intercepted method arguments etc (ie no boxing in an Object[] array). A next iteration would be to integrate with the AspectWerkz hot deployment feature, and this would bring in hot deployment of EJB interceptors at no cost - while still having everything statically compiled for the runtime to perform at its best. This implementation may seems at first glance full of details, and perhaps like a hammer to address a simple part of the spec. I don't think so. I think it address the very crucial point that so far everyone has skept - including JBoss folks (that have a foot in the AOP trench): it integrates seamlessly with the aspects and AOP concepts, and actually allow advanced user to apply more advanced AOP concepts as well ie bridging the gap between a commercial concept and needs (EJB interception) and a sound concept backed by years of research (AOP and cross-cutting). So which vendor will be the first to have its EJB play well with AOP : like applying an interceptor thru a real pointcut, defining programmatic precedence etc, dealing with cflow and hotdeployment of interceptors, and all that with an implementation that can scale ? Want the source code ? This one is part of AspectWerkz CVS. It can be browsed from here. Side note: my feedback on the specication: There are some odd things in the 3.5 section of the JSR-220 that I have spot:
Fortunately, the implementation exposed in this article addresses those issues nicely from a vendor specific extension perspective. Note: These are my own thoughts and not of my employer ..
[
avasseur
]
17:14, Wednesday, 23 February 2005
That's an exciting time for BEA. We now have announced we are joining Eclipse with a number of interesting things in the pipe, ranging from AOP with the AspectWerkz/AspectJ effort leading to AspectJ 5, to the IDE part that will shape up BEA WorkShop, and leading positions in the Web Tools Platform, and in the JDT compiler area. Things were a bit odd when we shipped an AspectWerkz Eclispe plugin some month ago, since everyone out there was thinking that there was a death match between BEA WorkShop and Eclipse... Didn't you thought that way ? And don't say we have started to sneak in randomly just to catch up. Things are now ranging from the JVM with AOP work going on within JRockit up to the IDE... Read the news
[
avasseur
]
15:26, Tuesday, 22 February 2005
Last time I was reading about a project, folks were arguing they had many many tests. But what is exactly this measurement ? Do we have to count the number of classes that extend The current figures for AspectWerkz are pretty much those one: Off course, what would matter would be the coverage (that has several definitions as well), but still, the number of test in an interesting thing to define. So how many tests do I have ?
[
avasseur
]
18:02, Tuesday, 15 February 2005
Today Jonas and I shipped Backport175, a back port of the JSR-175, the Java 5 Annotations spec. This project comes with an Eclipse plugin and an IDEA plugin, so its time to say something about IDEA... I just like the architecture of the IDEA plugins. There is very few docs on the topic, some very bad javadoc, and some samples around but no books yet etc. The nice thing in IDEA plugins is that it s just code, a rather clear API, and a bit of IOC (IDEA is using PicoContainer). A plugin as just one XML descriptor. What is missing the most in IDEA v4 is a good plugin project wizard, but if you have the chance to give a try to IDEA IRIDA, the EAP of the upcoming v5, then you have it, and it's as easy to debug your plugin as it is for a regular app. You can probably learn some in that space by comparing both Backport175 plugins. It will leads you thru Off course, it is probably not the correct design neither for Eclipse nor for IDEA (I am far from beeing efficient in that plugin area) but it seems to do the job. IDEA plugin CVS Thanks to JetBrains to allow free use of IDEA for OSS projects !
[
avasseur
]
13:56, Thursday, 20 May 2004
I am moving to San Francisco for BEA eWorld. Jonas and I will give several sessions / demos about AOP in BEA JRockit and the BEA WebLogic Platform, including WebLogic Server and WebLogic WorkShop. In case you are in the area but do not attend to eWorld, just join the Silicon Valley BEA User Group since we will be there on wedsnesday as well. We have been under the radar since AOSD, so be ready for something disruptive !
[
avasseur
]
13:02, Tuesday, 17 February 2004
Most of my blog' fans (do I have blog fans ?) might think I am hacking AOP constructs and weaving architecture all the day. Well I have to admit that this is not exactly true, thought almost true ;-). These days I had to hack a small app that gather data from a WebLogic Server farm (more than 60 servers) by querying runtime JMX mbean so that we can then generate some graph to feed a NOC intranet. For now the logs are parsed and consolidated as regular file. I would have liked to use a MySQL or HSQL database instead of parsing Go of files... but well, it is a customer driven story. Here is a pretty cool graph that I got using JFreeChart that shows some http session data history grabbed from a subset of the farm.
[
avasseur
]
12:14, Monday, 3 November 2003
Last day I realized that using ThreadLocal can be very dangerous when it comes to long running applications and garbage collections. When you read the documentation of the ThreadLocal, you read that the object put in a ThreadLocal context is associated to the thread, and will be garbaged once the thread is dead.
So if you use ThreadLocal to store some object instance there is a high risk to have the object stored in the thread local never garbaged when your app runs inside an app server like WebLogic Server, which manage a pool of working thread - even when the class that created this ThreadLocal instance is garbage collected. To solve this issue, you will probably have to check for it first with a memory profiler tool like JProfiler, and then wrap the value put in the ThreadLocal in a WeakReference. That did not appears to be obvious while reading the javadoc. Isn't it ?
[
avasseur
]
18:38, Wednesday, 23 July 2003
Past 6 month I have founded and developped the beSee project. This project is now closed, but I am definitely happy since the core architecture is now part of AspectWerkz, founded by Jonas Boner, for which I am commiter. AspectWerkz power will be unleashed in the next weeks, and let me explain why. It all started with beSee-1-x. This project aimed to provide a runtime bytecode instrumentation solution for BEA WebLogic Server (v7), based on Javassist for bytecode instrumentation and BEA ClassPreProcessor feature, which allow to modify bytecode of deployed applications when they are loaded in the app server. But there was something missing: BEA ClassPreProcessor does not allow instrumentation of core server classes or jvm wide component, like a JDBC driver, so I was unable to instrument enough my CMPs to track down SQL query being executed. I started beSee-2-x architecture. It provides a JVM wide PreProcessor hook, allowing to extend what BEA provided for deployed application to the whole JVM, and thus to any product running java (!). So the main features of beSee-2-x I implemented are: beSee-2-x allowed me to unleash the power of beSee-1-x to the whole weblogic, not just the deployed app. So stay tune. All those features are right now in AspectWerkz CVS, and in some weeks, you won't feel the pain to plug AOP in your whole architecture, on the fly or offline, and with its full power - no debug mode required, java 1.3 supported, optional process forking (choose between tuning and easy set-up), not tight to any app server but certified app server ready.
[
avasseur
]
17:43, Wednesday, 23 July 2003
I have submitted a patch for the BCEL thread safe issue I described (read). You'll find it on the BCEL dev mailing list archive. I am waiting for BCEL guy to put the patch in their CVS HEAD. For now you can whether incorporate the patch in the BCEL source and rebuild your own BCEL, or build a jar with only the two files I patched and put it in your classpath before the bcel.jar.
[
avasseur
]
12:00, Saturday, 19 July 2003
Using BCEL to do bytecode modification on a simple application I have, I encountered problems with thread safety. As soon as I got 2 threads instrumenting in parallel, the java Verifier begins to complains about generated method signatures. I struggled half a day to find it out. Thread safety problem is not that easy to isolate. After some googling I found the following post on BCEL mailing lists It appears that some of BCEL static class (org.apache.bcel.generic.Type and org.apache.bcel.classfile.Utiity at least), which should provides static method to compute human understandable signature from bytecode and vice-versa are miscoded. If I understand that doing a thread safe application can be difficult, I am really thinking BCEL guy were lazy this time with a snip like // sample purpose - pseudo code package org.apache.bcel.classfile; As we can see its obvious it is non thread safe because its bad designed: two static methods are using the same static field as a temporary storage to perform string operations. I had to wrap the consumed_chars in a ThreadLocal and replace all calls. It works fine, but I cannot be sure I covered all the bad design BCEL put in. Guy, ok to say BCEL is not designed for thread safety in the FAQ. But please try to avoid such ugly coding. Another option for me could be to add some synchronized in my instrumentation application - but it would be a hell from a performance point of view. |
