Community
Participate
Working Groups
I don't understand how this bug can be closed just like that. I'm learning and trying to adopt AOP to my programming experience. Here is what happened when I tried to use contract4j aspect library with aop.xml. After several days of tweaking and testing, I found out that I need to enumerate all the aspects defined in contract4j to get it working with aop.xml! This is a little ridiculous! Shall I blame the guy who developed contract4j for not providing one single aspect for his library? Shall I blame that aspect is so difficult for beginners to adapt? The basic argument for not having this feature is similar to the following, "because fire can be sometimes dangerous, so our human race should not use fire at all!" which doesn't seem acceptable to me at all! The bottom line is that there should be at least one way of bulkly specifying aspects that need to be woven, in one word, it should give the power to the user and warn them to be careful. +++ This bug was initially created as a clone of Bug #93320 +++ I have found that using the current branched aop.xml format, which requires explicit enumeration of all aspects in the project, to be very brittle in the face of refactoring or adding new aspects. It would be much better if we could specify the equivalent of an aspect path (jar files or exploded classes directories) which will be scanned for aspects to apply. It would also be very useful to support an equivalent of inpath (i.e., to separate aspectpath, which specifies aspects that are applied but not woven, and inpath which can potentially include aspects and weave them). I would be willing to work on code to do these things once the loadtime branch is merged into HEAD, if it would help.
Let me start by reiterating why aspectpath is a bad idea for LTW, I will explain why you had trouble with Contract4J and then suggest some ways to avoid such problems in the future. As Alex clearly points out in the original bug report using JAR names makes no sense in general when applications can be packaged in a number of complex ways e.g. EAR/WAR, loaded across the network or generated on the fly. The traditional classloader hierarchy is being abandoned (because it is flawed) and being replaced by more complex delegation models e.g. OSGi where the concept of classpath is non-existent. Performance has been a challenge for LTW so enumerating all the classes in a possibly unbounded set of JARs on the off chance we might find an aspect is impractical. I have not used Contract4J but I assume that it comprises one or more JARs that contain one or more Aspects. I also assume these can be used for either compile-time or binary weaving with -aspectpath. When you chose LTW what "interface" were you using? If the authors of Contract4J do not list the aspects supplied then they have not anticipated your use of LTW and it may not even work at all. In which case I do "blame" them for not using the "-outxml" compiler option or documenting the aspects. You are trying to use LTW, which is quite advanced for someone new to AspectJ, in conjunction with a 3rd party application which may not have been intended to be used that way. I am not at all surprised it took you several days to get something working! I strongly suggest you start simply with binary-weaving to ensure your application is working correctly. You could then use "-showWeaveInfo" which would identify the aspects being used. You could then easily write your own aop.xml or indeed contact the authors of Contract4J to supply one.
Thanks for your quick response. However I am still not convinced that the reasons for not having an aspectpath sort of thing in aop.xml are strong enough. 1. performance issue. Having to find all the classes just by using classpath happens to the standard class loader even without using aspectj. I agree that classpath is flawed, classloader is flawed but they are going to be there for a long time! are we going to abandon this idea completely right now?? On the other hand, why don't allow both? User can either enumerate all the single aspects, or they can provide a couple of jar file that contains all their aspects and of course this jar file will have to be examined by LTW and indeed some time will be spent on it. On the other hand, LTW will be slower than binary weaving and compile time weaving, anyway! The advantage of LTW is not that it's fast but it's more convinient for deployment time aspect configuration. How can we claim this goal is fulfilled with the current cumbersome aspects enumeration? Finally, some clearance on contract4j. Their website is www.contract4j.org. The author of contract4j indeed advocates LTW other than the other two methods, for the obvious reason: LTW is the least intrusive solution. > +++ This bug was initially created as a clone of Bug #93320 +++ > > I have found that using the current branched aop.xml format, which requires > explicit enumeration of all aspects in the project, to be very brittle in the > face of refactoring or adding new aspects. It would be much better if we could > specify the equivalent of an aspect path (jar files or exploded classes > directories) which will be scanned for aspects to apply. It would also be very > useful to support an equivalent of inpath (i.e., to separate aspectpath, which > specifies aspects that are applied but not woven, and inpath which can > potentially include aspects and weave them). > > I would be willing to work on code to do these things once the loadtime branch > is merged into HEAD, if it would help. >
>Having to find all the classes just by using classpath >happens to the standard class loader even without using aspectj. Not true. A classloader does not enumerate the contents of its classpath rather it loads specific class files on demand. Worse still the ASPECTPATH approach would involve loading and parsing the byte-code twice: once to look for aspects and again to actually define a class. >I agree that >classpath is flawed, classloader is flawed but they are going to be there >for a >long time! are we going to abandon this idea completely right now?? No. We devised a mechanism that works with all class loaders without needing to know how they work. >On the >other hand, why don't allow both? User can either enumerate all the single >aspects, or they can provide a couple of jar file that contains all their >aspects and of course this jar file will have to be examined by LTW and indeed >some time will be spent on it. Because an ASPECTPATH makes no sense in all but the most simple systems (please read Alex's comments again). It must be kept in step with CLASSPATH: maintaining configuration in two places is always a bad idea. The resulting application is not portable because the ASPECTPATH must be changed for each new deployment. >On the other hand, LTW will be slower than >binary weaving and compile time weaving, anyway! The advantage of LTW is not >that it's fast but it's more convenient for deployment time aspect >configuration. The performance of an ASPECTPATH is only one reason for not supporting it however their is no point in making something slower than it needs to be. >How can we claim this goal is fulfilled with the current >cumbersome aspects enumeration? You tell me which is more cumbersome: building your aspects with "-outjar ... -outxml" and simply adding it to CLASSPATH (like any other JAR) or having to configure and maintain ASPECTPATH (which may not work anyway e.g. OSGi, many application servers, ...) as well? One important thing that you forget is that aop.xml is a statement of intent: it says "I want these aspects". If AspectJ can't find one then you get an error which can be quite important if it's a security aspect! On the other hand with ASPECTPATH I just get the aspects that AspectJ can find, whether I want them or not. Thanks for the link to Contract4J. I had a look at their download and saw that it includes an aop.xml file that enumerates all their aspects. If you follow their example that uses "aj5" everything should work OK so I fail understand why you had so much trouble.
Thank you again for your prompt reply! This will probably be my last email, I decided to just go with compile time weaving for now. Not because I gave up my standpoint but because I am just learning it for fun for now. However, please read my comments. Thanks! (In reply to comment #3) > >Having to find all the classes just by using classpath > >happens to the standard class loader even without using aspectj. > Not true. A classloader does not enumerate the contents of its classpath rather > it loads specific class files on demand. Worse still the ASPECTPATH approach > would involve loading and parsing the byte-code twice: once to look for aspects > and again to actually define a class. > I didn't say that classloader enumerates the contents of its classpath (at once). I didn't even use the word "enumerate". I meant a class is found by using classpath possibly through a chain of delagation to the bootstrap classloader or the root classloader that is built-in the jvm. How does root classloader or bootstrap classloader find and extract the definition of a class? By using classpath that supports jar files! You are right for aop ltw, perhaps to do it naiively, you need to parse classfiles twice. Jvm avoids future redundant loading by using a cache. Can aspectj learn from it? I don't know. Because weaving requires all the weaving classes already known to the weaver before weaving starts. I agree that performance hit can happen. However, just consider the fact that there won't be many aspect jars. I don't see why this just can't be done. > >I agree that > >classpath is flawed, classloader is flawed but they are going to be there > >for a > >long time! are we going to abandon this idea completely right now?? > No. We devised a mechanism that works with all class loaders without needing to > know how they work. I'm a bit confused. which meachanism? you mean the current meachanism where user has to enumerate all the aspects himself? Or a new mechanism that will be used in the near future? > > >On the > >other hand, why don't allow both? User can either enumerate all the single > >aspects, or they can provide a couple of jar file that contains all their > >aspects and of course this jar file will have to be examined by LTW and indeed > >some time will be spent on it. > Because an ASPECTPATH makes no sense in all but the most simple systems (please > read Alex's comments again). It must be kept in step with CLASSPATH: > maintaining configuration in two places is always a bad idea. The resulting > application is not portable because the ASPECTPATH must be changed for each new > deployment. I agree too that it is not a good design. Unless java has aspect support built-in, I don't see an easier way to avoid it either. The current aop.xml is not portable either (or at least not easily maintable). What if I foget to take out an aspect that has been merged into another existing one! > > >On the other hand, LTW will be slower than > >binary weaving and compile time weaving, anyway! The advantage of LTW is not > >that it's fast but it's more convenient for deployment time aspect > >configuration. > The performance of an ASPECTPATH is only one reason for not supporting it > however their is no point in making something slower than it needs to be. > I have limited experience in J2EE programming, and performance reason is the only obvious reason I can see. I will read other people's posts more carefully. > >How can we claim this goal is fulfilled with the current > >cumbersome aspects enumeration? > You tell me which is more cumbersome: building your aspects with "-outjar ... > -outxml" and simply adding it to CLASSPATH (like any other JAR) or having to > configure and maintain ASPECTPATH (which may not work anyway e.g. OSGi, many > application servers, ...) as well? I'm not building aspects! at least not now! I am purely using aspects from third party. > > One important thing that you forget is that aop.xml is a statement of intent: > it says "I want these aspects". If AspectJ can't find one then you get an error > which can be quite important if it's a security aspect! On the other hand with > ASPECTPATH I just get the aspects that AspectJ can find, whether I want them or > not. This can go either way. I can also say I want all the aspects in this jar file to help me enforce "design by contract" annotations. I don't care their exact names. > > Thanks for the link to Contract4J. I had a look at their download and saw that > it includes an aop.xml file that enumerates all their aspects. If you follow > their example that uses "aj5" everything should work OK so I fail understand > why you had so much trouble. > The author of the contract4j gave a quick tutorial on his website without mentioning anything about the existence of aop.xml! I had to figure this out myself by digging through the aspectj documentation. The second reason is that I am not using aj5 but eclipse IDE. I intended to set the -javaagent option with a standard java application project, but because aop.xml was not there, it didn't work. Here is the last question for you. Suppose I am just a developer for a graphics application without any knowledge of AOP. But my company decided to adopt a few third party aspect libraries to enforce coding sytle including but not restricted to "design by contract" etc. The libraries use annotation as frontend, and thus keep the complexity of aspects behind the scene. Are you saying I have to find out the exact aspects that are used?? Again, my point is not efficiency but user-friendliness. Put it another way, the fundamental question is why asking the user to enumerate all the aspects explicitly is better? Or is it always better? Is it the best solution? Isn't "the user should do more, so we can do less and do it correctly " solution always universally applicable but universally lame as well? final comment: think of a jvm that only support -classpath option that requires you to list all the class files, but doesn't allow you to specify jar files. I may completely ditch java!
>I didn't say that classloader enumerates the contents of its classpath (at >once). I didn't even use the word "enumerate". I meant a class is found by >using classpath possibly through a chain of delagation to the bootstrap >classloader or the root classloader that is built-in the jvm. The point I am making here is that when HelloWorld is loaded from a JAR the class loader does not have to load every single class file in the JAR file (enumerate), only the one containing HelloWorld. However because AspectJ _must_ know all aspects _before_ a single class is loaded and defined, an ASPECTPATH implementation would require all class files in all identified JARs to be loaded and parsed to see which are aspects. This would be expensive in all but trivial systems. >However, just consider the fact that there won't be many aspect jars. I don't >see why this just can't be done. There is no reason why every JAR in the system shouldn't define an aspect. >I'm a bit confused. which meachanism? you mean the current meachanism where >user has to enumerate all the aspects himself? Or a new mechanism that will >be used in the near future? It is the aspect _author_ not the user that must declare aspects. This is done automatically by the -outxml option. The user need only add the JAR to their classpath. >The current aop.xml is >not portable either (or at least not easily maintable). What if I foget to >take out an aspect that has been merged into another existing one! See previous. >I'm not building aspects! at least not now! I am purely using aspects from >third party. Again see previous. If you read the AspectJ documentation about LTW before trying to use Contract4J you would have know about the need for aop.xml. If you were curious you could have looked in the JAR as I did and found the one provided. >The author of the contract4j gave a quick tutorial on his website without >mentioning anything about the existence of aop.xml! He didn't need to. If you follow his instructions the demo should work. If you feel they are unclear I suggest you contact the Contract4J guys so others don't experience your problems. >I had to figure this out >myself by digging through the aspectj documentation. The second reason is >that I am not using aj5 but eclipse IDE. I intended to set the -javaagent >option with a standard java application project, but because aop.xml was not >there, it didn't work. It doesn't matter how you use LTW if you use the aop.xml provided your program should work. >Here is the last question for you. Suppose I am just a developer for a >graphics application without any knowledge of AOP. But my company decided to >adopt a few third party aspect libraries to enforce coding sytle including but >not restricted to "design by contract" etc. The libraries use annotation as >frontend, and thus keep the complexity of aspects behind the scene. Are you >saying I have to find out the exact aspects that are used?? Again, my point is >not efficiency but user-friendliness. No. The provider of an aspect library must include an aop.xml as described in the AspectJ documentation. Simply adding the libraries, just like any regular Java libararies, to your classpath (or other environment-dependent configuration) seems like the height of user-friendliness. >Put it another way, the fundamental question is why asking the user to >enumerate all the aspects explicitly is better? Or is it always better? Is it >the best solution? Isn't "the user should do more, so we can do less and do >it correctly " solution always universally applicable but universally lame as >well? Again I am not asking the user to enumerate aspects. I am not even asking the author to enumerate their aspects just use the -outxml option. We do ask users to the read the free documentation though before opening bug reports.
The previous bug report Bug 93320 "aop.xml format should support aspectpath style rather than enumeration" was closed, with the agreement of the raiser, because the feature was seriously flawed (although it should be noted that the suggestion to generate aop.xml has been implemented in Bug 95516 “aop.xml –outjar”). I am closing this report because it has neither addressed those flaws nor provided any compelling use-cases. While the idea of an aspectpath seems attractive in a simple LTW scenario or in a well controlled environment such as binary weaving it makes no sense in general. It has been suggested that we support both mechanisms for configuring LTW: aop.xml and aspectpath. Unfortunately there are situations when using each approach with the same aspect library (JAR) may yield different results e.g. not all aspects have been declared in aop.xml. More seriously an application developed using aspectpath may not be deployable because the target environment uses a non-standard packaging scheme so the author must use aop.xml anyway. My most serious concern with this suggestion is that it encourages legacy thinking, in terms of simple classpaths and JAR files, at a time when those approaches are being replaced e.g. OSGi. Furthermore an application that uses aspectpath is defined it terms of environment-specific configuration (path) rather that meta-data (dependencies, aop.xml) which is more portable. Each element of a complex system should be self describing, whether it is an aspect library or dependent application, something that can be achieved with aop.xml but not aspectpath.
