The AOP Caching Challenge

Discussions

News: The AOP Caching Challenge

  1. The AOP Caching Challenge (91 messages)

    In his weblog last week, Cedric Beust gave an example of how to use AOP to implement a cache, but then questioned whether AOP could allow the implementing of a separate CacheMonitor. What followed was an ongoing thread of discussion across multiple blogs in response to this challenge.

    See Cedric's AOP thread summary page and initial challenge.

    Threaded Messages (91)

  2. put it in xml and it's ++[ Go to top ]

    I guess more implementations of aspects has it's upsides. But the argument that aspectJ comes down to an extension of the language and aspectwerkz, which uses an XML format to express aspects, does not seems to me foolish.
    Is a computerlanguage better when expressed in XML?
    It takes shorter to implement because you don't need to define a grammar using BNF and implement the interpreter/compiler.
    But to me tags do not aid readability. Which seems a very important quality for a language.
    I shudder to think what would have been the result if cedric and rickard and the rest should have been at the cradle of Java: java in tags?

    Or is the appreciation for aspectWerkz due to the fact that it does not originate (directly) with a commercial firm like Xerox?

    groetjes,
    Joost
  3. Don't use XML to program[ Go to top ]

    <joost>
    Is a computerlanguage better when expressed in XML?
    </joost>

    Not at all. Quite the opposite.

    Everything I have been working on for these past years goes exactly in the opposite direction: the less I write XML, the better I feel, and I want to use tools that assist me in this quest. EJBGen is just one out of many.

    But just because I think that XML is hard to deal with doesn't mean it should never be used. There are cases when constructs that go beyond a programming language are needed, and Aspect-Oriented Programming is clearly one of them.

    That being said, I think the best approach to AOP is a mix of XML files and metadata used as hints by the weaving engine, but that's just my personal opinion.

    My appreciation for AspectWerkz simply comes from its elegant simplicity, nothing more. I wish it could incorporate some of the advanced features that AspectJ provides, but I am confident Jonas will get there soon.

    --
    Cedric
    http://beust.com/weblog
  4. aspectXml vs aspectJ[ Go to top ]

    <cedric>But just because I think that XML is hard to deal with doesn't mean it should never be used. There are cases when constructs that go beyond a programming language are needed, and Aspect-Oriented Programming is clearly one of them.</cedric>

    I agree that AOP goed beyond the language Java and is clearly needed. What I question is that
    1. aspects are better expressed in XML
    2. when expressed in XML they do not amount to an extension of Java and when expressed with a non-xml syntaxis they do.

    One could argue that since aspects are orthogonal to the constructs they refer to (Java) that they do not extend Java. They provide another dimension (no startrek-pun intended).

    Anyway I'd be interested to see aspectJ taking on the competition and making the same classloader thing possible.

    Was it Mao Tse Tung who said 'let a 1000 flowers bloom'?
    (I'm not from that generation)
     
    Joost
  5. aspectXml vs aspectJ[ Go to top ]

    <joost>

    One could argue that since aspects are orthogonal to the constructs they refer to (Java) that they do not extend Java. They provide another dimension (no startrek-pun intended).

    </joost>

    Right on!

    One could even surmise that when you start applying aspects to aspects, you add a third dimension to the picture...

    --
    Cedric
    http://beust.com/weblog
  6. aspectXml vs aspectJ[ Go to top ]

    It seems to me quite sensible that aspects, which cross and develop independent of the code they are applied to should be decoupled as much as possible from the API and mechanism used to apply them, even if it's using runtime bytecode modification. It makes even more sense given the rapid growth and tansformation of the paradigm and tools.
  7. AOP in XML is actually something that promises to manage some of the complexities that XSLT bring to the mix. I started up a small open source project recently to do just that, look at the advantages that cross-cutting concerns can reap when represented and processed in the XML. The project is in it's early stages (0.8 just released) but if anyone is up for the challenge then please feel free to check out www.aspectxml.org (we are in the process of a complete site re-location due to demand so please forgive the link problems at the moment).

    In answering another comment as to whether AOP should be in the XML at all, AOP offers as much to the declarative world as it does to the imperative world of Java. As to whether or not the cross-cutting concern is elicited within XML or within Java, this appears to me to be a moot point. By modularising the cross-cutting concern, and by being able to harness the advantages of using the abstraction that pointcuts represent, we can effectively free the developers from much of the complex transformations that would be necessary using XSLT alone to specify the aspects of their particular data sets.

    If it's useful to represent cross-cutting concerns in your software architecture, like AspectJ and others do for Java, then isn't it also useful to also be able to easily elicit cross-cutting concerns in the data itself.

    In fact when you consider the potential blurring between internal program data and external data messages that is proposed as part of projects such as Xen then it becomes a fairly simple conceptual jump to see that the same reasons for using aspects in structural OO software can benefit the data itself in the structural world of XML.
  8. put it in xml and it's ++[ Go to top ]

    Java is a quite expressive and clear language and with the modern refactoring IDEs of today (Eclipse, IDEA) there's little point in using a language that "doesn't require compilation".

    Nanning is entirely based on Java, for configuration and all purposes.

    I've yet to see an example where XML is more expressive than Java.

    But I guess this is an entirely different blog-debate. :-)
  9. put it in xml and it's ++[ Go to top ]

    <quote>
    I've yet to see an example where XML is more expressive than Java.
    </quote>

    This is not the point. You can express similar things in XML and Java, nobody disputes that.

    The point is that if you define the deployment descriptors of your aspects in Java, you need to recompile before you can redeploy them, which quickly becomes unacceptable.

    Imagine a classloader-type engine ("online" to use AspectWerkz' terminology). All it needs to do is read the .xml file and it can then weave the aspects as the classes get loaded.

    If the definition file is in .java, it needs to compile it first. Which is kinda dumb :-)

    --
    Cedric
    http://beust.com/weblog
  10. mixture of approaches[ Go to top ]

    Hi,

    As you suggest, I see benefits in keeping a combination of the two approaches. For example if the metadata is included in the compile step AND there is a XML descriptor that apply to the same language element, then the XML descriptor takes precidence. In this way, developers whose nose is in the code can feel at home (and we compile all the time anyway) and if someone needs to wear the "application assembler" hat, they can override the settings without recompiling. This would be more in line with a peaceful co-existence of compiled-in metadata and the way aspects are specified with external xml files.

    - Mark
  11. ... I have missed the IDE which can refactor XML files with attributes of classes in sub tags.

    And what do you do with classes already loaded? And if you use hot redeploy of classes, why not redeploy the .java advices?

    I think .java is much more agile than .xml and I want a framework that supports .java at first, letting me switch to .xml should my needs change (YANGNI). .xml from the start will slow you down a lot.

    bye
    -stephan
  12. And ...[ Go to top ]

    ... how do you programatically change advices with XML?

    bye
    -stephan
  13. Programming != declaring[ Go to top ]

    <stephan>
     ... how do you programatically change advices with XML?
    </stephan>

    You don't program your advice in XML.

    You program your advice in Java and you declare your pointcuts (and other stuff) in XML.

    --
    Cedric
    http://beust.com/weblog
  14. RE: put it in xml and it's ++[ Go to top ]

    <Cedric>
    Imagine a classloader-type engine ("online" to use AspectWerkz' terminology). All it needs to do is read the .xml file and it can then weave the aspects as the classes get loaded.

    If the definition file is in .java, it needs to compile it first. Which is kinda dumb :-)
    </Cedric>

    Agreed 100%. It is kinda dumb. :) But there are some people who don't need to imagine this kind of functionality. They can do it in Smalltalk and have been for a while. :) It all lies in the Art of the Metaobject Protocol. :)

    Have fun,
    Greg
  15. Re: Compilation and Smalltalk[ Go to top ]

    Agreed 100%. It is kinda dumb. :) But there are some people who don't need to imagine this kind of functionality. They can do it in Smalltalk and have been for a while. :) It all lies in the Art of the Metaobject Protocol. :)


    Dynamic typing (DT) and static typing will continue to be a point of contention as long as static typing engines make it difficult to implement what can often be done elegantly in a dynamically-typed language. I, believe, though, that the consensus seems to be that the validation which occurs in XML documents is a very important part of XML. (Otherwise, why invent a much more complex specification - Schema - capable of enforcing much stronger validation?) Validation of an XML document is roughly equivalent to static typing in a programming language.

    Compilation achieves both static typing and an efficient representation of the data. We've just established that static typing is desirable, and we know that the need for efficient representation of data is extremely commonplace (for example, compilation of stylesheets), therefore, I find that I must disagree with the assertion that compilation is "dumb".

    God bless,
    -Toby Reyelts
  16. The point is that if you define the deployment descriptors of your aspects in Java, you need to recompile before you can redeploy them, which quickly becomes unacceptable.


    Why is this unacceptable? As implemented, JSPs require re-compilation every time they are changed, and that has been very acceptable.

    > Imagine a classloader-type engine ("online" to use AspectWerkz' terminology). All it needs to do is read the .xml file and it can then weave the aspects as the classes get loaded.
    >
    > If the definition file is in .java, it needs to compile it first. Which is kinda dumb :-)

    Why is this dumb? I think you're caught up in some sort of false economy. Every time you load the XML file, the parser must validate it against its DTD/schema. Once the XML file is loaded, you must then validate the data which could not be automatically validated by the parser. Once you've validated the document, then you need to interpret that document based on it's declarative content.

    If you used Java, or some other DSL (domain-specific language), then the parser (compiler) is capable of performing much more complex validation then a typical XML parser. The AST created by a compiler is then roughly equivalent to the in memory document object created by an XML parser. But, the compiler takes it one step further, by translating the AST into executable bytecode as compared to the interpretation that occurs against an XML document.

    IMHO, what we need are better tools for easing the development of DSLs, especially those which can target a JVM. I think it's about time for people to start admitting that XML doesn't buy you anything more than a free parser for a fairly naive and verbose language.
  17. <toby>
    Every time you load the XML file, the parser must validate it against its DTD/schema. Once the XML file is loaded, you must then validate the data which could not be automatically validated by the parser.
    </toby>

    I think you are missing my point.

    I am not complaining about the cost of compiling. Obviously, parsing XML is akin to compiling Java, not much difference there.

    I am just objecting to the idea of using a programming language to write deployment descriptors that don't have any programmatic intelligence in them. If you want an analogy, it would be similar to saying "We don't need properties files, I can put these values in my Java sources". It's a step backward in flexibility in my opinion.

    Especially if you are going to put these values in the same code as the implementation of your aspects (at least, use a different class).

    --
    Cedric
    http://beust.com/weblog
  18. I think you are missing my point. I am not complaining about the cost of compiling.


    Well, then we agree on that. :)

    > I am just objecting to the idea of using a programming language to write deployment descriptors that don't have any programmatic intelligence in them. If you want an analogy, it would be similar to saying "We don't need properties files, I can put these values in my Java sources". It's a step backward in flexibility in my opinion.

    > Especially if you are going to put these values in the same code as the implementation of your aspects (at least, use a different class).

    I think you missed my point. I wasn't saying that you should be writing the code in the same class, I was saying that programming languages are a more flexible, mature, and efficient means of achieving the same end result.

    As an example, pretend that instead of reading a 'standard' properties file, your system reads the source code for a Java class implementing your PropertySource interface. A class loader determines when the source code for the Java class changes and re-compiles the class. Now the properties provider can take advantage of the compiler's static typing system to ensure that his property values are of the correct type and format. He can also easily implement complex properties like Maps. He can also retrieve properties from external resources like the Windows registry. He could perform "property file validation" simply by compiling, without even deploying the new properties file. The Java language is too complex you say? Then create a new DSL called Props, that makes it easy to declare simple properties, but that can escape to full-blown Java when necessary.

    God bless,
    -Toby Reyelts
  19. External data[ Go to top ]

    Well, I think that the problem is, you externalize some properties to make them easy changeable - by other people than developers.
    For example, a repointing to a different database (a property), or switching on security for a different feature (an aspect).
    Either of these should be available to a system admin. Arguably, system admin could change the java class, even w/o knowledge of deep java, DIBE (do it by example).
    On the other hand, I would argue that what you really need here is a good UI tool for configuring whatever you want to be configurable.
    This almost eliminates the discussion of xml or java or database (hey, it's quite an advatage of being able to keep audit track) or whatever. I say almost, because some of storage mechanisms have advantages such as providing a large set of UIish tools not specific to your application.
    Note that I'm talking about _really_ configurable parts of your system. Thing like transaction management tends not to be that configurable, and I think that metadata embeded in the code is the best way.
    Regards,
    Vlad
  20. External data[ Go to top ]

    Well, I think that the problem is, you externalize some properties to make them easy changeable - by other people than developers.

    > For example, a repointing to a different database (a property), or switching on security for a different feature (an aspect).

    That's why I said you could create a DSL, Vlad - With a simple DSL you could support statements of the form:

    name=value # simple prop
    name=[value1,value2] # array
    name.subname={name1=value1,name2=value2} # compound property with map

    Since you're designing the language, it's really up to you. Your language could support escaping out to Java for more complex situations, like:
    \ # begin escape
    Context c = new InitialContext();
    String foo = c.lookup( "myprop" );
    \ # end escape

    God bless,
    -Toby Reyelts
  21. External data[ Go to top ]

    That's true, but then you need to teach your admins your DSL. That's why I advocate GUI tools :). Makes it easy for the users to use. What internal form you put it into - well, that depends on how much time are you able/willing to spend on your configuration tool. Using XML means that you can just go and download (say) XMLSpy for your editing.
    The important part there is "the users". In my experience, developers too often forget that there are other people using their systems than just business users/other developers.
    Regards,
    Vlad
  22. Cedric-,
    with all due respect, I disagree with you and think that Jon Tirsen and
    Toby Reyelts are 100% right. As Jon shared, I also find it difficult to justify
    the use of XML "configurators", including for AOP. And I have tried everything from standard APIs to digester to jelly - it only brings more problems and more fragility to the code.
    In your previous example, I do not think you want to make it possible for the application user to re-configure aspects thru the XML descriptor, not to mention the fact that leaving the user to edit a property file is like: "Sorry, we did not have time to implement decent validating UI interface for configuration, so you learn how to edit properties file and blame yourself if you break the application" ;-)

    I think there a few "urban legends" haunting developers when it comes to
    selecting how to implement extra-lingual/metadata features in their apps:

    1. Java code is expensive to write/debug/maintain compared to a cheap
    and naive language like XML.
    This one shows deep C/C++ roots and vi/emacs habits;-) On top of being much safer language than C/C++, Java has become a lot more agile and *cheap* to alter language with the latest crop of refactoring IDEs. The truth is that IDEs made a huge leap in terms of productivity and smartness over the last couple pf years, while XML is not at all convinient to validate refactor or parse. So, there is nothing wrong in using a powerful language for no-programatic purposes IMHO.

    2. Sun does it across J2EE, so it must be a good practice na d I should not question it!
    Initially, in classic Java Beans and EJB1.0 configurations were made
    in java classes! Sun was afraid that serialized bean descriptors (in EJB 1.x)
    may become incompatible. They imagined a world of a developer, deployer and app server developer all using different versions of JDK and using XML to link
    their responsibilities. Plis, XML was "the next cool think" and had to be used in J2EE. Just look at the reality - while everyone is fighting XML deployment descriptors with tools like XDoclet and EJBgen, there are so many cases where the web server (and the database) is tightly wrapped with the application, never ment to to be re-configured!

    I think Sun is recovering for this mistake - read the Overview part of JSR175
    The fact is that until there is better way to express configuration about the java code, java itself is the better for that, not XML.

    3. Bundling java code in the .JAR file for configuration swells the package
    and takes more memory.
    I do not think XML descriptors eat less of the JAR file, no to mention all
    the extra code ment only to parse/validate the XML configuration file itself. Plus, do not forget that the JVM can "unloads" a class if it is not used for a while.

    Cheers,
    Hristo
  23. <hristo>

    2. Plis, XML was "the next cool think" and had to be used in J2EE. Just look at the reality - while everyone is fighting XML deployment descriptors with tools like XDoclet and EJBgen, there are so many cases where the web server (and the database) is tightly wrapped with the application, never ment to to be re-configured!

    </hristo>

    Trust me, these deployment descriptors are not going back in the Java source any time soon :-)

    However, you are preaching to the choir if you are telling me that the J2EE descriptors are not the best example to use XML, and the reason is that a lot of the metadata described inside these descriptors need to be tied to Java code.

    Not so for the declarative specification of aspects.

    But if you reread my posts above, you will see that I recommend a dual approach: XML and metadata. Note that contrary to the way someone (sorry, forgot who) interpreted what I said, I believe that what is specified in XML and what is specified in metadata should have no intersection.

    <quote>
    I think Sun is recovering for this mistake - read the Overview part of JSR175
    </quote>

    Oh I know JSR 175 pretty well, it's kind of a requirement when you sit on the experts group :-)

    <quote>
    The fact is that until there is better way to express configuration about the java code, java itself is the better for that, not XML.
    </quote>

    I don't like absolute statements :-)

    "Sometimes" XML is better, and "sometimes" metadata is better.

    I believe that if all you need is to specify an ordering of interceptors or a regexp, XML is better suited than Java.

    --
    Cedric
    http://beust.com/weblog
  24. Everyone seem to have made up their mind whether XML is good or not, but I just thought I'd toss in some numbers from our product (a CMS) which is based 100% on AOP using a framework that uses XML descriptors.

    When I say "100%" I mean this:
    All domain objects (50 unique types) are AOP objects, all of which are composed of a number of introductions (60 in total).
    All services (30 on server, 10 on client) are AOP objects.
    The domain objects and services have 57 advice that modify their behaviour. About one third of these are "system" advice (e.g. "store on set-method") and the rest are "application" advice (e.g. "on remove for this type of object, remove aggregated objects as well").

    All of this is bound together by XML descriptors in two versions: one for the server and one for the client (e.g. "store on set-method" on the server is replaced on the client with "store change in object in undo manager"). The two versions share some configuration and have some unique configuration. This is accomplished by placing the shared configuration into XML fragments which are then tied together into the client- and server-profiles by using XML entities. Each major subsystem (e.g. forums) has its own XML fragment that is included in the same way. In total we have 11 XML descriptors(/fragments) which together specify the behaviour of the product as a whole.

    We have found this to be a maintainable system, and it is easy to find information about how a particular object behaves. If a particular "kind" of object needs to have its behaviour changed we have meta-types (e.g. "persistent objects") which allow us to easily apply some advice on all of those objects.

    In the beginning of the product lifecycle we did use Java configuration, mostly in order to be able to refactor the Java classes without worrying about breaking things. When "the dust settled" and the product grew we switched to XML, in part because the Java code became rather hard to overview and maintain, and in part because of our requirements to have two different profiles which shared some configuration and did not share some configuration. I would stress that it's mainly the maintainability factor that makes XML a better choice I think. With a specialized XML format you can express the relationship between all pieces with a very few lines of code, and they are easy to read if you're in a hurry. Also, if XML is used it becomes possible to create a tool that takes the XML and creates HTML documentation that makes it easy to navigate the objects and how they are constructed.

    To me, using Java makes information about how the system works too concealed. If I am given an AOP system and have the task of maintaining it I want the opposite: I want to its guts to be exposed! I want to be able to easily find every little piece that makes it what it is. XML allows me to do that.

    Some people have asked about the ability to make changes in runtime. Personally I don't believe in that model, for consistency and debugging reasons. It's certainly a "cool idea", but other than that I wouldn't use it in any major project for safety reasons. I can't really see a good reason why I'd want to do it either, but maybe I'm too narrow minded.

    These are only my experiences with the two ways to do configuration, and with using XML descriptors in particular. YMMV.

    Some more numbers: the product is currently running in production environments on about 10 sites, one of which is a webhotel with 10 customers on one Linux-server. As I said it's a CMS, and the average rendering time is about 50-150ms with a load of 10 concurrent users (no sleep-time). We have no caching of the HTML output (since the output is extremely dynamic), only on the AOP domain model. The overhead of an AOP call is for us 0.005ms (using the JRockit JVM).
  25. Dynamicity is needed.[ Go to top ]

    Rickard Oberg wrote:
    > Some people have asked about the ability to make changes in runtime. Personally I don't believe in that model, for consistency and debugging reasons. It's certainly a "cool idea", but other than that I wouldn't use it in any major project for safety reasons. I can't really see a good reason why I'd want to do it either, but maybe I'm too narrow minded.
    >


    Rickard, maybe I'm missing what you're saying here, but....

    The lack of no dynamic, runtime interface is one of the few reasons we at JBoss decided to write our own AOP framework and not go with AspectJ. There are a bunch of use cases why dynamic AOP is needed.

    1. Transactional Objects. One of the system-level aspects we're writing for JBoss 4 is the ability to mark a POJO as transactional. What this means is that all POJO state changes become ACID. All state changes are managed by the Transaction manager. Even the following is transactional:

    pojo.getHashMap().put(key, value);

    Yes, even HashMap access is transactional. To allow for this behavior you need to be able to apply aspects dynamically to a given instance, because, for instance, not all HashMaps in your system will be transactional.

    2. Replicated Objects. JB4 is also implementing cluster replicated POJOs. Again, the same reasoning of why you need dynamicity. not all HashMaps are replicated.

    Stack transactional and replicated aspects together and you have a transactional, distributed, replicated Cache for POJOs. Yep, we're doing this for JB4.

    Yet another use case:
    3. Efficient and intuitive HTTP session replication. App servers that implement HTTP session replication either must replicate at the end of every HTTP request, OR define a coding contract between the Web Server and the application developer. By contract, I mean that:

    httpsession.getAttribute("foo").setValue("blah")

    does not cause a replication event and the app developer must do:

    foo = httpsession.getAttribute("foo");
    foo.setValue("blah"):
    httpsession.setAttribute("foo", foo);

    Yet another reason for Dynamic AOP. So you see, dynamic AOP definately has strong viable use cases.

    Regards,

    Bill Burke, Chief Architect, JBoss Group LLC.
  26. Dynamicity is needed.[ Go to top ]

    1. Transactional Objects. One of the system-level aspects we're writing for

    > JBoss 4 is the ability to mark a POJO as transactional. What this means is
    > that all POJO state changes become ACID. All state changes are managed by the
    > Transaction manager. Even the following is transactional:
    >
    > pojo.getHashMap().put(key, value);
    >
    > Yes, even HashMap access is transactional. To allow for this behavior you
    > need to be able to apply aspects dynamically to a given instance, because, for
    > instance, not all HashMaps in your system will be transactional.

    "Cool", but inherently dangerous.

    > 2. Replicated Objects. JB4 is also implementing cluster replicated POJOs.
    > Again, the same reasoning of why you need dynamicity. not all HashMaps are
    > replicated.
    >
    > Stack transactional and replicated aspects together and you have a
    > transactional, distributed, replicated Cache for POJOs. Yep, we're doing this
    > for JB4.

    "Cool", but inherently dangerous.

    > Yet another use case:
    > 3. Efficient and intuitive HTTP session replication. App servers that
    > implement HTTP session replication either must replicate at the end of every
    > HTTP request, OR define a coding contract between the Web Server and the
    > application developer. By contract, I mean that:
    >
    > httpsession.getAttribute("foo").setValue("blah")
    >
    > does not cause a replication event and the app developer must do:
    >
    > foo = httpsession.getAttribute("foo");
    > foo.setValue("blah"):
    > httpsession.setAttribute("foo", foo);

    "Cool", but inherently dangerous.

    (Because the app will break when it's moved to another vendors implementation)

    > Yet another reason for Dynamic AOP. So you see, dynamic AOP definately has
    > strong viable use cases.

    Right. Still, I think I'll stick with my boring deployment time XML descriptors.
  27. Dynamicity is needed.[ Go to top ]

    1. Transactional Objects. One of the system-level aspects we're writing for

    > > JBoss 4 is the ability to mark a POJO as transactional. What this means is
    > > that all POJO state changes become ACID. All state changes are managed by the
    > > Transaction manager. Even the following is transactional:
    > >
    > > pojo.getHashMap().put(key, value);
    > >
    > > Yes, even HashMap access is transactional. To allow for this behavior you
    > > need to be able to apply aspects dynamically to a given instance, because, for
    > > instance, not all HashMaps in your system will be transactional.
    >
    > "Cool", but inherently dangerous.


    That's almost as stupid as saying, "your code will have bugs". Come on, stop the FUD and be specific. We will not think of all scenarios, and any disussion on the "gotchyas" would be quite benefitial.


    > > Yet another use case:
    > > 3. Efficient and intuitive HTTP session replication. App servers that
    > > implement HTTP session replication either must replicate at the end of every
    > > HTTP request, OR define a coding contract between the Web Server and the
    > > application developer. By contract, I mean that:
    > >
    > > httpsession.getAttribute("foo").setValue("blah")
    > >
    > > does not cause a replication event and the app developer must do:
    > >
    > > foo = httpsession.getAttribute("foo");
    > > foo.setValue("blah"):
    > > httpsession.setAttribute("foo", foo);
    >
    > "Cool", but inherently dangerous.
    >
    > (Because the app will break when it's moved to another vendors implementation)
    >

    AFAIK, the J2EE specification does not define this type a contract for clustering and vendors are free to define how an application is clustered. Each vendor will have their own different optimizations and contracts.

    I contend that without this capability that dynamic AOP brings, there is even a greater danger.

    1. If you replicate at the end of every Request, you're clustered app will not scale.

    2. If you optimize and define the get/set contract described above, you are in a greater danger of a developer forgetting this. Since a node failure *should* be a very rare event, unless a project's testing environment is complete, this type of coding bug will not surface

    > > Yet another reason for Dynamic AOP. So you see, dynamic AOP definately has
    > > strong viable use cases.
    >
    > Right. Still, I think I'll stick with my boring deployment time XML descriptors.

    Never send "boring" deployment time XML descriptors were not needed or were not important. They are and I agree with you. The point is that there are diffinately a multitude of use cases for dynamic AOP.


    Bill
  28. clarification[ Go to top ]

    Bill:
    httpsession.getAttribute("foo").setValue("blah")
    does not cause a replication event and the app developer must do:
    foo = httpsession.getAttribute("foo");
    foo.setValue("blah"):
    httpsession.setAttribute("foo", foo);


    Rickard: "Cool", but inherently dangerous. (Because the app will break when it's moved to another vendors implementation)

    Bill: AFAIK, the J2EE specification does not define this type a contract for clustering and vendors are free to define how an application is clustered. Each vendor will have their own different optimizations and contracts.

    IIRC The Servlet specification does state that you must call setAttribute.

    1. If you replicate at the end of every Request, you're clustered app will not scale.

    Full replication certainly does not scale.

    2. If you optimize and define the get/set contract described above, you are in a greater danger of a developer forgetting this.

    That is certainly true. I am not sure that AOP is a good way to solve this; perhaps the spec or the design patterns are poor to start with. Thoughts?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  29. clarification[ Go to top ]

    Bill:

    > httpsession.getAttribute("foo").setValue("blah")
    > does not cause a replication event and the app developer must do:
    > foo = httpsession.getAttribute("foo");
    > foo.setValue("blah"):
    > httpsession.setAttribute("foo", foo);

    >
    > Rickard: "Cool", but inherently dangerous. (Because the app will break when it's moved to another vendors implementation)
    >
    > Bill: AFAIK, the J2EE specification does not define this type a contract for clustering and vendors are free to define how an application is clustered. Each vendor will have their own different optimizations and contracts.
    >
    > IIRC The Servlet specification does state that you must call setAttribute.
    >

    I have the Servlet spec in front of me. Where does it state that

    Foo = (Foo)session.getAttribute("foo");
    foo.setValue(newval);

    is not safe in a clustered ("distributable") environment? I could not find it in the Servlet 2.4 spec.

    How does the session object receive notification that foo has changed state in this instance? Answer: It can't. Please, prove me wrong. Less work for us to do if you do.

    Thanks,

    Bill
  30. clarification[ Go to top ]

    Bill:

    > > httpsession.getAttribute("foo").setValue("blah")
    > > does not cause a replication event and the app developer must do:
    > > foo = httpsession.getAttribute("foo");
    > > foo.setValue("blah"):
    > > httpsession.setAttribute("foo", foo);

    > >
    > > Rickard: "Cool", but inherently dangerous. (Because the app will break when it's moved to another vendors implementation)
    > >
    > > Bill: AFAIK, the J2EE specification does not define this type a contract for clustering and vendors are free to define how an application is clustered. Each vendor will have their own different optimizations and contracts.
    > >
    > > IIRC The Servlet specification does state that you must call setAttribute.
    > >
    >
    > I have the Servlet spec in front of me. Where does it state that
    >
    > Foo = (Foo)session.getAttribute("foo");
    > foo.setValue(newval);
    >
    > is not safe in a clustered ("distributable") environment? I could not find it
    > in the Servlet 2.4 spec.
    >
    > How does the session object receive notification that foo has changed state in
    > this instance? Answer: It can't.

    Therefore, if JBoss allow changes to be propagated without having to call session.setAttribute() apps that utilize this will break when moved to other app-servers since the changes will not work properly in clusters.

    MarcF has stated that the AOP features of JBoss4 will implement J2EE *as a base*, and that developers will be able to augment apps with AOP should they choose to. This case shows that this is not true, since the above encourages writing J2EE apps (without any AOP) that will definitely break on other J2EE implementations.

    You can't have it both ways: either you implement the above, which you feel is enhancing the platform, or you don't implement it and apps developed with JBoss will work on other servers too. Take your pick.
  31. clarification[ Go to top ]

    Therefore, if JBoss allow changes to be propagated without having to call session.setAttribute() apps that utilize this will break when moved to other app-servers since the changes will not work properly in clusters.

    >

    If JB4 can really allow me to easily setup and code replicated HTTPSession cluster, it is a great thing. You must be crazy if you are blaming JBoss for innovation. I asked if we could get replicated cache in JBoss, Bill answers yes.

    I have been in Corba in my past. Let JBoss innovate like they are doing. If JBoss puts their innovations back in JCP, then J2EE will be JBoss. But decrying JBoss innovation because others don't have it is a mentally ill approach.

    Thank god Gallileo sticked his head up otherwise we would still have portable knowledge of a flat earth. Go JBoss.
  32. clarification[ Go to top ]

    Therefore, if JBoss allow changes to be propagated without having to call

    > > session.setAttribute() apps that utilize this will break when moved to other
    > > app-servers since the changes will not work properly in clusters.
    > >
    >
    > If JB4 can really allow me to easily setup and code replicated HTTPSession
    > cluster, it is a great thing. You must be crazy if you are blaming JBoss for
    > innovation. I asked if we could get replicated cache in JBoss, Bill answers
    > yes.

    I'm not blaming them for innovation, I'm asking them to make up their mind. If JBoss4 has transparent replication of session state, "cool", but it's gonna break portability of J2EE apps. That's not an opinion, that's just pointing out a fact, and any amount of wishful thinking isn't going to change that.

    *IF* JBoss wants to implement J2EE then allowing for transparent replication of session state is contrary to that goal. You can't have the cake and eat it.

    > I have been in Corba in my past. Let JBoss innovate like they are doing. If
    > JBoss puts their innovations back in JCP, then J2EE will be JBoss. But
    > decrying JBoss innovation because others don't have it is a mentally ill
    > approach.

    ... and if you had actually read what I wrote you'd know that's not what I said.

    If JBoss wants to innovate like they are doing, then why not be honest about it and say "look, we're going to innovate here and make life simpler for developers. But, apps written this way are not going to be portable to other J2EE servers". Wouldn't that be the right thing to do? I think so. But that's not what they're saying. Here's what Marc said in a CNET interview recently:
    "So you're committed to be compliant to the base specification, but you're adding your own features above and beyond?
    Yes, we call it beyond J2EE...We are putting these features forward without waiting for the specification. As the specification moves forward, we'll standardize but that takes time.

    Is that certification of compliance important before customers are going to buy off on a JBoss to make sure they can port the application?
    Oh, it definitely is. We're not saying we're going to break compliance. In fact, we're known in the market as one the most compliant servers. BEA is fast at bringing out new features, and we're usually second in line. IBM usually trails our own release in terms of spec adherence. So we believe strongly in one unified application server market and yes, we know for some people it's really important to have that brand of certification. "

    (emphasis mine) So, as you can see the stated position is to be fully compliant, in fact, to be one of the most compliant servers. But, this contradicts Bill's statement about how to replicate session state, because that will make apps written to utilize it break when they are moved to another server. Again, this is really not an opinion, just pointing out the facts.
  33. clarification[ Go to top ]

    *IF* JBoss wants to implement J2EE then allowing for transparent replication of session state is contrary to that goal. You can't have the cake and eat it.

    >

    It is the basis for your long winded argumentation and it is false. JBoss is J2EE compliant afaict and I can code http code to it that does 'no replication'.

    Rickard I don't know you personally but from these threads you sound like a has-been. Stop treating yourself like a sacred cow, with these arm-chair quaterback type comments. If you know so much where is the code? when I asked bill he pointed me to JBoss CVS.
  34. clarification[ Go to top ]

    It is the basis for your long winded argumentation and it is false. JBoss is

    > J2EE compliant afaict and I can code http code to it that does 'no replication'.

    Ok, but let's say hypothetically that you might want to do replication, and you're using JBoss4 and have decided to use the "cool features" it will provide (some day) to do transparent replication of session state. What would happen if you, hypothetically, would move that application as-is to another vendors J2EE server? Would the state:
    a) still be replicated
    b) not be replicated

    What do you think? If your answer is b), then does this mean that JBoss4 (hypothetically speaking) is either:
    a) compliant with the J2EE specification
    b) not compliant with the J2EE specification

    What do you think? If your answer is b), then how does that compare with MarcF's statement in a recent CNET interview that (and I quote) "In fact, we're known in the market as one the most compliant servers.". In your opinion, would that statement be compatible with the conclusions from the above questions?

    > Rickard I don't know you personally but from these threads you sound like a
    > has-been. Stop treating yourself like a sacred cow, with these arm-chair
    > quaterback type comments. If you know so much where is the code? when I asked
    > bill he pointed me to JBoss CVS.

    Yes, I know, I am a clueless has-been, and with no CVS to show. I like to talk (preferably at seminars where lots of other clueless people can hear my rants) instead of code, and on occasion maybe write some JavaScript. If you ask me about code I will say "Code? I'm a Software Architect! I do UML".

    Happy now? Would it be possible to perhaps return to the actual topic being discussed? Could you please enlighten this sorry-ass has-been by helping me out with the above queries. That would be absolutely terrific. Thanks in advance.
  35. rickard oberg is crazy[ Go to top ]

    It is the basis for your long winded argumentation and it is false. JBoss is

    > > J2EE compliant afaict and I can code http code to it that does 'no replication'.
    >
    > Ok,

    So we agree.

    You are beating a dead horse, your logic is flawed and this is going crazy.

    The point is that JBoss is J2EE compliant (or will be) and offering native AOP visibility gives more, and doesn't break JBoss J2EE compliance. Why would it? Code to J2EE and you will be J2EE. JBoss AOP doesn't claim to be J2EE in fact if I understand the AOP forum on JBoss, they are building J2EE on top of AOP.

    It opened my old eyes to what they are doing. Reminds of corba.

    <quote>
    using JBoss4 and have decided to use the "cool features" it will provide (some day) to do transparent replication of session state. What would happen if you,
    </quote>

    I checked the JBoss CVS code with my old eyes. It is not "some day" it seems the feature is already in CVS from what I can tell (state modifications). It seems to be there already.

    <quote>
     hypothetically, would move that application as-is to another vendors J2EE server? Would the state:
    > a) still be replicated
    > b) not be replicated
    >
    > What do you think? If your answer is b), then does this mean that JBoss4 (hypothetically speaking) is either:
    > a) compliant with the J2EE specification
    > b) not compliant with the J2EE specification

    answer is 1/b and 2/a. BEA will not replicate automatically (although Cedric is from BEA and seems to follow JBoss AOP so we may) but if you coded manual replication you would work in full J2EE compliance. So JBoss is still compliant. It is a simple logical point.

    > Happy now? Would it be possible to perhaps return to the actual topic being discussed? Could you please enlighten this sorry-ass has-been by helping me out with the above queries. That would be absolutely terrific. Thanks in advance.

    You seem to come from the same mold of JBoss ultra coders and seeing you and bill, 2 of the stars (ex star in your case) of JBoss duke it out is great. As a referee, "we have a winner"... bill in cvs, got there first.

    The rest is loser talk.
  36. rickard oberg is crazy[ Go to top ]

    The point is that JBoss is J2EE compliant (or will be) and offering native AOP

    > visibility gives more, and doesn't break JBoss J2EE compliance. Why would it?

    That's not what we are discussing. Please stick to the topic. To remind you, we're talking about transparent replication of session state. The AOP API is not so important for this discussion.

    > Code to J2EE and you will be J2EE. JBoss AOP doesn't claim to be J2EE in fact
    > if I understand the AOP forum on JBoss, they are building J2EE on top of AOP.

    They're building "J2EE with a twist".

    > I checked the JBoss CVS code with my old eyes. It is not "some day" it seems
    > the feature is already in CVS from what I can tell (state modifications). It
    > seems to be there already.

    According to Bill it's pre-alpha, which is not "here today", but sure I get your point.

    > <quote>
    > hypothetically, would move that application as-is to another vendors J2EE server? Would the state:
    > > a) still be replicated
    > > b) not be replicated
    > >
    > > What do you think? If your answer is b), then does this mean that JBoss4 (hypothetically speaking) is either:
    > > a) compliant with the J2EE specification
    > > b) not compliant with the J2EE specification
    >
    > answer is 1/b and 2/a. BEA will not replicate automatically (although Cedric
    > is from BEA and seems to follow JBoss AOP so we may) but if you coded manual
    > replication you would work in full J2EE compliance. So JBoss is still
    > compliant. It is a simple logical point.

    The (hypothetical) example was that if you used JBoss4 features to enable transparent replication of session state, would your application break if moved to another server (which we seem to agree on), and is this behaviour J2EE compliant. You disagree on this, and I'd recommend that you read my response to Ryan why this is indeed non-compliant behaviour.

    > > Happy now? Would it be possible to perhaps return to the actual topic being discussed? Could you please enlighten this sorry-ass has-been by helping me out with the above queries. That would be absolutely terrific. Thanks in advance.
    >
    > You seem to come from the same mold of JBoss ultra coders and seeing you and
    >bill, 2 of the stars (ex star in your case) of JBoss duke it out is great. As
    >a referee, "we have a winner"... bill in cvs, got there first.

    Yes yes, I thought we had covered this already. I'm an ex-star, I have no public CVS, and I'm basically a loser. Big deal.
  37. All this talk on AOP is quite interesting indeed. At a very high level, I do not think there are any vendors that do not try and lock you into their code base but leveraging features that go beyond the spec. However, I think one major difference is as follows. What is the big deal if you are locked into a FREE implementation in which you have and own the source? If everyone starts coding in this fashion, you then have what is called a standard. What is wrong with a FREE standard? From reading this entire thread, it seems that everyone including people like Grady Booch who is not on this thread, seem to think that AOP is the way of the future. If we have a free implementation that can be easily migrated to from existing J2EE application servers, is there a problem? AOP allows developers, ISV, architects, etc, to do a lot easier what they have been doing since the birth of distributed computing, WRITE behavior that is molded to their specific business. THis is just the nest iteration in distributed computing. If we have a free infrastructure, we all win.
  38. rickard oberg is crazy[ Go to top ]

    The point is that JBoss is J2EE compliant (or will be) and offering native AOP

    > > visibility gives more, and doesn't break JBoss J2EE compliance. Why would it?
    >
    > That's not what we are discussing. Please stick to the topic. To remind you, we're talking about transparent replication of session state. The AOP API is not so important for this discussion.
    >
    > > Code to J2EE and you will be J2EE. JBoss AOP doesn't claim to be J2EE in fact
    > > if I understand the AOP forum on JBoss, they are building J2EE on top of AOP.
    >
    > They're building "J2EE with a twist".
    >
    > > I checked the JBoss CVS code with my old eyes. It is not "some day" it seems
    > > the feature is already in CVS from what I can tell (state modifications). It
    > > seems to be there already.
    >
    > According to Bill it's pre-alpha, which is not "here today", but sure I get your point.
    >
    > > <quote>
    > > hypothetically, would move that application as-is to another vendors J2EE server? Would the state:
    > > > a) still be replicated
    > > > b) not be replicated
    > > >
    > > > What do you think? If your answer is b), then does this mean that JBoss4 (hypothetically speaking) is either:
    > > > a) compliant with the J2EE specification
    > > > b) not compliant with the J2EE specification
    > >
    > > answer is 1/b and 2/a. BEA will not replicate automatically (although Cedric
    > > is from BEA and seems to follow JBoss AOP so we may) but if you coded manual
    > > replication you would work in full J2EE compliance. So JBoss is still
    > > compliant. It is a simple logical point.
    >
    > The (hypothetical) example was that if you used JBoss4 features to enable transparent replication of session state, would your application break if moved to another server (which we seem to agree on), and is this behaviour J2EE compliant. You disagree on this, and I'd recommend that you read my response to Ryan why this is indeed non-compliant behaviour.

    Actually Rickard you are totally wrong here. If you wanted HTTPSession replication and you wanted your code to work on every vendor's HTTPSession implementation with no code changes Session state would have to be replicated at the end of every HTTP request(See my above example for why). This is because the Specification defines absolutely no contract on HTTP Session replication that I can find.

    Unfortunately, replicating HTTP state every HTTP request is just plain NOT scalable. Again, again, because the specification is completely lacking each vendor is required to define their own contract, API, and/or configuration mechanism to provide a real-world scalable HTTP Session replication implementation.

    Well, the real point was that you can use Dynamic AOP to provide seemless, scalable, optimized, HTTP Session replication.

    FYI, by default JBoss HTTP Session replication does replicate at the end of every HTTP request so that we don't break anybody's code and are theoretically portable to other app servers (assuming of course that other vendors themselves provide a "portable" solution). You can optionally optimize it to either

    1. replicate only when a setAttribute has been called
    2. or have snapshotted replication.

    Again, we feel that Dynamic AOP will allow us to have truly optimized HTTP session replication since we can

    1) Know exactly when to replicate
    2) Only replicate the fields/Objects that need to be replicated thus reducing serialization times, and network traffic.

    Dynamic AOP is extemely useful and very applicable to many significant use cases which was the original point of my post. If we didn't feel it was needed we just would have gone with AspectJ.

    Bill
  39. Replication[ Go to top ]

    <quote>
     BEA will not replicate automatically (although Cedric is from BEA and seems to follow JBoss AOP so we may)
    </quote>

    Uh? We've had in-memory replication of Stateful Session bean since WLS7 (I wonder if it's not 6 actually). No need for AOP for that.

    --
    Cedric
    http://beust.com/weblog
  40. clarification[ Go to top ]

    Ok, but let's say hypothetically that you might want to do replication,

    > and you're using JBoss4 and have decided to use the "cool features" it
    > will provide (some day) to do transparent replication of session state.
    > What would happen if you, hypothetically, would move that application
    > as-is to another vendors J2EE server?

    The same thing that would happen if I decide to use the "cool feature" of interceptors in all existing versions of JBoss (which as far as I understand, you created and advocated). It won't work because the interceptors are not part of the J2EE specification.

    Yet the interceptor architecture has proved to be immensely useful and powerful way of implementing functionality that is not necessarily covered by the J2EE spec. And my feeling is that this is what the new version of JBoss aims for as well. J2EE will be supported but the JBoss server can do much more than what is in the specification. If you need to take advantage of the additional features, they're provided for you.

    In my mind your argument could just as well be extended to cover workflow engines or portal products that are provided by different J2EE vendors as add-ons for their server. Relying on those APIs will break your portability but the cost savings you get are worth it.

    /T
  41. clarification[ Go to top ]

    The same thing that would happen if I decide to use the "cool feature" of

    > interceptors in all existing versions of JBoss (which as far as I understand,
    > you created and advocated). It won't work because the interceptors are not
    > part of the J2EE specification.

    Exactly. But, JBoss4 claims to be J2EE compliant as-is. But with this feature it won't be.

    > Yet the interceptor architecture has proved to be immensely useful and
    > powerful way of implementing functionality that is not necessarily covered by
    > the J2EE spec.

    A correct but (for this discussion) irrelevant point.

    > And my feeling is that this is what the new version of JBoss aims for as well.

    I would agree with you on this one.

    > J2EE will be supported but the JBoss server can do much more than what is in
    > the specification.

    Except the API will be "augmented", so it's not really J2EE anymore. You need to differentiate between "adding" and "changing", and this is most definitely a change. Even adding a new method to HttpSession, for example, is a change and not an addition.

    > If you need to take advantage of the additional features, they're provided for
    > you.

    A correct but (for this discussion) irrelevant point.

    > In my mind your argument could just as well be extended to cover workflow
    > engines or portal products that are provided by different J2EE vendors as
    > add-ons for their server. Relying on those APIs will break your portability
    > but the cost savings you get are worth it.

    No, because they're true additions and not changes of standardized API's. If you use them it's going to be pretty obvious that it's not J2EE. This example is about a J2EE API (HttpSession) which has a particular behaviour and semantics for usage. JBoss4, according to Bill Burke, is going to change those semantics.
  42. clarification[ Go to top ]

    "Except the API will be "augmented", so it's not really J2EE anymore."

    Structurally spoken, I'd say the above is not true. Behaviorally, the above is very true:

    Taking the "Systems structure" view, JBoss4 will still be J2EE compliant, as it implements the spec. However, when you start it up and look at how JBoss4 behaves at runtime, it might not be J2EE-compliant anymore, because they chose to implement the session replication interceptor in such a way.

    So I guess, if an application is running in a jboss cluster, they need to choose against the above discussed interceptor and implement a different replication mechanism.

    In the end, it comes down to the app developer to decide whether they want their app to be J2EE compliant or not. The app server itself IS J2EE compliant, however by offering AOP/interceptors opens up a dangerous and very tempting door to make applications that are not J2EE apps but JBoss4 apps.
  43. clarification[ Go to top ]

    Can anyone imagine a scenario where you wouldn't want the state replicated after making a change, ie

    pojo = (POJO)request.getAttribute("pojo");
    pojo.setBar(bar);

    //forget to call request.setAttribute("pojo", pojo);

    In this case I think the J2EE spec is very limiting. The above should work, but it does not. Why? you might ask. The writers of the spec didn't know how easily this could be implemented using aspects, so we are stuck with a requirement that is dumb. But I guess if you want to be compliant you better remember to call setAttribute.

    tx

    Matt
  44. JB4 == java ++[ Go to top ]

    In this case I think the J2EE spec is very limiting. The above should work, but it does not. Why? you might ask. The writers of the spec didn't know how easily this could be implemented using aspects, so we are stuck with a requirement that is dumb.


    If i read your post right you are saying that the spec did not take into account the capacity of the java language enhanced with AOP as in JBoss. The logical implication is that

    JB4 == java ++

    and that they should be leading the specs... they are beyond the spec committees because they are using a new language? let the losers lose, you kids keep on going. Go Bill, Go JBoss.
  45. clarification[ Go to top ]

    Matt: In this case I think the J2EE spec is very limiting. The above should work, but it does not. Why? you might ask. The writers of the spec didn't know how easily this could be implemented using aspects, so we are stuck with a requirement that is dumb.

    Your description of aspects used for HttpSession support is not dissimilar to having the HttpSession attributes represent an object-oriented database with transitive closure.

    I think your enthusiasm is great, and wish more people had it, but the specs are built on the current (or even previous) Java language and libraries, so aspects are not actually that "simple". Once the language + libraries extend to incorporate these aspects (no pun intended) then your suggestion will be spot on.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  46. tangosol is dead[ Go to top ]

    wait...

    I just realized that JB4 AOP Cache makes tangosol look like pricey legacy?

    Cameron, what is your take on it? spot on or you are not afraid of the JBoss?
  47. Brian: I just realized that JB4 AOP Cache makes tangosol look like pricey legacy? Cameron, what is your take on it? spot on or you are not afraid of the JBoss?

    Fear isn't one of my strong points ;-). If this type of feature becomes more accepted, I hardly see how it hurts our own market acceptability. Besides, if we sit around doing nothing to innovate and an open source project ends up eventually incorporating everything that we do, then we deserve to lose business, right? I think it just proves the old adage, "You're either growing or dying." I choose to grow.

    As for pricey, you can check out our published pricing and make your own decision. We have published our Coherence prices since day one, and we have never charged for Coherence development licenses. Companies deploying app server clusters find our pricing to be more than reasonable for the reliable and extensive features that we provide, but there are certainly going to be some projects for which we are too expensive. I think that is unfortunate, because I'd like everyone doing clustering to be able to take advantage of our software, so we do try to be flexible and make exceptions for the few customers that can't afford the list pricing.

    Regarding our HTTP Session replication module, it's a free module that we provide to customers with our free development license. If you're interested in looking at it, just drop an email to sales at tangosol dot com and ask for a free dev license. We're probably going to donate the code to JSR 107 (JCache), since this functionality is going to be in the JCache reference implementation.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  48. clarification[ Go to top ]

    should have read

    pojo = (POJO)session.getAttribute("pojo");
    pojo.setBar(bar);

    //forget to call session.setAttribute("pojo", pojo);

    <brian thomas>If i read your post right you are saying that the spec did not take into account the capacity of the java language enhanced with AOP as in JBoss. The logical implication is that</brian thomas>

    correct, and i guess it couldn't have

    <Cameron>I think your enthusiasm is great, and wish more people had it,</Cameron>

    Thanks



    tx

    Matt
  49. Rickard,

    I am not sure I understand your point here. But just to make sure, here is what I have gathered so far...

    - JB4 transparently intercepts modifications to session objects and notifies the cluster of these changes.
    - If you depend on this behavior (not having to call setAttribute after the modification), then you will lose this notification feature if you move to another app server.
    - You contend that this is dangerous.
    - You also argue that Fleury's statement that "In fact, we're known in the market as one the most compliant servers" may be inaccurate because of this (and perhaps some other similar issues?)

    Why? If JB4 complies with the spec, can't they add other (non-spec) features and still be 100% compliant. Isn't the onus of the developer to take caution when using app server specific features, with JB *or any other* server. Isn't that the whole point of these differentiating features? So that server vendors can say "Port your app to us and all spec-defined actions will work, *plus* you can have some cool non-standard features." The only difference with this "session object interception" feature is that no new code is required - it just happends automagically.

    If you ask me, you *can* have your cake and eat it, too. (BTW - what the hell does what mean. If I had my pick, I was always choose to eat the cake. Don't really care if I *have* the cake).

    Just some thoughts from the sidelines.

    Ryan
  50. - JB4 transparently intercepts modifications to session objects and notifies the cluster of these changes.

    > - If you depend on this behavior (not having to call setAttribute after the modification), then you will lose this notification feature if you move to another app server.
    > - You contend that this is dangerous.
    > - You also argue that Fleury's statement that "In fact, we're known in the market as one the most compliant servers" may be inaccurate because of this (and perhaps some other similar issues?)

    Correct.

    > Why? If JB4 complies with the spec, can't they add other (non-spec) features
    > and still be 100% compliant.

    This isn't an addition. This is a change in the semantics of how the API works. It is changed from "it is necessary to call session.setAttribute after each change to session state" to "it is only necessary to register state with session.setAttribute once. After that all state that is referenced by the registered state will be transparently replicated".

    >Isn't the onus of the developer to take caution when using app server specific
    >features, with JB *or any other* server.

    You can have that position, sure. I think it's rather unhelpful attitude towards application developers, but it's certainly a valid position.

    >Isn't that the whole point of these differentiating features? So that server
    >vendors can say "Port your app to us and all spec-defined actions will work,
    >*plus* you can have some cool non-standard features." The only difference with
    >this "session object interception" feature is that no new code is required - it
    > just happends automagically.

    In other words, applications developed for JBoss4 that uses session state in a cluster will not work on any other server. If you have the position as above, i.e. "if a developer uses JBoss4 and shoots himself in his/her foot we cannot be blamed", then it's a valid position. I'd contend that it's a rather contemptous position, but it's still possible, I guess.

    > Just some thoughts from the sidelines.

    Thanks, and I'm glad you presented them. Keep 'em coming.
  51. Attriubtes....[ Go to top ]

    Hi,

    Just to switch gears a little bit... I'd be interested to hear some opinions on the mixture of using meta data, ala JSR 175 and aspects. I'm prototyping some scenarios using attribute/metadata based on a homegrown implementation, attrib4j.sf.net.

    For example, my original motivation for the project was that I thought it would be "cool" to reproduce nunit, nunit.org, in Java. Other JSRs such as 181 are planning to make use of the new java metadata facilities, which by its very nature of being a "spec" will tend to flavor other peoples approaches to these issues.

    Another example, transactions. In JBoss 4, there is an AOP like way of specifying this, and then in .NET there is a more attribute/meta-data manner of specifying how methods participate in transactions.

    - Mark Pollack
  52. clarification[ Go to top ]

    Hi Bill,

    Bill: I have the Servlet spec in front of me. Where does it state that
      Foo = (Foo)session.getAttribute("foo");
      foo.setValue(newval);
    is not safe in a clustered ("distributable") environment? I could not find it in the Servlet 2.4 spec. ... Please, prove me wrong.


    I gain nothing by proving you wrong ... that goal appears nowhere on my TODO list ;-). I know that I've read that you have to call setAttribute, but you may be right that it is not in the spec itself; perhaps I read it in a vendor's materials and transmogrified that memory into being part of the spec.

    One thing that did worry me about 2.4 was this section:

    Distributed Environments
    Within an application marked as distributable, all requests that are part of a session must be handled by one virtual machine at a time. The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately.

    I appears that, because of the limitations of various container implementations, or limitations of the committee's architectural imagination, that session stickiness and migration are now mandated as the implementation of distributed environments. Instead of defining behavioral requirements, they mandated a particular implementation; this type of "enhancement" seems counter-productive.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  53. Let's code[ Go to top ]

    I am growing warry of the JBoss talks, for or against. While it is great that Bill is here talking I would much rather see him give us JB4. JBoss 4.0 seems to really leave everyone behind and could very well shift the application market through sheer innovation. Is JBoss 4.0 really delivering on all the AOP features? if so we are done here.

    IS the code in CVS? if so where?
  54. Let's code[ Go to top ]

    I am growing warry of the JBoss talks, for or against. While it is great that Bill is here talking I would much rather see him give us JB4. JBoss 4.0 seems to really leave everyone behind and could very well shift the application market through sheer innovation. Is JBoss 4.0 really delivering on all the AOP features? if so we are done here.

    >
    > IS the code in CVS? if so where?

    "Shut up and code". I like it :) I'm off, but here's some info.

    cvs checkout jboss-head
    jboss-head/aop/... FRAMEWORK + remoting aspect
    jboss-head/varia/src/main/org/jboss/aop/... System-level aspects
    jboss-head/cluster/src/main/org/jboss/aop/... invocation failover and loadbalancing
    jboss-head/testsuite/src/main/org/jboss/test/aop/... testing of framework and aspects
    jboss/head/testsuite/src/resources/aop/META-INF/jboss-aop.xml XML descriptor for tests.

    Old initial somewhat out-of-date documentation:
    http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop

    That page has link to development forum too.

    Please note that this framework and system-level aspects have not even had an alpha release. I intend to stop functionality development around May 5th. After that date, you should see the framework and aspects stabilize and documentation expanded for our Developer's Release by end of May.

    Bill
  55. <Cedric>It would be similar to saying "We don't need properties files, I can put these values in my Java sources". It's a step backward in flexibility in my opinion.</Cedric>

    I think you are missing everyone else's point. Why put what can be expressed more clearly (and with fewer bytes) in a properties file into an XML file? The only pro-XML arguements are that you can programmatically validate and change the XML. But you can much quicker write a much more expressive and precise validator as a java. You could even create a generic properties validator class to extend (or pass parameters to via an XML file) with common validation points such as string length, currency, enumerations, etc.

    The primary purpose of XML validation is to make sure all your brackets and ampersands are in the right place, and the main complexity comes from not having a clearly defined document format.
  56. <quote>
    I am just objecting to the idea of using a programming language to write deployment descriptors that don't have any programmatic intelligence in them.
    </quote>

    Um, yes, and then again, no. I've been trying (in my non-existant spare time) to write a JDO Reference Enhancer using AspectJ. An (annoying) problem is that I need to dynamically generate my Aspects.

    But... I hate xml deployment files. I hate them because I know them. I'm a J2EE programmer, so I'm used to having deployment files out the wazoo and the issue involved with that. Basically, the only time you should ever permit xml deployment files is when your IDE is up to saying, for a given method "This method is marked as FOO in the deployment .xml file". Because otherwise you're hiding knowledge elsewhere which should be in the face of whoever is reading the code.

    Sean
  57. I'm getting into this a bit late, but let me offer a thought experiment for thinking about whether AOP in Java should use XML to specify the binding from advice bodies (the imperative code) to join points.

    Before the thought experiment, let me say that I think this is an issue on which reasonable people can disagree. The main factors as I see it are ease of integration with IDE tools and supporting static typing. Along with static typing comes good runtime performance and compile-time error checking of course.

    Here's the thought experiment.

      Objects don't exist yet. Pretend its 1963/1970/1983/1990.
      You are adding OOP to Algol/an_all_new_language/C/an_all_new_language.

      But, XML already exists.

      Is it better to add the OO functionality as a programming
      language construct, or to use XML to describe the OO part,
      and keep using procedural programming to code the bodies
      of the methods.

    In other words, should I write something like:

    class Point {
      int x, y;
      int getX() { return x; }
      ...
    }

    or something like

    int Point_getX(*this) { return this[0]; }
    ...

    and

    <class>
      <name>Point</name>
      <field><type><name>int</name>..
      ...

    (excuse me for not being able to rip out proper XML)

    I think this thought experiment is serious. I have always though that the advice construct in AspectJ was like a method declaration in OOP, except that the condition of applicability was crosscutting rather than just a specific message to a specific object.

    And I think some good arguments can be made for doing it either way.

    But I think we have to acknowledge that in the OOP space, doing it as an extension to the language won out. I think that's because it made the description of the behavior appear "right there" in the code, and so it made it easier for tool integration to work properly. And of course it enables static typing. I don't know how we would have gotten proper static typing with an XML based version of OOP.
  58. I think this thought experiment is serious. I have always though that the advice

    > construct in AspectJ was like a method declaration in OOP, except that the
    > condition of applicability was crosscutting rather than just a specific message
    > to a specific object.

    What do you do when you want to apply the advice in many ways? For example, we have a case where the same classes get different advice depending on if the object is on the client or server. How would you propose to handle that if you declare how advice are applied in Java code?
  59. <rickard>
    What do you do when you want to apply the advice in many ways? For example, we have a case where the same classes get different advice depending on if the object is on the client or server. How would you propose to handle that if you declare how advice are applied in Java code?
    </rickard>

    There are several constructs for doing this in Java-code: if-statements, abstract classes with different implementations (where the pointcut is declared abstract and the advice is concrete, the pointcut is then specialized concretely differently in two baseclasses), factories, abstract template method, strategy pattern. And so on.

    (The sample of the coming Aspect/J book published here on TSS recently actually demonstrates exactly this kind of "abstract" aspect. It's very elegant, you'll enjoy it.)

    This is the main reason for using Java (or Java-extensions a la Aspect/J). All these different patterns that have been accustomed to doing in Java can be reused and we can simply add new ones to our toolbox of patterns and idioms without having to reinventing new ones. With a new language designed on XML we're stuck to whatever the author of the framework decides is appropriate to put into the XML language, if we want something else we'll have to beg him or write a plugin (again, probably, in Java).
  60. <jon>
    This is the main reason for using Java (or Java-extensions a la Aspect/J).
    </jon>

    The main reason for using Java would be for static typing, but I don't believe the example you give is a good one because you are now coupling the Java class that defines the aspects with the Java classes that implement them. In other words, they need to be known at compile time and be in the classpath at runtime.

    What if the said classes are proxies generated on the fly, or something similar?

    What if they are classloaded at runtime?

    What if they are not available when the client is compiled? (server not up yet)

    You need late binding for all these cases, and in these cases, a definition in XML makes more sense than in Java.

    --
    Cedric
    http://beust.com/weblog
  61. <jon>

    > This is the main reason for using Java (or Java-extensions a la Aspect/J).
    > </jon>
    >
    > The main reason for using Java would be for static typing, but I don't believe the example you give is a good one because you are now coupling the Java class that defines the aspects with the Java classes that implement them. In other words, they need to be known at compile time and be in the classpath at runtime.

    That's definitely one reason more. IMHO it's not the main reason, because static typing is just one more "idiom" that's part of the standard toolbox that doesn't need to be reinvented when using Java for AOP. XML is reinventing the wheel.

    > What if the said classes are proxies generated on the fly, or something similar?

    That's exactly how Nanning works. And I uses Java-classes for defining aspects. No problems with it so far.

    > What if they are classloaded at runtime?

    That's how my classes are loaded in Nanning. Actually all classes are loaded at runtime in Java (not that I need to remind you of that). No problems with it so far.

    > What if they are not available when the client is compiled? (server not up yet)

    Well, that's why you're gonna be working against interfaces and plugging in the implementation at runtime. Standard stuff in Java, do it every day. No problems with it so far.

    > You need late binding for all these cases, and in these cases, a definition in XML makes more sense than in Java.

    Yep, you need late binding. Luckily Java is a great language for late binding! You compile against the interfaces and load the implementations at runtime. You'll get both runtime type-checking and pluggable implementations. Don't you just love Java?
  62. Jon has already made many of the points I would have. Let me try to add another idea in the way of thinking about this.

    I think there are several properties of these different designs that are getting lumped together in some of these messages. They include (at least):

      - What is the syntax for specifying the binding from join points
        to advice code? Extension to Java, as in AspectJ's advice and
        pointcut syntax? Or XML?

      - What is the SEMANTICS of weave time? In particular, how dynamic
        is it? Compile-time? Pre-load time (e.g. configure time)? Load
        time? Run time? The AspectJ language is fairly neutral on this
        issue. The early implementations restricted it to compile time,
        the current implementation is a late as load time. The interceptor
        approach is like runtime. XML deployment descriptions is somewhere
        between configure and load time as near as I can tell.

      - What is the ACTUAL weave time? This is different from the above
        in some interesting ways. In particular, as long as actual time
        is >= semantics time, its easy to get good runtime performance.
        If actual time is earlier than semantics time you have to leave
        some runtime dispatch code behind.

      - Is there static typing? In particular, can I be sure that advice
        bodies won't ever have to cast, and won't ever get runtime type
        errors?

      - Is there abstraction and reusability of aspect code? Is there
        separate compilation of aspect code?

    I think some of the mail that's gone by has assumed that XML vs. Java
    extension syntax inherently takes a stand on some of these other issues.
    I don't think that's the case at all. I think with either XML or Java
    syntax you can have significant latitude on most of the other issues.
    You can, as Jon pointed out, have abstract reusable aspects, aspects
    that get tailored to different platforms... in AspectJ. Reading the
    AspectJ examples shows that.

    What I'm not sure of is whether you can get the kind of static typing,
    fast runtime, and fast loading behavior AspectJ supports in the XML
    approach. I can't even really get myself past the issue of static
    typing.

    And I'm also not sure how well you could get the kind of debugger /
    browser integration we are seeing in the XML approach.

    Those kinds of questions are the reason for my initial thought experiment.
    If you take away language syntax for OOP, and try to do it in XML, then
    what changes. I'm not sure the answer. But I am sure the above are mostly
    orthogonal.
  63. put it in xml and it's ++[ Go to top ]

    <cedric>
    The point is that if you define the deployment descriptors of your aspects in Java, you need to recompile before you can redeploy them, which quickly becomes unacceptable.
    </cedric>

    This is simply not true. I've worked with J2EE since it's inception (and earlier, since EJB 1.0), not a single time have I used the "modify deployment descriptor without recompile". I think this concept is entirely broken. You're always using a build-process to put all pieces together, so a recompile makes no difference.

    The only other thing that speaks for XML based deployment descriptors is the coupling between the components and it's container. With a Java (procedural/object-oriented) type of configuration API instead of an XML based (declarative) there will be not just structural couplings but also temporal. This can of course be handled if you're aware of it.

    The new refactoring IDEs for Java, runtime attributes and AOP will in the future make XML based deployment descriptors completely obselete.
  64. put it in xml and it's ++[ Go to top ]

    This:
    > This is simply not true.

    is not implied from this:
    > I've worked with J2EE since it's inception (and earlier, since EJB 1.0), not a
    > single time have I used the "modify deployment descriptor without recompile".

    For example, I have redeployed J2EE apps many times without recompiling, so the above is "simply not true".

    And this:
    > I think this concept is entirely broken. You're always using a build-process
    > to put all pieces together, so a recompile makes no difference.

    is also "simply not true". We have LOTS of classes in our app and it takes the compiler (invoked through Ant) quite some time even if no classes have changed.

    > The only other thing that speaks for XML based deployment descriptors is the
    > coupling between the components and it's container.
    I've listed a number of reasons in a prior post why XML is a good choice.

    >With a Java (procedural/object-oriented) type of configuration API instead of
    >an XML based (declarative) there will be not just structural couplings but also
    > temporal. This can of course be handled if you're aware of it.

    What is a "temporal coupling", and why is it used?

    > The new refactoring IDEs for Java, runtime attributes and AOP will in the
    > future make XML based deployment descriptors completely obselete.

    I don't think so, for previously mentioned reasons. Oh well, time will tell.
  65. What is a "temporal coupling", and why is it used?


    A coupling between components where the protocol is sensitive to the ordering of communications. This obviously only shows up in a procedural language such as Java and never in a declarative language such as most XML based deployment descriptors. A declarative language has no notion of "order".

    For example, when using the Jetty API you first need to create and add a web application to the server before you can add a servlet. This introduces a temporal coupling between our system and the Jetty API. In a web.xml you never have this problem. This makes a Java API a bit more difficult to use.

    So this is my point, a declarative language is easier to use in certain situations and if we move all deployment descriptors into Java code they can't be declarative any more. (Except runtime attributes of course, as they are declarative in nature.)

    There are other advantages of having everything in Java code, but I've already mentioned them.

    > > The new refactoring IDEs for Java, runtime attributes and AOP will in the
    > > future make XML based deployment descriptors completely obselete.
    >
    > I don't think so, for previously mentioned reasons. Oh well, time will tell.

    Yes, I agree. Time will tell.
  66. Descriptor requires recompile[ Go to top ]

    <Jon>
    I've worked with J2EE since it's inception (and earlier, since EJB 1.0), not a single time have I used the "modify deployment descriptor without recompile". I think this concept is entirely broken. You're always using a build-process to put all pieces together, so a recompile makes no difference
    </Jon>

    I think the concept that changes to deployment descriptors require a "recompile" comes from the initial approach to ejb development where you cobbled the compile process (compiling .java files) with the formatting process (sticking the class files into a jar and running ejbc). This is compounded as people have used ant scripts to "build" ear's were they assemble the ear as they compile.

    WebLogic 8.1 has a prescribed dev time scheme (your ear in exploded format combined with the generated output's [classfiles]) where making changes to a descriptor only requires a redeploy, and never a recompile.

    Cheers
    mbg
  67. put it in xml and it's ++[ Go to top ]

    "interpreting" an XML file is the exact same thing as "compiling" java. Only it is slower and more cpu and memory intensive. It would be better to include a scripting engine like beanshell, than to lug around the whole of Xerces.
  68. put it in xml and it's ++[ Go to top ]

    I've yet to see an example where XML is more expressive than Java.

    >
    > But I guess this is an entirely different blog-debate. :-)

    heh, well, once it's turing complete the debate was had about 50 years ago. here are some languages written in xml that are as expressive as java:

    xexpr
    jelly
    bml

    and probably lots more. that said, none of them have the IDE support that java enjoys.
  69. I've yet to see an example where XML is more expressive than Java.

    > >
    > heh, well, once it's turing complete the debate was had about 50 years ago.
    > here are some languages written in xml that are as expressive as java:

    The expressiveness of a language has little to do with it's "turing completeness".
  70. Use appropriate tools for the job[ Go to top ]

    * XML is markup - use it to express and communicate data, don't program with it (look at the mess that is XSLT if you don't believe this)

    * Java is general purpose - program with it, but don't script or communicate with it

    * Python/Ruby/etc.. - script or program with it, but don't communicate with it

    * Aspects are a form of programming, not markup - so put them in the language, not XML
  71. Use appropriate tools for the job[ Go to top ]

    <tom>
     * XML is markup - use it to express and communicate data, don't program with it (look at the mess that is XSLT if you don't believe this)

    * Java is general purpose - program with it, but don't script or communicate with it

    * Python/Ruby/etc.. - script or program with it, but don't communicate with it

    * Aspects are a form of programming, not markup - so put them in the language, not XML
    </tom>

    Ah, I was with you until that last point, but I think we can reconcile our opinions :-)

    Aspects are made of two very different pieces: their implementation and their deployment information (pointcuts).

    The former should undoubtedly be written in a programming language.

    The latter belongs to a declarative language.

    --
    Cedric
    http://beust.com/weblog
  72. I think Aspectj does distinguish Caller from Callee,and doesn't need any odering of Advices:
    We can define an aspect to cache and count all method call:
    import java.util.HashMap;
    aspect CachingPi {
    private static HashMap m_cache = new HashMap();
    static int Pi.getPiDecimalCalled;
    pointcut computePiDecimal(int n) : call(int Pi.getPiDecimal(int)) && args(n) ;

    int around(int n) :computePiDecimal( n) {
    Pi.getPiDecimalCalled++;
    Integer result = (Integer)m_cache.get(new Integer(n));
    if (null == result) {
                 result = new Integer(proceed(n));
                 m_cache.put(new Integer(n), result);
             } else {
                 //System.out.println(" Cache: " + n + "rd decimal:" + result);
             }
    return result.intValue();
    }
    }
    and define another aspect to count method execution:
    aspect ExecutePiComputing {
    pointcut executePiDecimal() : execution(int Pi.getPiDecimal(int)) ;
    static int Pi.getPiDecimalExecuted;
    before() : executePiDecimal() {
    Pi.getPiDecimalExecuted++;
    }

    }
    and another aspect :
    aspect CacheMiss {

    pointcut computePiDecimal() : call(int Pi.getPiDecimal(int)) ;

    after() :computePiDecimal() {
    System.out.println("total called:"+Pi.getPiDecimalCalled+" executed:"+Pi.getPiDecimalExecuted);
    }
    }
    now we can change cache inplementation and don't need change ExecutePiComputing and CachingMiss .
  73. Just print something "automatically" when I run main method in Test.
    It should be a static method.
  74. AspectJ makes my head hurt[ Go to top ]

    The AspectJ example just points out to me how much clearer the XML syntax for declaring and applying aspects is. Build your aspects in Java. Apply them with XML. Java is NOT good with metadata (yet) whereas XML is all about metadata.
    Someone metnioned "where's the IDE which can refactor your XML config files?"... Well, where's the IDE that can refactor the mess that AspectJ makes of a class when you start putting that stuff in? I know they're starting to put it into Eclipse, but I use IDEA, and it's XML support is probably better than the AspectJ support in Eclipse, and only getting better...
    I think it's important to realize that AspectJ has been around for a while now, but AOP never really started getting any buzz until recently. Why is open to interpretation, but my take (from my point of view, having looked at AspectJ a while back and deciding not to look further) is that AspectJ always came off as an interesting idea, but done in much too academic a way to be practical. It wasn't until Rickard starting talking about AOP done in a pragmatic, usable way, that AOP started getting the attention it has now.
  75. This clearly shows that Aspect/J is the most mature of all AOP implementations. If you're prepared to dig into a new language (so far) unsupported by your refactoring IDE and other tools I'd recommmend Aspect/J any day.

    Nanning does not aspire to be an Aspect/J and will never implement all those things (byte-code modification, extensive pointcut-model). It's a simple application of JDK1.3 dynamic proxies to enable some primitive use of AOP, today, now, directly in Java.
  76. The AOP Caching Challenge[ Go to top ]

    I think the discussion of AspectWerkz vs Nanning vs AspectJ/HyperJ is somewhat too generic and premature because of a lack of any real use of AOP in enterprise applications (at least today). It is impossible to really judge which approach is better looking at "Hello, World" type of example as opposed to real life system development.

    One of the issues that I am observing with AOP approach is that it introduces tight coupling between aspect definitions and OO code (like Java), which is a serious disadvantage of AOP in my opinion. In some cases it may be dangerous to have totally unrelated to each other java classes sharing same logic by a virtue of some aspect that cross-cuts into all of them. It is especially true when an advice mutates a state of a target object.

    AOP definitely has its place in life, but it still has to be tamed and massaged until it can be seriously used.

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
  77. The AOP Caching Challenge[ Go to top ]

    Hmm..
    There are two (well, more or less) ways of using aspects.
    One is entirely non-intrusive (in sense of affecting the original code). A well written logging aspect won't change the behaviour of your class at all. Your class won't be even aware that something is there. It might have new members/methods, but they are unknown to the original.
    You don't get less tight coupling.
    The other is where aspect implements some business functionality. This of course introduces some coupling. On the other hand, without aspects you would still implement it as either part of the class (repeating the functionality in various classes), or another class. The level of coupling will not increase at all.
    Of course, if someone misuses a feature, does wrong design etc., all bets are off. But then, this is true of any language and development strategy.
    Regards,
    Vlad
  78. Tight coupling with AOP[ Go to top ]

    I agree that for read-only aspects with proper use of AOP tight coupling may not be a serious issue. However, aspects that implement business logic and/or change state of target object may indeed have potential damaging side effects due to tight coupling.

    Suppose developer created a new PersistenceManager class responsible for database updates. All of a sudden this class begins to send some JMS messages to another system just because it was implicitly point-cut by some existing aspect based on a method name pattern. Now the PersistceManager presumably continues to function, but the behavior of the system that receives JMS messages is likely broken. Problems like that may be extremely difficult to spot during testing stage and may not even become evident right away in production. I think this case can hardly be qualified as a misuse.

    On the other hand, this problem would not exist in a standard OOP approach since all the methods are called explicitly.

    Best regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
  79. Nostalgia[ Go to top ]

    <quote>
    On the other hand, this problem would not exist in a standard OOP approach since all the methods are called explicitly.
    </quote>

    Ten years ago, people used to say that C was more readable than object-oriented languages because in C, all the methods are called explicitly, whereas with all this polymorphic magic of object-oriented languages, you never know...

    --
    Cedric
    http://beust.com/weblog
  80. Nostalgia[ Go to top ]

    "Ten years ago, people used to say that C was more readable than object-oriented languages because in C, all the methods are called explicitly, whereas with all this polymorphic magic of object-oriented languages, you never know... "

    That is a very good point and regarding readability/maintainability, AOP probably has the same potential over OOP.

    The problem about AOP - like Cedric has pointed out well in his blog - is that a developer of an aspect pretty much wants to be oblivious about the code, the aspect gets finally woven into (the coupling issue). This is very hard to do, especially for intrusive aspects, that modify the state of the target object. But even for the non-intrusive, read-only, obliviousness in designing the aspect has effects on the runtime. Imagine "read-only" advices for e.g.<BR>
    - Caching<BR>
    - Logging<BR>
    that are being crosscut around a method getStockQuote(String id) in the above order.<P>

    Let's say getStockQuote() looksup stock information using a webservice (which is the only webservice out there:). If my code makes a call to getStockQuote(), first the CachingAdvice is being invoked. If there is a cache miss, the Advice will call proceed() on the JoinPoint, so that logging gets invoked. However, if there is a cache hit, proceed() will not be called and any Advices that were being declared for getStockQuote will not be executed from hereon after. (Btw, I can easily solve this by turning the order of the advices in my deployment descriptor around - so I like this not being hardcoded)

    It is kind of a weird example, but I hope it illustrates, that when developing Aspects/Advices, it is very hard to do this in an oblivious way. But by having a configuration file for the deployment descriptor, there is at least some sort of flexibility to further "orchestrate" the aspects in the right order.
  81. Nostalgia[ Go to top ]

    <cedric>
    Ten years ago, people used to say that C was more readable than object-oriented languages because in C, all the methods are called explicitly, whereas with all this polymorphic magic of object-oriented languages, you never know...
    </cedric>

    This is rather fragile comparison…

    Author should not take a long time to look back to see that in retrospect polymorphism was one of the most dangerous and highly misused feature or characteristic of OOP. Thousands and thousand of convoluted, “giant on the straw legs” designs are clear testaments to that (Smalltalk people seem still not being able to grasp this “aspect”…)

    So, there was actually certain amount of truth to the initial quote in this post.

    But coming back to the question raised by Dimitry, I think it is a valid one among many other similar issues. We all see value in AOP (and in Fitech we are working extensively in this area) but we differ on what part AOP would play in day-to-day development in the couple of years from now when AOP will be more widespread and accepted.

    Good luck!
    Niktia Ivanov.
    Fitech Labs, Inc.
  82. Tight coupling with AOP[ Go to top ]

    Cedric said it all, but still :).
    I'd say that yout example actually is a misuse. That is, someone just went and wrote that all methods called "doSomething" must send a JMS message, when sending of the message is a context sensitive operation.
    It seems to me that you don't really see the tight coupling as a problem, but the (possible) lack of visibility of the tight coupling.
    In a case of context sensitive aspect, I would argue that creating a PC relying on naming pattern - especially wide naming pattern - is a design error, because it relies on naming convention. Unless this is a part of language (or can be strictly enforced in some other way), I think that any design relying on naming conventions is dangerous, as there is almost always someone who will break them without noticing it. And no, I don't like Java bean properties, ejbLoad etc.
    Some solutions I'd see there:
    The method must be an implementation of a specific class/interface. This defines the semantic of the method, and separating the aspect is separating the specific functionality in the same way as you would do it in standard OO way (something like:
    public abstract class ... {
      public void foo() {
        // do somethind
        bar();
        // do something else
      }
      protected void abstract bar();
    })
    With interfaces, you don't have the explicit call, but you know that X happens when this method is called. The same way as with any methods on an entity bean you know that ejbLoad/ejbStore are going to be called.
    Metadata (directly in source code, .NET-like). Probably most flexible way, if you can pull it off (in Java, now).
    Regards,
    Vlad
  83. AOP in use[ Go to top ]

    This is a great discussion. I'm glad TSS is providing a public forum for this.

    Dmitriy Setrakyan wrote:
    > I think the discussion of AspectWerkz vs Nanning vs AspectJ/HyperJ is somewhat too generic and premature because of a lack of any real use of AOP in enterprise applications (at least today). It is impossible to really judge which approach is better looking at "Hello, World" type of example as opposed to real life system development.
    >

    Advises have been used in enterprise applications for years. JBoss and Iona's Orbix2000 use interceptors extensively to apply a range of system-level aspects(thanks Vinoski and Rickard).






    > One of the issues that I am observing with AOP approach is that it introduces tight coupling between aspect definitions and OO code (like Java), which is a serious disadvantage of AOP in my opinion. In some cases it may be dangerous to have totally unrelated to each other java classes sharing same logic by a virtue of some aspect that cross-cuts into all of them. It is especially true when an advice mutates a state of a target object.
    >
    > AOP definitely has its place in life, but it still has to be tamed and massaged until it can be seriously used.
    >
    > Regards,
    > Dmitriy Setrakyan
    > Fitech Labs, Inc.
  84. Re: AOP in use[ Go to top ]

    Dmitriy Setrakyan wrote:

    > > I think the discussion of AspectWerkz vs Nanning vs AspectJ/HyperJ is somewhat too generic and premature because of a lack of any real use of AOP in enterprise applications (at least today). It is impossible to really judge which approach is better looking at "Hello, World" type of example as opposed to real life system development.
    > >
    >
    > Advises have been used in enterprise applications for years. JBoss and Iona's
    > Orbix2000 use interceptors extensively to apply a range of system-level
    > aspects(thanks Vinoski and Rickard).

    I think you misunderstood Dimitriy's statement. First of all, JBoss has never been an AOP programming environment. It's not possible for programmers to write aspects and apply them to objects or services using JBoss. What JBoss *has* done, in the EJB implementation, is to implement a thick specification which lists a *number of cross-cutting concerns*, and how they should behave and interact. That is not AOP however. That is "just" EJB implemented using OOP with interceptors.

    The real problem, which I think Dimitriy is really referring to, is what happens when *application programmers* write *aspects* (both advice and introductions) and apply them to the objects and services. Specifically, what happens with the interaction between the aspects, and how should issues with coupling be dealt with. This is to a large extent also a core concern of the initial "AOP challenge" that Cedric formulated, and which his comments in the thread have highlighted.

    These are fairly new issues, and have not been dealt with in enterprise programming (as far as I know), and especially not in JBoss (which relies on the EJB specification to resolve any such issues), ever.

    I find it a little silly that I have to rebut your claims about what JBoss did in 2000. I would appreciate if you did not make such claims, because they simply aren't true.
  85. Re: AOP in use[ Go to top ]

    Dmitriy Setrakyan wrote:

    > > > I think the discussion of AspectWerkz vs Nanning vs AspectJ/HyperJ is somewhat too generic and premature because of a lack of any real use of AOP in enterprise applications (at least today). It is impossible to really judge which approach is better looking at "Hello, World" type of example as opposed to real life system development.
    > > >
    > >
    > > Advises have been used in enterprise applications for years. JBoss and Iona's
    > > Orbix2000 use interceptors extensively to apply a range of system-level
    > > aspects(thanks Vinoski and Rickard).
    >
    > I think you misunderstood Dimitriy's statement. First of all, JBoss has never been an AOP programming environment. It's not possible for programmers to write aspects and apply them to objects or services using JBoss. What JBoss *has* done, in the EJB implementation, is to implement a thick specification which lists a *number of cross-cutting concerns*, and how they should behave and interact. That is not AOP however. That is "just" EJB implemented using OOP with interceptors.

    Please don't lecture me on the innerworkings of JBoss. You haven't been around for years. Again, I said JBoss and Iona's ART support Advices, not full AOP. JBoss 3.x allow's you to define "advices" both client and server side for EJBs via XML. JBoss and Iona's ART are EXAMPLES of production quality software using the AOP concept of Advices. Its the application of the patterns that matter here. AspectJ, JBoss, Nanning, etc, are just a more generalized packaging of these well known and well used patterns.

    Yet another example is EJB for instance. It is a hardcoded contract for applying a finite set of system-level aspects to an object. Again, the patterns are being used everywhere, people just need to be educated

    >
    > The real problem, which I think Dimitriy is really referring to, is what happens when *application programmers* write *aspects* (both advice and introductions) and apply them to the objects and services. Specifically, what happens with the interaction between the aspects, and how should issues with coupling be dealt with. This is to a large extent also a core concern of the initial "AOP challenge" that Cedric formulated, and which his comments in the thread have highlighted.
    >

    Again, I state that *application programmers* have been writing advices for JBoss for years. One of our software partners has written both client-side and server side EJB interceptors(advices) to do funky distributed caching both on the client and server side.

    Many JBoss Group customers are writing EJB advices to define their own security models or their own monitoring engines.

    > These are fairly new issues, and have not been dealt with in enterprise programming (as far as I know), and especially not in JBoss (which relies on the EJB specification to resolve any such issues), ever.
    >
    > I find it a little silly that I have to rebut your claims about what JBoss did in 2000. I would appreciate if you did not make such claims, because they simply aren't true.

    Please, please. Don't get pure on me. Interceptors ~ Advises. JBoss has pluggable interceptors, both on client and server for EJB. *Application programmers* have been taking advantage of them. Advices may only be 50% of AOP as you say, but without them you really can't generically apply cross-cutting concerns on existing APIs.

    I find it silly that you pretend to understand the full capabilities of JBoss or how people are using JBoss considering you haven't really been a contributor or involved with the community in years.

    Bill
  86. Re: AOP in use[ Go to top ]

    Ok, we had this shootout before.
  87. AOP in use[ Go to top ]

    <burke>
    Advises have been used in enterprise applications for years. JBoss and Iona's Orbix2000 use interceptors extensively to apply a range of system-level aspects(thanks Vinoski and Rickard).
    </burke>

    I hope we can agree that interceptors have little to do with full-fledged AOP application – the issues clearly referred by Dmitry in his question. Applying the same stretched logic we can say that AOP was used since 1979 (A. Fouxman, "Technological Aspects of Program Systems Development." Finances and Statistics Publishing Co., 1979); this work, by the way, introduced cross-cutting concerns into system programming. Or, we can also "argue" that callbacks are also simple form of AOP...

    Thanks to Rickard for clarifying this question as well. Also, his post describes one of the few real applications of full AOP for the system of any serious size to be good enough for a "statistical sampling".

    As far as topic in hand, I would side with Nanning approach (i.e. XML-based descriptors). For many good reasons, I don’t believe that in the end AOP will significantly change the way we do system development but will rather add a useful technique to address specific problems. And for that, programming frameworks (JSR 175, CLR attributes) would do better long term than a new language or byte code augmentation.

    Regards,
    Nikita Ivanov.
    Fitech Labs, Inc.
  88. AOP in use[ Go to top ]

    <nikita>As far as topic in hand, I would side with Nanning approach (i.e. XML-based descriptors). </nikita>

    Nanning does not use XML based descriptors, it uses Java for configuration.

    tx


    Matt
  89. AOP in use[ Go to top ]

    http://nanning.snipsnap.org/space/xml+based+configuration
    http://www.theserverside.com//home/thread.jsp?thread_id=18878&article_count=50#80124

    I was not referring to a new experimental configuration subsystem...

    Nikita Ivanov,
    Fitech Labs, Inc.
  90. AOP in use[ Go to top ]

    Nanning is Tirsen's project not Oberg's. Doesn't matter anyway. You like xml, so do I. Nanning
  91. JBoss AOP Caching[ Go to top ]

    FYI:

    http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop

    We took the challenge a bit further....

    Regards,

    Bill
  92. JBoss AOP Caching[ Go to top ]

    Does anyone think that it would make sense to specify metadata in some XML format rather than Javadoc?