1 Reply Latest reply on Jul 23, 2004 11:52 AM by ryan.campbell

    Problems building JavaDocs in 3.2.5

    Sean Garagan Newbie

      Good day,

      I am trying to build the JavaDocs for the JBoss source and I keep hitting the same problem. The error I get is:

      C:\tmp\JBoss\jboss-3.2.5-src\build>build docs
      Calling ..\tools\bin\ant.bat docs
      Buildfile: build.xml

      Trying to override old definition of task property



      [echo] groups: default
      [echo] modules: common,jmx,system,j2ee,naming,remoting,jmx-remoting,transac







      [mkdir] Created dir: C:\tmp\JBoss\jboss-3.2.5-src\build${build.api}

      C:\tmp\JBoss\jboss-3.2.5-src\tools\etc\buildmagic\buildmagic.ent:662: C:\tmp\JBoss\jboss-3.2.5-src\build${source.java} not found.

      Total time: 2 seconds

      Any suggestions around properties I need to set up?


        • 1. Re: key properties of AOP in Java

          > > The pointcut language is compositional. This
          > means
          > > that you
          > > can take pointcuts and compose them to form other
          > > pointcuts.
          > > This means that you can build up crosscutting
          > > structure in
          > > a similar manner to what we know about building up
          > > procedural
          > > structure or class structure.
          > Be precise makes little sense as is. Right now we
          > have precise requirements for JBoss System that we
          > must able to say 'on this method/field/constructor'
          > please apply this set of interceptors. We can do
          > dynamically.

          Composition is more useful at the app developer level for "application aspects" although it definitely would be useful at the system level as well -- even though the specified sets at system level are predefined and therefore easily handled by other means.

          > One of the things that would be nice is a more
          > evolved language that enables us to provide multiple
          > pointcuts in one sentence such as
          > "apply these interceptors to methods having to do
          > with CRUD operations" a "where get/set create/delete,
          > intercept" kind of thing. Can you give me use cases
          > of evolved languages?.

          This is composition. First you have a definition of a set of methods/fields 'A' and for example two defined sets of interceptors; one stack 'M' of CMP persistence interceptors another stack 'N' for Tx/Locking.

          You compose these definitions into a component contract 'X' by joining them to apply to a specific set of methods where you want the persistence and transaction/locking construct enforced. Essentially you define 'X' to say "if my objects contain signatures A I want to apply M+N". From that point on you can advice your POJO to fulfill contract X directly.

          This is a point about giving more expressive power to the developer.

          > hmmmmm, in the case of system AOP ala JBoss I am not
          > sure I see a use for the named abstractions. I can
          > say the above where the pointcut is a
          > method/field/constructor/interface method but where
          > do I need a more evolved language?

          Have a look at the current standardjboss.xml file. About thousand or so lines of configuration that basically just repeats itself. And this is to cover just a few basic cases of fulfilling the EJB service contract. This is where composition (via inheritance) even at system level would be helpful although of more limited use compared to application level.

          It might be that XML schema is enough -- although I have my doubts relying too much on the XML garbage files. Failure at component level already, who wants it at the object level?

          Anyhow, composition at the application level would serve the developer quite well as we're unable to provide the defaults at that point.

          > I don't see why 'type safety' brings you for AOP
          > combination of behavior.

          It is clear that the type safety requirements absolutely must be relaxed for "system aspects". The framework has no way of knowing at compile time the types of the components (since we want to do away with any kind of mandatory component contract). At system level giving up the type safety might not be that much of an issue anyway -- yes it may be painful for a while until all the wrinkles get ironed out but we can assume that eventually "we'll get it right". This code will be shared across so many different services that bugs related to non-typed invocations should surface fairly quickly.

          Again, different picture at the app level. A simple case (so simple it might already have been adressed). I don't want to track down through all my interceptor stack definitions just because I decided to change a method name on my POJO and whatever configuration existed for that method does not apply anymore because of signature mismatch (btw, composition plays a large role in how much 'tracking' I would have to do).

          On the other hand, we gave up partially on type safety with EJB component contract already (so even at app level) when the interfaces were separated from the implementation. And seeing that custom compilers would be difficult to get accepted and rather top heavy approach it may be that we need to rely on a similar 'verifier/xdoclet/etc' preprocessor strategy we used with EJBs.

          > Some interceptors come typed, meaning they expose an
          > interface for simplicity's sake and for end users
          > (think standard mbeans). Dynamically composing that
          > signature as a sum of the signature is what Dynamic
          > Proxies used to do and what JBossAOP does today with
          > Chiba's bytecode chirurgical kit.

          This is fine if the intended advices, introductions and metadata can all be determined from the naming conventions of a statically typed interface. But it seems unlikely. So you still end up with part of the contract located outside the Java language (assuming no language extensions, JSR175) which naturally loses any type safety from the programmers point of view.

          Of course, the same problem exists for EJBs as well (part of why the price of writing an EJB component contract is so high). There still doesn't seem to be a good solution for this (although XDoclet manages to relieve the nastiest symptoms) and I doubt there will be anything outside extending the language itself (via JSR175 or otherwise).

          > I am worried about the "need for a language".

          Need for language is always about adding abstraction and more expressiveness to the application developer (and less places to fuck it all up). Everything can be equally expressed with a "lower" level language. Turing complete. No point in arguing that.