Seam 1.0 beta 2 released

Discussions

News: Seam 1.0 beta 2 released

  1. Seam 1.0 beta 2 released (40 messages)

    Seam 1.0 beta 2, a framework based on EJB 3.0 and JSF, has been released. New updates include workspace management (with automatic breadcrumb generation, if using the Seam conversational model), business process modeling with jBPM integration, and reverse generation capability from the Hibernate Tools project.

    The announcement has examples of page flow generation with jBPM as well.

    Threaded Messages (40)

  2. XML vs @annotations[ Go to top ]

    Seam seams an annotations oriented framework, but in the example of integration with jBPM, a beatiful XML code is shown.

    What about the idea of a XML pure SEAM version. Using simple POJOs + XML, as in the case of original hibernate?

    Javier Paniza
    OpenXava: XML for easier J2EE
  3. Seam use of annotations is evil[ Go to top ]

    I concur. The example of using annotations for declaring bean names, access to private instance variables (in a SLSB), and most horribly, interceptors(!) is anti-reuse, anti-separation of concerns, and basically anti-OO.

    Annotations should not be macros to generate code in classes where it has no purpose being. Leave your application assembly to external entities.
  4. Seam and Use of annotations[ Go to top ]

    I use Seam and find the annotation method very developer friendly, it allows me to have a single place to look for all development issues.

    Annotations versus xml configuration is outside the scope of this post (it is about Seam and its functionality - of which it has a LOT!).
  5. Seam and Use of annotations[ Go to top ]

    James,

    As I didn't specify the nature of the external configuration mechanism, let's indeed leave XML for another time. My point was not to say annotations were bad. As you note, they are useful and developer-friendly, but I disagree with the use of them for application configuration as I saw in the Seam example.

    @In and @Out; if they generate accessors and mutators, ok. I think its counterintuitive, but to each his own. What if some properties need massaging of the input/output, though? You write a real mutator? Then you can end up combining two styles of code in a class - to me, a bad thing.

    @Name - A class should not know about what an external entity, be it component or application, calls it. Different applications can use a User class for different things, yet it will probably get real confusing just calling them all "user".

    @Interceptor - How can this be reused within different applications using different interceptors? A class should not have embedded within it knowledge of the objects responsible for pre- or post-processing it.

    To me, examples like these show a propensity to push too much application knowledge into the classes. That said, I have a team investigating Seam, and I'm sure they will respond to my concerns.
  6. Seam and Use of annotations[ Go to top ]

    The use of @In and @Out is pretty clever. The key to understanding it is to realize to think of your code in terms of components. Components have state, and some of that state will be things that are shared in various contexts (conversation, session, business process, etc...) or made available directly to the view.

    Seam allows for a more dynamic form of injection than the stateless injection models currently out there. It doesn't just inject state when the object is created, it dynamically keeps the state current - both injected and outjected values. To use one of the Seam examples, if you need the current shopping cart component, you just declare dependency to it. You don't have to care where it is or call out to some context get it. Your components just worry about their own state and Seam weaves everything together. It's simple and powerful.

    What happens when you need to transform the values? Just declare it. Look at the @DataModel tags for an example. We've got a long way to go to make this generic enough where you can easily plug in your own transformations, but that's something I hope we can make a priority for a future release.

    @Name? I love it. I don't think of it as "I demand everyone call me Widget" as much as me as the programmer saying "This is a widget". It's very simple. You won't have naming conflicts between applications, and inside of a single application this is very manageable. Should we allow you to set a component name in an XML file? Arguably, but we haven't really addressed the issues of XML overrides when you want to make your application complicated. We're dealing with making things simple. And this is as simple as it gets.

    @Interceoptors - this is standard EJB3. In Seam we use it to add Seam functionality to EJB3 components in a container-independent way. You can also add your own interceptors. When combined with your own annotations, this is very powerful.

    In general, you say "an object shouldn't know this" whereas I say "You shouldn't have to configure this externally". It's nice to have that power so that you can configure eternally in those rare, rare cases where you truly need it. But, I'm feeling like any system that forces you to default to external configuration is too complex. Annotations make your code simple and easy to understand.
  7. Seam and Use of annotations[ Go to top ]

    As you note, they are useful and developer-friendly, but I disagree with the use of them for application configuration as I saw in the Seam example.

    None of the uses of annotations in Seam are for configuration information. They are all examples of plain declarative programming, none carries information that can change between different deployments of the system.

    @In and @Out; if they generate accessors and mutators, ok. I think its counterintuitive, but to each his own. What if some properties need massaging of the input/output, though? You write a real mutator? Then you can end up combining two styles of code in a class - to me, a bad thing.

    @In and @Out are used to allow a component to access a contextual variable. This is nothing to do with configuration.

    You can use either:

    @In @Out Foo foo;

    or

    @In void setFoo(Foo foo) { .... }
    @Out Foo getFoo() { .... }

    Depending upon your taste.

    Note that Seam's bijection functionality is done in exactly the same way as EJB3's dependency injection: annotation of an instance variable or accessor method. Nothing especially new here.

    You may think it is "counterintuitive" the first time you see it, but I bet 99% of developers found dependency injection a bit counter to intuition the first time they saw it. Then they got used to it and found it intuitive. This is the nature of new ideas ;-)

    (Note that none of this discussion will make sense until you have completely grokked the notion of a "contextual variable". A contextual variable is to a context what an instance variable is to an instance, or a local variable is to a stack frame, or a global variable is to a process.)

    @Name - A class should not know about what an external entity, be it component or application, calls it.


    Why not?

    Different applications can use a User class for different things, yet it will probably get real confusing just calling them all "user".

    Why would that be confusing!?

    Lets use what we know about instance variables to decide if this is the case. Instance variables are shared between many methods (just like contextual variables are shared between many contextual components). And all methods refer to instance variable by the same name. So by analogy, it is natural that all components would use the same name to refer to a contextual variable.

    And, in fact, Seam provides a level of indirection here that goes beyond what we have in instance variables. I can do:

    @In("user") User currentUser;

    Which allows many components to alias the same contextual variable to differently-named instance variables.

    In fact, this is exactly what we do if we don't have contextual variables. If I am putting state in my HttpSession, I have a key, "user" which is shared by all components, and I do:

    User currentUser = (User) session.get("user").

    I am not aware that this is generally understood to be "real confusing".

    @Interceptor - How can this be reused within different applications using different interceptors?

    EJB3 lets you declare interceptors in XML. When I wrote the Seam examples, JBoss EJB3 did not yet support this, so I used @Interceptors. In practice, I will use XML. This is actually mentioned in the Seam documentation as the better approach!

    Note that @Interceptors is *not* a Seam annotation, it is javax.ejb.
  8. Anti-OO?[ Go to top ]

    So encapsulation is anti-OO now?
  9. XML vs @annotations[ Go to top ]

    What about the idea of a XML pure SEAM version. Using simple POJOs + XML, as in the case of original hibernate?

    >> I concur. The example of using annotations for declaring bean names, access to private instance variables (in a SLSB), and most horribly, interceptors(!) is anti-reuse, anti-separation of concerns, and basically anti-OO.

    I don't want to steal Seam's thunder here, this thread should probably be primarilly for people to find out about Seam, but since the above topic came up, people interested in it should keep an eye out for Spring Web Flow 1.0 RC1, which should be out by about mid-next week at the latest. This release would actually have been out already, but Keith Donald, the primary force behind SWF, had another 'software release', a new baby girl, this last Wed, which took priority :-)

    Spring Web Flow has been maturing in various milestone releases for something like 10 months now. It has no dependency of any sort on annotations, works in JDK 1.3+, allows flows to be defined in XML or Java, and unlike Seam is view layer agnostic, working on top of Spring MVC, Struts, Portlets and JSF at this time, with more to come (Tapestry being a prime candidate). Its development has been driven by real-life needs, and in fact we know of one site using a PR5 release from last July, serving 30 million hits plus per day.

    On the whole question of annotations, we've done some experimentation with optional annotation support where it may makes sense (for some people/applications) and some of that will probably get added in. The key word here is optional.

    The wiki here is quite out of date in a few areas but should give people at least an idea of what SWF encompasses:
        http://opensource2.atlassian.com/confluence/spring/display/WEBFLOW/Home

    I encourage people reading the above to also take a look at the actual 1.0-RC1 release when it is out, as it includes more up-to-date, comprehensive documentation at the same high quality level of the normal Spring documentation. Nightly builds are available at the link below, although the docs are unfortunately left out of those snapshots, they should be in either tonight or tomorrow night.
      http://www.springframework.org/webflow-snapshots

    Regards,
    Colin

    ---
    Colin Sampaleanu
    Interface21 Principal Consultant
    Spring Training, Consulting and Support - "From the Source"
    http://www.springframework.com
  10. XML vs @annotations[ Go to top ]

    Come on, Colin. Do we need at least one Spring guy commenting on every Seam news? I think not. IMHO that is just bad business conduct. I hope that this time no Seam guy freaks out about this (as usual - which probably also does more harm than good). What would you say if every time car manufacturer A makes advertisements with big posters some guerilla group of car manufacturer B comes and sprays "Don't buy A, buy B, it is much cooler" on the advertisements of manufacturer A? Well, I would know which manufacturer to prefer.

    BTW: BusinessWeek and German heise today carried news about Oracle trying to acquire JBoss, Zend and Sleepycat. That would have been nice news for TSS.

    See here
    http://www.businessweek.com/technology/content/feb2006/tc20060209_810527.htm
    http://www.heise.de/newsticker/meldung/69434
  11. XML vs @annotations[ Go to top ]

    Come on, Colin. Do we need at least one Spring guy commenting on every Seam news? I think not. IMHO that is just bad business conduct. I hope that this time no Seam guy freaks out about this (as usual - which probably also does more harm than good). What would you say if every time car manufacturer A makes advertisements with big posters some guerilla group of car manufacturer B comes and sprays "Don't buy A, buy B, it is much cooler" on the advertisements of manufacturer A? Well, I would know which manufacturer to prefer.

    Michael,

    Actually, I thought long and hard about that reply and whether I should even post it. This is not an ad for Seam we're talking about here though, though, it's a thread that Joseph Ottinger started pointing to the new release, where you have two posters directly asking about doing XML based flows without any annotations. So my post, which I even prefixed with a disclaimer saying I'm not trying to take attention away from Seam, seems pretty relevant. I would hope those two posters at least, and probably a few other people interested in this whole topic, will find it so.

    I _was not_ trying to start a general Seam/SWF comparison here. The scopes of the two products are not even quite the same, so an apple to apple comparison is probably not even relevant, but people do need to know where to go to do their own research.

    I'll stay out of any subsequent discussion here if at all possible, unless there are direct questions to me. If anybody found my post inappropriate, I apologize.

    Regards,
    Colin
  12. XML vs @annotations[ Go to top ]

    I _was not_ trying to start a general Seam/SWF comparison here. The scopes of the two products are not even quite the same, so an apple to apple comparison is probably not even relevant, but people do need to know where to go to do their own research.

    Colin, that is the kind of factual conversation level I like. Actually what I said was more or less to prevent the start of yet another ugly Spring vs. Seam discussion. Something I personally am fed up with. Of course the JBoss folks aren't angels themselves (I know that, and I hate it just as much as the next guy: sometimes too rude for my taste, jboss issue...). Maybe I am just a late hippie.
  13. XML vs @annotations[ Go to top ]

    Come on, Colin. Do we need at least one Spring guy commenting on every Seam news? I think not. IMHO that is just bad business conduct.

    To be fair to Colin, threads about Jonas or Geronimo usually get their fair share of posts from JBoss affiliated folks who preach the advantages of JBoss technologies.

    It's fine, it just means us readers get exposure to more of what is going on in the community. As long as it is relevant then I say 'post it up'. Works both ways though :)
  14. XML vs @annotations[ Go to top ]

    I agree. It seems you can't swing a dead cat around here without someone from JBoss posting about their product. Nothing inherently wrong with that, but as you said, it goes both ways.

    Seam sounds interesting, Spring Web Flow sounds interesting, they're both brought up here with relevant merits, all done politely so far, and that's the way it should be on a site like this.
  15. XML vs @annotations[ Go to top ]

    Come on, Colin. Do we need at least one Spring guy commenting on every Seam news? I think not. IMHO that is just bad business conduct. I hope that this time no Seam guy freaks out about this (as usual - which probably also does more harm than good). What would you say if every time car manufacturer A makes advertisements with big posters some guerilla group of car manufacturer B comes and sprays "Don't buy A, buy B, it is much cooler" on the advertisements of manufacturer A? Well, I would know which manufacturer to prefer.BTW: BusinessWeek and German heise today carried news about Oracle trying to acquire JBoss, Zend and Sleepycat. That would have been nice news for TSS. See here http://www.businessweek.com/technology/content/feb2006/tc20060209_810527.htm

    http://www.heise.de/newsticker/meldung/69434
    Where were you when the JBoss guys comment on the Spring stuff?
  16. XML vs @annotations[ Go to top ]

    Come on, Colin. Do we need at least one Spring guy commenting on every Seam news? I think not. IMHO that is just bad business conduct. I hope that this time no Seam guy freaks out about this (as usual - which probably also does more harm than good). What would you say if every time car manufacturer A makes advertisements with big posters some guerilla group of car manufacturer B comes and sprays "Don't buy A, buy B, it is much cooler" on the advertisements of manufacturer A? Well, I would know which manufacturer to prefer.BTW: BusinessWeek and German heise today carried news about Oracle trying to acquire JBoss, Zend and Sleepycat. That would have been nice news for TSS. See here http://www.businessweek.com/technology/content/feb2006/tc20060209_810527.htm

    http://www.heise.de/newsticker/meldung/69434
    Since when is competing technology not relevant.

    +1 Colin.
    -1 You.

    I find Seam very intriguing. After using EJB-style annotations with Hibernate, I went back to using XML on my next problem (with Hibernate). I don't like the imports and how annotation tie my objects to another framework. It is the opposite of "light weight".

    However, I would not rule out a frame simply b/c it relied on an annotation only option. I prefer XML (at least until they fix annotations).
  17. XML vs @annotations[ Go to top ]

    After using EJB-style annotations with Hibernate, I went back to using XML on my next problem (with Hibernate). I don't like the imports and how annotation tie my objects to another framework. It is the opposite of "light weight".However, I would not rule out a frame simply b/c it relied on an annotation only option. I prefer XML (at least until they fix annotations).

    I'm going to disregard my own comments and express my feelings on annotations. The key point with annotations is that it doesn't force or modify the object's implicit intentions. You aren't extending, you aren't adding setters or getters to break encapsulation.
  18. XML vs @annotations[ Go to top ]

    What (exactly please) is wrong with annotations?
    Why do you feel that XML which is name and type unsafe is better than java annotations?

    About annotation dependency. You can develop your own set of annotations (similar to Spring) and than apply Aspects (aspectj support it) which will hook you annotations to different frameworks. With this combination you can develop your own business specific annotations which will be translated to Seam specific annotation via aspectj. I'm still missing java AST in APT tool. Then we (as framework developers) will have very strong toolbox. APT + ANNOTATIONS + ASPECTS = compile time software reconfiguration.
  19. Well, the real and basic reason is that JBoss being for sale is - as far as I can tell - a rumour. Officially, JBoss' stance is "No comment," which doesn't mean it's not for sale, of course, but they insist that there's only rumour right now - and given that the original source was Sys-Con, I'm not sure it's credible... yet.

    When it happens, TSS will let you know. Until then, we would prefer to avoid baseless rumour.
  20. XML vs @annotations[ Go to top ]

    Why do the spring maggots always have to hijack threads
    and post their nonsense. This thread is about Seam. Why
    on earth would I want to know about the immature spring web
    elephant.
  21. XML vs @annotations[ Go to top ]

    Why do the spring maggots always have to hijack threadsand post their nonsense. This thread is about Seam. Why on earth would I want to know about the immature spring webelephant.

    I think I speak for everyone else when I say that this is exactly the kind of thing we can do without. I guess there are Seam maggots as well, but I don't think that the rather intelligent people who came up with Seam would necessarily want to be associated with them.
  22. XML vs @annotations[ Go to top ]

    Why do the spring maggots always have to hijack threadsand post their nonsense. This thread is about Seam. Why on earth would I want to know about the immature spring webelephant.

    Very mature and helpful. With advocates such as you, Seam will go far!
  23. XML vs @annotations[ Go to top ]

    Oh come on now. I want to read about Seam
    on this thread, not some post advocting
    spring or anything associated with it.
    This thread has already provided me with
    Seam comments and knowledge. My statement
    is geared towards people attempting to
    defend spring in every possible relevant
    thread, which just shows the decline in its
    usage. I have stated this before, so if you
    wish to continue mentioned the spring elephant
    then feel free.
  24. XML vs @annotations[ Go to top ]

    ..With advocates such as you, Seam will go far!

    Assumptions assumptions ... please prove that I am
    a seam advocate? You can spread al the FUD you like.
    Now shut up and let people with seam experience
    post.
  25. XML vs @annotations[ Go to top ]

    ..With advocates such as you, Seam will go far!
    Assumptions assumptions ... please prove that I ama seam advocate? You can spread al the FUD you like.Now shut up and let people with seam experiencepost.

    Strong words, maggot man. And such strong technical content...that come out of a certification book?
  26. XML vs @annotations[ Go to top ]

    Raymond, please go to your room and let the adults talk.
    Everything you've posted on here is always negative comments about other systems.
  27. Why we have to stand XML everywhere?[ Go to top ]

    Who said XML is Object Oriented?
    Who said XML is a key to code reuse?
    Who said XML ease application's maintenance?
    Who said XML is the right place to write business logic?
    Isn't Java a better choice?
    Isn't Java logical and faster?
    Isn't Java easier to write, test and maintain?

    Why XML everywhere and for everything?

    Why to use a "human-readable" format to format data to be read by a computer?. I have not met anyone who spend all his/her day writing or reading XML.

    Is it because many people think XML is cool?
  28. Seam 1.0 beta 2 released[ Go to top ]

    Why does everyone compare Seam to Spring? In working with Seam, it's a whole different way of looking at IoC that is founded on contextual importance-- it's not a configuration file. Trying to argue Annotations vs. XML is a crap shoot at best.
  29. Oracle[ Go to top ]

    This is off topic, but if Oracle buys JBoss, and it because a big pos it's time to let Java die.
  30. Oracle[ Go to top ]

    This is off topic, but if Oracle buys JBoss, and it because a big pos it's time to let Java die.

    Why? Are we going to start another thread about why open source projects are better, etc... than profitable company sponsored projects? I just don't get it. There is Open Source software that's great, and there is commercial software that great as well.

    Another point is that although JBoss is open source, it's always been controlled by a corporation, so it wouldn't be any different is Oracle owned them.

    Ilya
  31. Annotations are great[ Go to top ]

    I hope that people who haven't yet started using annotations won't be too prejudiced to try them out. As a former XDoclet user, I was both very aware of the value of inline metadata and very wary of the idea of moving to a typed Java-centric type of metadata from the loser approach from XDoclet. I remained skeptical until I actually started using them. When you write code with annotations you will like it. I can't even imagine going back and working without them.

    It is still nice to be able to come back and override your annotation values externally as EJB3 allows. In cases where you actually have real re-use you might want to shift more of your configuration to XML. But you shouldn't have to be saddled with the burden of external XML configuration when you don't need it.

    Annotations keep the common cases easy and don't get in the way of the less common things. Annotations are definitely the way to go. Give it a try and you won't go back to XML micro-management.
  32. Annotations are great[ Go to top ]

    I hope that people who haven't yet started using annotations won't be too prejudiced to try them out. As a former XDoclet user, I was both very aware of the value of inline metadata and very wary of the idea of moving to a typed Java-centric type of metadata from the loser approach from XDoclet. I remained skeptical until I actually started using them. When you write code with annotations you will like it. I can't even imagine going back and working without them. It is still nice to be able to come back and override your annotation values externally as EJB3 allows. In cases where you actually have real re-use you might want to shift more of your configuration to XML. But you shouldn't have to be saddled with the burden of external XML configuration when you don't need it. Annotations keep the common cases easy and don't get in the way of the less common things. Annotations are definitely the way to go. Give it a try and you won't go back to XML micro-management.

    I agree with you but one extreme over another is not good. I think the problem is people confuse declarative programming and configuration information. For instance, the datasource to be used by an application is definitely a configuration element and should be put in an external xml configuration file.

    But the kind of annotations you see in Seam (note I don't have a big knowledge of it) seems alright to me because you can't change this information without changing the component code. Just like with EJB, you couldn't change it from being stateless instead of stateful without rewriting some code. Since it is closely related to the code, why put it in xml. Afterall, it is just declarative programming in my opinion.
  33. Annotations are great[ Go to top ]

    Yes, external files are good for configuration and application resources (images,strings). Metadata is not a configuration and it is not a resource, it is related to declaration (class or method/field). If metadata is not polutted with configuration stuff and resources then annotations are great (metadata stored in XML can be polluted in the same way).
  34. Annotations vs External Configuration[ Go to top ]

    The argument being made that it is okay to utilize annotations within a class to describe things such as database mapping and lifecycle scope because they are not configuration but rather metadata is soft at best.

    I agree that this type of information is not configuration and that it is metadata. However, it is contextual metadata meaning that it is relevant within a particular usage of the class but NOT EVERY usage of the class. If you are in a situation where there will be only one usage of the class okay maybe annotations will save you some time. These types of annotations are not appropriate if it is necessary to utilize a class in more than one context, which in my experience is usually the case for classes that represent core domain concepts in an enterprise system.

    Placing metadata related to persistence or ui lifecycle scope into a domain class simply results in mashing together many concerns that could and should be separated.

    A banking application has an Account class, instances of this class may be utilized in one manner within a web application, and in a completely different manner within a service layer, and in a completely different manner within a thick client. The concept of conversation scope being included in a class as an annotation ... each and every new use of that class within a different workflow will require a new annotation to that class ... these things have no relevance on the business logic implemented in the class.

    It is a matter of trade-offs ... both approaches should be supported ... annotations for quick and dirty ... externalization and separation of concerns for flexibility, extensibility, and maintainability.

    The current push to annotate every concept in each and every class stinks of the same mentality that leads to xml over configuration ... have a hammer ... everything looks like a nail.

    None-the-less ... the concepts in Seam integrated with JSF are kick ass powerful. I just want to be able to weave these concepts into my classes rather than embed them.
  35. Annotations vs External Configuration[ Go to top ]

    The concept of conversation scope being included in a class as an annotation ... each and every new use of that class within a different workflow will require a new annotation to that class ... these things have no relevance on the business logic implemented in the class.

    But in your example, each "workflow" is a conversation, so why would ever it have any other scope than conversation scope? :-)

    Nevertheless it is possible for a class to have more than one "scope". It is just a lot rarer than you might guess. One of the few good examples is the User class, which usually represents the currently logged in user (Session scope), but other times represents a User associated with the conversation (Conversation scope).

    If that is the case in your application, simply don't make the User the thing that is a conversation-scoped component. Instead, have some other stateful contextual component that holds a reference to the User. This is a basic pattern in Seam, and one that gives all the flexibility you need. Eg. have a session-scoped Login object that holds the current User, and a conversation scoped Customer object that holds the customer User.

    So there are certainly two approaches here:

    (1) Make your model objects (your entities) Seam components (as in the Booking or DVD Store demos)
    (2) Have stateful components that "manage" the model objects (as in the Issue Tracker demo)

    Which approach is more appropriate depends upon the actual application.

    In fact, in Seam beta 2 there is a third approach!

    Any Seam component can declare multiple roles (each with its own context variable name and scope) using the @Roles annotation).

    @Roles({
       @Role(name="currentUser", scope=SESSION),
       @Role(name="customer", scope=CONVERSATION)
    })
    public class User { ... }

    Having said all this, I have no ideological problem with allowing declaration of Seam components to be done via XML. This is of course quite trivial to implement. But so far no actual user has requested this. I have to be careful to not throw in features that people think they need after a quick look at Seam, I only want the features that people will really use once they actually start using this stuff in practice.

    The reality is that the annotation-based approach offers massive advantages in terms of productivity and understandability. And this is what most users will want to use once they get into it.
  36. Annotations vs External Configuration[ Go to top ]

    Having said all this, I have no ideological problem with allowing declaration of Seam components to be done via XML. This is of course quite trivial to implement.

    That's good news.
    I think that the key issue is simplicity versus complexity, or declaring versus programming, and not @annotations vs XML. But , you cannot avoid that some people love XML and hate @annotations and vice versa (this probably is more emotional than practical issue). If you allow the 2 formats, then your framework may be more inviting for more people.

    We will see the evil or divine part of annotations when they will be used to develop large applications in the next years....

    Some ideas in annotations vs XML in
    http://www.gestion400.com/openxava/portal/SeamBooking
  37. The argument being made that it is okay to utilize annotations within a class to describe things such as database mapping and lifecycle scope because they are not configuration but rather metadata is soft at best. I agree that this type of information is not configuration and that it is metadata. However, it is contextual metadata meaning that it is relevant within a particular usage of the class but NOT EVERY usage of the class.
    No offense, but you just totally contradicted yourself there. If it is relevant within a particular usage, it's not declarative programming but configuration information and it's best left out of the class. But like I said before, think about EJB 2.1, is it possible to change a bean to be stateless to be stateful without changing some code? I don't think so, so it isn't configuration information and can be handled better by annotations.

    have a hammer ... everything looks like a nail.
    Well, this has to be the most over-used expression lately. Quite ironic isn't it?
  38. Annotations vs External Configuration[ Go to top ]

    A banking application has an Account class, instances of this class may be utilized in one manner within a web application, and in a completely different manner within a service layer, and in a completely different manner within a thick client.
    Things are very simple, just use different annotations for different contracts. If it conflicts ( like @Serializable and @Remote) then you can not use both to annotate same class, just declare new class. Same "problem" exists with interface contracts too.
  39. Annotations vs External Configuration[ Go to top ]

    ...Placing metadata related to persistence or ui lifecycle scope into a domain class simply results in mashing together many concerns that could and should be separated...

    I disagree... database-driven web applications is at least one class of application where "mashing together" form validation, persistence, and UI lifecycle concerns makes alot of sense, and that's what Seam is designed for.

    You raise a valid point that an Account class shouldn't have to know whether it belongs in the conversation scope. However, this is business logic related, so I don't think it's the stuff of XML either. Seam does allow you to place a variable in a context programmatically--this can be done in your business logic layer, with no @Scope or @Name annotation on the Account class itself.
  40. http://blog.taragana.com/index.php/archive/jboss-seam-stripes-and-hibernate-an-irreverent-look-at-java-software-frameworks/
  41. I have been working with Seam for the past 7 months. I have been working with Spring, JBPM and JCR for past 3 years. There are strengths for seam which is merely a way of wiring different frameworks together to create a web application with EJB3 support (optional, we may use plain java objects without transactionality ..etc) The way IOC is implemented is so different from other IOC containers and its implementation completely focuses on Component oriented declerative programming style by IOC (Using annotations) and EJB3 annotations. Its a great technology to create robust web application which uses newer and emerging frameworks like JSF,EJB3 ...etc. Seam itself is not directly providing any transactionality, but rather it leverages benifits from EJB3. But, if we are not using EJB3 (for its implementation immaturity), how can we get good transaction support? So many enterprise resources are just resources, not components and can be used only with stateless environment, or restful environments. In this case How seam can help to create reusable components to be reused? JSF is one way of working with coponent based UI model, but Learning curve is steep and takes a lot of time, so most of the developers try to use their well known MVC frameworks and strive for separation to facilitate to another better framework once team or people build extertise on those. In this way, seam may not help there. As i see, Seam is very good to create a new web application by liveraging new J2EE frameworks where you can not reuse your previous component models, but adopt a new style of component oriented decelrative style. As the above said, Spring is a framework which is the same a seam(wiring different frameworks) which gives a way to get things working with less learnign curve and add support as you go along.It works with JAVA 1.3 and it is not only for web based application but for all who tries to liverage IOC. Anyway, Spring is not standard but widely supported and used, Seam also same. I want to conclude it as follows, Seam and Spring are not comparable and very different in nature, the way they built and the problem they targeted. Spring tried to provide IOC container for any kind of java implementation by using XML decelrative style which liverages all of the most used J2EE frameworks and Seam tried to provide a IOC container for web based applications which liverages some perticular j2ee frameworks to name such as JSF, EJB3 and JBPM. I hope this is helpful to users who are trying to find Seam and Spring places.