Article: JBoss Seam: A "Deep Integration" Framework

Discussions

News: Article: JBoss Seam: A "Deep Integration" Framework

  1. Michael Yuan has written "JBoss Seam: A 'Deep Integration' Framework" for TheServerSide.com, showing how Seam works to make developers' lives easier when creating applications in Java. The article shows the integration points Seam offers (as well as summarizing what an "integration framework" is in the first place), and shows off Seam's integration with JSF vendors such as RichFaces and IceFaces - in addition to its integration with Javascript itself. Business process modeling, alternate output via iText, and advanced job scheduling are also addressed. [Editor's note: Bleargl. Link fixed. Copy/paste error.]

    Threaded Messages (43)

  2. broken link[ Go to top ]

    I suppose the link is broken..
  3. I think the article should be renamed to "SEAM - not so deep integration framework" IMHO if there is an integration framework it's name is Spring Am I the only one who tied of jboss ads on server side? ;-)
  4. stop talking about spring[ Go to top ]

    Spring rocks, no doubt about it. But please, this thread is for talking about SEAM, that is ANOTHER framework. You are not tied to JBoss, you can have SEAM in any AS or even on Tomcat.
  5. You are not tied to JBoss, you can have SEAM in any AS or even on Tomcat.
    Indeed thats how SEAM is marketed. But it's not the reality. There is absolutely no application server specific documentation available (just try searching 'weblogic' or 'webphere' from the docs and you have 0 hits). Also, this lack of documentation is surely not because things would work so smoothly that no documentation is needed. I'v managed to get Seam running in Glassfish 1 and WebLogic 10, but that took me all afternoon of trial and error, and still in the end both required adding manually tags. Plus, no matter what i did, i couldn't get Seams internal logging to work with Glassfish.After seeing the real state of this claimed app server support i have absolutely zero faith left in using Seam in a non-jboss app server for actual production. To me it seems that JBoss claims app server compatibility based on deploying a single demo app to a single version of a given app server - and leaves even this totally undocumented. /Henri Karapuu
  6. so I went testing it[ Go to top ]

    jboss seam has 2 demos booking demo and dvd store demo booking demo is ok, then you logout. after that, I clicked on the browser "back" button and I could access those "protected" pages without any problem. sounds not very safe funny, because the seam documentation says "Traditional web applications are incredibly vulnerable to bugs and performance problems relating to state management. Developers are forced to handle issues like back button navigation, multi-window browsing, session size management in an utterly ad-hoc fashion." then I went to the dvd store demo, and while trying to login, an ugly exception was raised (and I could see the whole stacktrace) so, we were talking about what? oh yes, an incredible new java framework that will fight with ROR and solve all our problems. Of course. and it's SOOOO easy to install and configure. just follow http://labs.jboss.com/jbossseam/gettingstarted instructions, which demands 3 days, and you just need to edit a couple of properties files what I would REALLY like is a ROR in Java with eclipse + everything ready to download and install, nothing to setup, ready to use, ready to develop, with a very very nice documentation is it THAT hard?
  7. Re: so I went testing it[ Go to top ]

    jboss seam has 2 demos
    Actually Seam has almost 30 demos. If you are talking about the totally out-of-date stuff on demo.jboss.com, we have not had time to update those demos for months, too much other work to do.
    booking demo is ok, then you logout. after that, I clicked on the browser "back" button and I could access those "protected" pages without any problem. sounds not very safe
    Ahem, seems you had a slight misunderstanding on how browsers work. The back button is a pure client-side thing. There is no way to "disable" backward navigation after logout (except using HTML headers, but that would completely disable backward navigation globally, which is not what we want). However, if you backbutton and then try to click a button, watch what happens. Seam detects that a request has occurred outside of a login session and redirects you to the login screen. So, very safe, actually.
    then I went to the dvd store demo, and while trying to login, an ugly exception was raised (and I could see the whole stacktrace)
    I can't currently login to the DVD demo on demo.jboss.com either. Like I said, that's totally outofdate and we havn't touched it in months. Try deploying the dvdstore from the Seam distribution, it works beautifully, of course.
    and it's SOOOO easy to install and configure. just follow http://labs.jboss.com/jbossseam/gettingstarted instructions, which demands 3 days, and you just need to edit a couple of properties files
    It does not demand three days. It asks for a couple of hours each day over three days. What a silly comment.
    what I would REALLY like is a ROR in Java with eclipse + everything ready to download and install, nothing to setup, ready to use, ready to develop, with a very very nice documentation is it THAT hard?
    No, its not very hard at all. Seam is super-easy to get started with: http://docs.jboss.com/seam/2.0.0.B1/reference/en/html/gettingstarted.html Of course, if you expect to be able to get started by surfing jboss.org for five minutes looking for things to criticize, and then spending ten minutes bitching on TSS, then you won't have success with Seam (or any other framework).
  8. Re: so I went testing it[ Go to top ]

    No, its not very hard at all. Seam is super-easy to get started with
    Perhaps this is the core of my point from the previous post. Seam indeed is really easy to get started with seam-gen, using the prescribed project structure, and deploying to JBoss AS. However, when moving to custom project structure and non-jboss app servers things change from 'super-easy' to 'the most difficult to configure and deploy framework ever' (IMO). /Henri Karapuu
  9. Re: so I went testing it[ Go to top ]

    However, when moving to custom project structure and non-jboss app servers things change from 'super-easy' to 'the most difficult to configure and deploy framework ever' (IMO).
    How come? As it stitches together JSF and Hibernate, which I've not had trouble with on serveral app servers, hence Seam has a good chance of being the same.
  10. Re: so I went testing it[ Go to top ]

    Seam indeed is really easy to get started with seam-gen, using the prescribed project structure, and deploying to JBoss AS.

    However, when moving to custom project structure and non-jboss app servers things change from 'super-easy' to 'the most difficult to configure and deploy framework ever'
    * In Seam2, moving to a non-jboss app EE5 server typically requires no changes apart from dependencies and perhaps the requirement for ejb-links listed in web.xml. * Moving to a custom project structure different to the one we recommend can indeed be difficult. But this is nothing to do with Seam, this is purely an issue with the (over-complex) Java EE 5 depoyment archive. (Java EE 6 will almost certainly alleviate this by letting you deploy everything in a WAR.) OTOH, if you follow our recommended project structure, you will have no problems. * I can't make seam-gen work smoothly for EARs on GlassFish/etc, because of the aforementioned need to list all EJB3 beans in web.xml. This makes it difficult for tools like seam-gen to automate creation of new components. * I *could* easily make seam-gen work smoothly for WARs on GlassFish/etc, there is basically no difference in the deployed project, only a different set of dependent jars. So, it seems to me, you are blaming Seam for stuff that is "not our fault".
  11. You are not tied to JBoss, you can have SEAM in any AS or even on Tomcat.


    Indeed thats how SEAM is marketed. But it's not the reality.

    There is absolutely no application server specific documentation available (just try searching 'weblogic' or 'webphere' from the docs and you have 0 hits).
    The Seam distribution includes two examples which run on WebSphere, WebLogic, OC4J, Tomcat, GlassFish and JBoss out of the box, just by typing, eg. "ant glassfish" and deploying the resulting war. Look at examples/jpa and examples/hibernate2. The distribution also includes a further example which run on GlassFish, OC4J and JBoss out of the box (ie. the platforms which support EJB3). Look at example/jee5.
    I'v managed to get Seam running in Glassfish 1 and WebLogic 10, but that took me all afternoon of trial and error
    First, it definitely does not take "all afternoon" to get the aforementioned examples running on GF or WL. In fact, it takes about 10 minutes. Second, if you *don't* start from one of those three examples, then yes, indeed, it might take an afternoon of effort to get a project written using Seam or any other framework working on 3 different application servers. (It would not take *me* that long, I can certainly see how it might take brand new users a bit of fiddling.) That's just normal and expected in the Java EE world.
    still in the end both required adding manually tags.
    These are required by glassfish, and you should complain to Sun, they are not our fault, I have already whined to Sun about this crazy requirement. You cannot write an EE5 application in GlassFish without having to write this tedious XML. I'm sorry if GlassFish sucks. I'm even sorrier that Seam gets the blame for it.
    Plus, no matter what i did, i couldn't get Seams internal logging to work with Glassfish.
    Strange, it works just great for me in the example applications.
    To me it seems that JBoss claims app server compatibility based on deploying a single demo app to a single version of a given app server - and leaves even this totally undocumented.
    Three example applications, actually. I'm not sure what open source frameworks you've used which are formally tested against multiple versions of every application server before each release (AFAIK, nobody does this). Rather, we test the three aforementioned examples against the most recent version of each of the major application servers. (This is a time-consuming process that Michael Yuan goes through each release.) We also get feedback from the Seam community, who are deploying on a variety of application servers. So, if you know of any actual, real bug in Seam's compatibility with some application server other than JBoss, please report it in JIRA, where it will be taken seriously and fixed. Or, if the reality was that you spent one afternoon on this, ran into a couple of little frustrating issues, and then wanted to work off your frustration by slamming the hard work of others on TSS, that's fine, it's par for the course around here. We have poured effort into compatibility testing, and I don't believe your summary of the situation was anything like fair or accurate. Especially since you seem unaware of some of the examples that are out there.
  12. Gavin, i understand your frustration. Let me clarify couple of points. Firstly, i'm well aware of the Seam example projects. Yes, the example apps include some valuable information, but demo apps are NOT documentation, nor they are sufficient substitute of it. Moreover, there are problems with the example projects; they use non-standard directory/project structure, which (i) violates the enforced standards of many companies, and (ii) does not work well with Eclipse or IDEA. As such, the examples were not usable starting point, and as you guessed, the 'all afternoon' referred to building a new project and build system from scratch and getting it deploy to jboss, glassfish and weblogic. And the problem was not the 'afternoon spent', but that the process of creating a simple, standalone project which follows standard structure and deploys to supported application servers was a totally undocumented process and i was left scrounging for config files from demo projects and playing with settings 'trial and error style'. Basically this experience left me with very little faith that the supported app servers were decently tested with Seam, that things would work well with real/complex applications, and that in case of difficulties we would be able to obtain proper support. I hope this clarifies the situation a bit. I feel that my original words were 100% accurate and fair, but if you still feel otherwise i'd happy to elaborate more, or offer concrete suggestions what to improve specifically.
    Or, if the reality was that you spent one afternoon on this, ran into a couple of little frustrating issues, and then wanted to work off your frustration by slamming the hard work of others on TSS
    The reality was that i spent couple of weeks on Seam, ran into very difficult issues with deployment, code maturity and documentation, and finally, reluctantly, was forced not to recommend the use Seam at this point in time, even though i personally feel it is technically very advanced. /Henri Karapuu
  13. Firstly, i'm well aware of the Seam example projects. Yes, the example apps include some valuable information, but demo apps are NOT documentation, nor they are sufficient substitute of it.
    OK, we've definitely emphasized examples as the way to learn Seam. I decided this was a better route than the one we took with Hibernate, which was all doc-centric. I can certainly ask Michael to write some docs covering deployment to GlassFish and other appservers. Until now I had assumed the examples were sufficient for most users.
    Moreover, there are problems with the example projects; they use non-standard directory/project structure, which (i) violates the enforced standards of many companies, and (ii) does not work well with Eclipse or IDEA.
    Oh, come on, that's silly. There is no such thing as a "standard" directory/project structure, there is only an EE standard deployment archive structure (EAR), which the examples all comply with. Yes, we are aware that the structure we use in the examples is not the same one preferred by Eclipse WTP, and the coming integration of seam-gen with JBoss Tools will address this issue this by allowing creation of a WTP-style project.
    And the problem was not the 'afternoon spent', but that the process of creating a simple, standalone project which follows standard structure and deploys to supported application servers was a totally undocumented process and i was left scrounging for config files from demo projects and playing with settings 'trial and error style'.
    Seam absolutely does not require anything special in terms of project structure or deployment archive structure. If you are wrestling with this stuff, you are wrestling with Ant and Java EE, not with Seam! The *only* Seam-specific metadata files in a Seam2 project are the pages.xml and components.xml files, which belong in WEB-INF/lib. Everything else is totally EE-standard stuff. And I just visually diffed the archive that deploys on GlassFish with the one that deploys on JBoss. The only difference between the two is: (1) some extra dependent jars in the GlassFish archive, which are already present in JBoss (2) the requirement for each EJB3 bean to be listed as an in web.xml Clearly, (1) is trivial. (2) is a problem, but it is not a problem of Seam, the same requirement exists for any GlassFish project that uses EJB3 beans. I hate it, but nothing I can do about it. JBoss does not have this requirement. These are the ONLY differences between Seam2 on JBoss and Seam2 on GlassFish. Neither difference is specific to Seam. Note that this is with Seam2, there may be additional differences in Seam 1.2.
    Basically this experience left me with very little faith that the supported app servers were decently tested with Seam, that things would work well with real/complex applications, and that in case of difficulties we would be able to obtain proper support.
    That's a pure assumption. You havn't demonstrated it at all. All you've shown is that you had problems creating a Java EE 5 project with deployment to a standard EAR. Nothing specific to Seam at all.
  14. Oh, come on, that's silly. There is no such thing as a "standard" directory/project structure, there is only an EE standard deployment archive structure (EAR)
    It does not matter if we call it a non-standard or something else, but the fact remains that Eclipse WTP, IntelliJ IDEA and 100% of my clients' projects all use same structure, and this is different and incompatible with you'v done with Seam. Also please note that i didn't complain about the structure, i only mentioned it as the reason why i was not able to utilize the examples more.
    Seam absolutely does not require anything special in terms of project structure or deployment archive structure. If you are wrestling with this stuff, you are wrestling with Ant and Java EE, not with Seam!
    I'm very comfortable with the EAR structure, and that was not the source of the difficulties. The difficulty was just the combination of getting all config files exactly right, with an exactly correct set of library dependencies. In the end i needed *eleven* XML config file (many of which in addition required different versions for different app servers) and three different sets of libraries that each had to be deployed differently depending on app server (sometimes as EAR modules, sometimes under /lib of of the web-app). And this was just for supporting Java EE 5 application servers! Then there is all the J2EE application servers. And then Tomcat. So it seems that during the Afternoon i only solved one third of the problem. It would probably require yet more XML files and library dependencies to get entirely different platforms to work (J2EE and Java SE), as opposed to my modest efforts with just different Java EE 5 app servers ... These difficulties could be acceptable if doing 'one-time custom' project which would be deployed to a single application server. For 'product' style development, that needs to be deployed to a wide range of platforms, my honest opinion is that Seam is very bad choice. Shipping a Seam based product that customers would need to install to variety of platforms would be slaughter for customer support. Only solution as i saw it would had been to develop a build system that allows transparent/automatic deployment of Seam applications to any application server, basically taking care of the JEE5, J2EE and JSE differences, and then differences between various app servers. That seemed quite a difficult task, and it was something that would had increased the total cost of building a Seam based product over the cost of competing alternatives. Sorry that i rubbed you again in a way that did not cause pleasure. I hope that ultimately hearing concerns of potential customers and reasons why they did not start using Seam is helpful. /Henri Karapuu
  15. Oh, come on, that's silly. There is no such thing as a "standard" directory/project structure, there is only an EE standard deployment archive structure (EAR)


    It does not matter if we call it a non-standard or something else, but the fact remains that Eclipse WTP, IntelliJ IDEA and 100% of my clients' projects all use same structure, and this is different and incompatible with you'v done with Seam.
    Just like Rails, or any of these rad environments, Seam is much easier to work with if you follow our recommended project directory structure. It is done like that for good reasons, enabling: * in-IDE unit and integration testing with TestNG * automatic exploded directory deployment from Eclipse allowing changes in facelets pages and some code to be immediately visible by pressing the browser refresh button * easy deployment to an EAR/WAR If you decide to not follow our recommendations, you will probably find Seam more difficult to work with. Not by any means impossible - after all, Seam applications are simply standard EARs. But you will lose some time getting everything "right". This is much more to do with the complexity of making EE5, Eclipse, Ant and TestNG work nicely together than it is to do with Seam. Seam adds no real additional complexity that is not already present in any EE 5 project that needs to be integration tested. I understand that most EE projects today simply *don't* allow easy integration testing, but that is a Bad Thing. Now, compatibility with Eclipse WTP is something that is being actively worked on, but I'm not really sure what it gains you compared to what is already possible with the standard seam-gen project structure.
    I'm very comfortable with the EAR structure, and that was not the source of the difficulties. The difficulty was just the combination of getting all config files exactly right, with an exactly correct set of library dependencies.

    In the end i needed *eleven* XML config file (many of which in addition required different versions for different app servers) and three different sets of libraries that each had to be deployed differently depending on app server (sometimes as EAR modules, sometimes under /lib of of the web-app). And this was just for supporting Java EE 5 application servers! Then there is all the J2EE application servers. And then Tomcat. So it seems that during the Afternoon i only solved one third of the problem. It would probably require yet more XML files and library dependencies to get entirely different platforms to work (J2EE and Java SE), as opposed to my modest efforts with just different Java EE 5 app servers ...
    The following config files are required in a typical Seam application: application.xml ejb-jar.xml faces-config.xml web.xml persistence.xml components.xml pages.xml All except the last two are standard Java EE 5 metadata. The second to last is a configuration files that is usually needed by Seam. The last is a totally optional configuration file used by Seam for separating orchestration logic from the Java components. That is 7 XML config files, not 11. I have no idea where you get 11 from. In Seam2, there are no app-server-specific difference between any of them, except for: * ejb-link elements are required in web.xml for some application servers and optional in others * persistence.xml will depend upon the persistence provider you use * on pre-Java EE 5 application servers, dependencies must be listed in application.xml (Java EE 5 application servers have an EAR lib/ directory) So, if you choose to use the same persistence provider everywhere, always list dependencies in application.xml and always list ejb-links in web.xml then there are NO platform-specific differences between them. Notice that none of the three listed differences is remotely anything to do with Seam. Now, prior to JBoss AS 4.2, where we needed to target two versions of JSF (MyFaces was 1.1, EE5 requires 1.2), this picture was complicated by the different configuration requirements for the different JSF versions. Also, the older version of JBoss Embedded needed to be installed in components.xml to enable integration testing, whereas we have a much better solution for this now, which means no tweaks to components.xml are needed for integration testing. But as of Seam2 and JBoss 4.2, these things are no longer an issue. Anyway, it looks to me like you made things way more complicated for yourself than they needed to be. If you can explain why you needed 11 files instead of 7, and what other files you needed multiple versions of, perhaps I can help you discover where you went wrong....
  16. I should also point out that if you decide NOT to use EJB3, and use Seam JavaBean components instead, and deploy as a WAR then: * you don't need application.xml or ejb-jar.xml * you don't need any ejb-links in web.xml So we are down to 5 configuration files, only one of which (persistence.xml) changes between deployment environments. ie. the exact same metadata applies in EE 5, J2EE and Tomcat.
  17. but I'm not really sure what it gains you compared to what is already possible with the standard seam-gen project structure.
    1. Many clients have strict guidelines for project structures, that just have to be followed, or then the process of changing their 'best practices' must be endured. 2. Using project structure that is not compatible with IDEs is rather inconvinient, although not a total show stopper. Everything that works with zero-effort from within IDE, like deploying, running, starting debugging, starting profiling, hot-reloading classes etc. would need to be programmed as Ant tasks. I honestly don't have a glue how would i do hot reload of classes using Ant. Note, i'm talking about IDEA here, i'm not sure if you'v done some work that makes Eclipse work better?
    Anyway, it looks to me like you made things way more complicated for yourself than they needed to be. If you can explain why you needed 11 files instead of 7, and what other files you needed multiple versions of, perhaps I can help you discover where you went wrong....
    The differences between our counts of config files (7 vs. 11) were 3 app server deployment descriptors, and hibernate.properties. Okey, not an XML file. The config files that required modification between app-servers were: - persistence.xml - application.xml (different dependency requirements) - components.xml (different jndi patterns) - web.xml (the damned s ... which btw are also needed by weblogic, it seems) Good example why i'v been having this cold n' mushy feeling is the jboss-app.xml file. You mention in this thread that app server specific files are not needed, but as there is no documentation my only change was to go scrounging the demos. Jboss-app.xml file is in the demo that i used as 'model' for my project, so i assumed it is needed, and thus it ended in my test project .. It should be also noted that my testing was done with latest release version 1.2.1GA, while you mention often '2.0 beta'. This might explain some of the differences in perceived ease of deployment. Now i'm off for a beer. Thanks for your replies and have a great weekend, /Henri Karapuu
  18. Many clients have strict guidelines for project structures, that just have to be followed, or then the process of changing their 'best practices' must be endured.
    Sometimes "best practices" need to change with the times.
    Using project structure that is not compatible with IDEs is rather inconvinient, although not a total show stopper. Everything that works with zero-effort from within IDE, like deploying, running, starting debugging, starting profiling, hot-reloading classes etc. would need to be programmed as Ant tasks. I honestly don't have a glue how would i do hot reload of classes using Ant. Note, i'm talking about IDEA here, i'm not sure if you'v done some work that makes Eclipse work better?
    All of those things you just listed work perfectly out of the box with a seam-gen'd project, in Eclipse and NetBeans. If something is *not* working in IDEA, then someone needs to report that in Seam JIRA, not on TSS. (You don't do hot reload of classes using Ant, of course, you let Eclipse do the work, I don't see why IDEA would be different.)
    The differences between our counts of config files (7 vs. 11) were 3 app server deployment descriptors, and hibernate.properties. Okey, not an XML file.
    And how the hell do the 3 app server deployment descriptors have anything at all to do with Seam??!! Is there anything Seam-specific in them? (Of course not.) How is using some other framework going to help you avoid adding them?? hibernate.properties?? What do you need that for? Use persistence.xml. Thanks, you have just helped prove my point that your problems are to do with the complexities of multi-platform EE development in general, and nothing at all to do with Seam. Please give me a single example of a single app-server-specific setting that you needed to make with Seam that you would not need to make in another framework. If you can't give an example then I think I've proved my point, wouldn't you say?
    Good example why i'v been having this cold n' mushy feeling is the jboss-app.xml file. You mention in this thread that app server specific files are not needed, but as there is no documentation my only change was to go scrounging the demos. Jboss-app.xml file is in the demo that i used as 'model' for my project, so i assumed it is needed, and thus it ended in my test project
    That file is definitely not needed by Seam. If you understood the JBoss classloading architecture you would realize that it is simply enabling scoped classloading, which is something you should always do when deploying multiple isolated applications to JBoss AS. Absolutely nothing to do with Seam. So far, the concrete examples you have given have gone absolutely nowhere to show your initial contention that Seam's multi-platform support is "BS". All you have shown is that in general, developing multi-platform EE applications can be a bit fiddly and take a few days to get right. Well, that is something I thought we all already knew.
  19. All of those things you just listed work perfectly out of the box with a seam-gen'd project, in Eclipse and NetBeans. If something is *not* working in IDEA
    The project structure is impossible to setup as an IDEA 'EAR project'. It would require 3 modules (ear, war, ejb-jar) and idea does not allow these to have same root directory. I guess i could setup it as regular java project, build the project with ant and still use IDEA to run, debug etc. but in this case i'd probably lose IDEAs Java EE specific support (for example 'EE Structure view' and EJB specific things). Of course it's possible to ask the question the other way round - what were the pressing reasons to choose project structure that is incompatible with tools such as WTP and IDEA?
    hibernate.properties?? What do you need that for? Use persistence.xml.
    Sorry, meant seam.properties. It was late.
    That file is definitely not needed by Seam. If you understood the JBoss classloading architecture you would realize that it is simply enabling scoped classloading,
    Guess what. I don't understand JBoss class loading architecture. If users would understand everything the invention called 'documentation' would not be necessary. /Henri Karapuu
  20. All of those things you just listed work perfectly out of the box with a seam-gen'd project, in Eclipse and NetBeans. If something is *not* working in IDEA

    The project structure is impossible to setup as an IDEA 'EAR project'. It would require 3 modules (ear, war, ejb-jar) and idea does not allow these to have same root directory. I guess i could setup it as regular java project, build the project with ant and still use IDEA to run, debug etc. but in this case i'd probably lose IDEAs Java EE specific support (for example 'EE Structure view' and EJB specific things).

    Of course it's possible to ask the question the other way round - what were the pressing reasons to choose project structure that is incompatible with tools such as WTP and IDEA?


    hibernate.properties?? What do you need that for? Use persistence.xml.

    Sorry, meant seam.properties. It was late.


    That file is definitely not needed by Seam. If you understood the JBoss classloading architecture you would realize that it is simply enabling scoped classloading,

    Guess what. I don't understand JBoss class loading architecture.

    If users would understand everything the invention called 'documentation' would not be necessary.

    /Henri Karapuu
    Henri, we can definately make Seam as painless as possible on JBoss and probably Tomcat standalone platforms. Since the Web Beans JSR seems it will become part of EE 6, we can probably address cross-platform difficulties in the spec process. My question for you is, should we make it as easy as possible on JBoss/Tomcat? Less steps and less configuration there? While requiring more steps on platforms we have less control over? Or is vanilla, standard Java EE what we should focus on? I guess what I'm asking is, should we have real tight integration with JBoss/Tomcat and document a different procedure for configuration for non JBoss/Tomcat platforms? This question applies not only to seam but to other JBoss projects that are packaged to run in other environments. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  21. My question for you is, should we make it as easy as possible on JBoss/Tomcat? Less steps and less configuration there? While requiring more steps on platforms we have less control over? Or is vanilla, standard Java EE what we should focus on?
    I think developers are used to bit of pain. It's not so important whether things are smooth or super-smooth and whether there are couple of steps more or less. However, what is critically important, imho, is to keep all cases under "threshold of abandonment". That is, providing enough documentation so that the developers can follow certain steps without detective work or trial-and-error hacking. Kind of like 'keeping developers on map'. Giving them feeling that what they are doing is supported and well tested, even if it requires bit of manual work. For example in this Seam case what happened was that i moved somewhat out of the base scenario (i needed different project structure), and i fell completely off the cliff. There were absolutely no app-server specific documentation. I had to build example projects, then unpack the archives to see what config file goes where, and then do about 100 deployments in trial-and-error style to find the correct settings for config files and required library dependencies. So yes, in the end i managed to get things working in an afternoon. But the process to get there was so undocumented that i was left with feeling that i was flying totally out of the map, that what i was doing was not supported and tested, that i was hacking. After this experience i had zero faith left that things would go smoothly during development, which ultimately caused me to abandon Seam. /Henri Karapuu
  22. Gavin King: Oh, come on, that's silly. There is no such thing as a "standard" directory/project structure, there is only an EE standard deployment archive structure (EAR)

    Henri Karapuu: It does not matter if we call it a non-standard or something else, but the fact remains that Eclipse WTP, IntelliJ IDEA and 100% of my clients' projects all use same structure, and this is different and incompatible with you'v done with Seam.
    Hi Gavin, Henri's comment resonates with me. My initial experience with Seam (and seam-gen) was one of both interest and confusion. The default Seam project layout is definitely counter-intuitive, but once you understand how simple it is, you are correct, it can be quite easy to get up and running fast with Seam. Personally, I'm a fan of the standard Java Web application layout for projects (eg. WEB-INF, META-INF, etc.), and I find this natural and compatible with my experience writing webapps. I understand that in the case of Seam projects that you are potentially targetting an EAR deployment, so a Web application-style project layout is not ideal for all scenarios. Enter seam-gen. What I have done is to use seam-gen to get a feel for the Seam project layout (to iterate what you have said, it simply requires seam.properties, components.xml, pages.xml, or some combination of the above. These resources can be added to any existing Eclipse project, for example, be it a webapp or an EJB JAR project, without much difficulty. In fact, my development team and I have been using Seam in production for many months now, quite successfully. It is definitely a very enjoyable framework to use. Combining EJB3 and JSF is simply a great idea. We got pretty excited about Seam and my company built Seam Tools for Dreamweaver, to help developers (and designers) leverage Dreamweaver to build Seam applications. If Seam followed a more conventional layout for projects, this would go a long way towards better round-trip engineering support for our users. Keep up the good work! Ian -- Ian Hlavats JSFToolbox for Dreamweaver
  23. These are required by glassfish, and you should complain to Sun, they are not our fault, I have already whined to Sun about this crazy requirement. You cannot write an EE5 application in GlassFish without having to write this tedious XML. I'm sorry if GlassFish sucks. I'm even sorrier that Seam gets the blame for it.
    I've written a LOT of EE5 apps, all deployed on GlassFish. Beyond the little bit of XML for web.xml, JSF and JPA (which I'm about to get rid of mostly with Seam ;), I don't write XML. And, IMO, GlassFish most certainly does not suck, but this isn't the right forum (as I eye the Spring people... ;).
  24. These are required by glassfish, and you should complain to Sun, they are not our fault, I have already whined to Sun about this crazy requirement. You cannot write an EE5 application in GlassFish without having to write this tedious XML. I'm sorry if GlassFish sucks. I'm even sorrier that Seam gets the blame for it.


    I've written a LOT of EE5 apps, all deployed on GlassFish. Beyond the little bit of XML for web.xml, JSF and JPA (which I'm about to get rid of mostly with Seam ;), I don't write XML. And, IMO, GlassFish most certainly does not suck, but this isn't the right forum (as I eye the Spring people... ;).
    To clarify, I don't really think that GlassFish sucks, I'm just annoyed about the silly requirement for ejb-link.
  25. Okey, the core of all this ...[ Go to top ]

    And how the hell do the 3 app server deployment descriptors have anything at all to do with Seam??!!
    I think the main difference between our thinkings is that i take much more holistic view. SEAM's main claim to fame is ease of development, and that is what i'm evaluating, as a *whole*. Now we are constantly running into arguments like: Henri: "X sucks" Gavin: "Okey, but it's not SEAM's fault" I don't care if it's the fault of Jesus Christ. I'v been "sold" a complete application development framework, and thats what i want, instead of blaming of others. Prime example of this is the . Two out of two non-jboss application servers i tried required these. Maybe not Seam's fault, but in practice makes development more XML intensive than Spring. My view of framework developers duty is similar to that of good chef's: Using whatever ingredients you are given ensure great dining experience. If there is problem with some ingredient work around that problem, substitute it with something else etc. When in restaurant i don't want to be served a rotten egg and then told "hey, the egg was already rotten, it's not our fault!". I'm not really saying that all of the complexity and difficulties are caused by Seam itself, it's more like Seam has chosen very demanding ingredients to work with, and does a sub-optimal job providing decent meal from them, in part of the cases. /Henri Karapuu
  26. Re: Okey, the core of all this ...[ Go to top ]

    I think the main difference between our thinkings is that i take much more holistic view. SEAM's main claim to fame is ease of development, and that is what i'm evaluating, as a *whole*. Now we are constantly running into arguments like: Henri: "X sucks" Gavin: "Okey, but it's not SEAM's fault" I don't care if it's the fault of Jesus Christ. I'v been "sold" a complete application development framework, and thats what i want, instead of blaming of others.
    Yes but the problem is you are trying to have your cake and eat it. If you want a "holistic" solution, in the nature of RoR, you can get it easily enough. The trouble is that you were NOT using the "holistic" solution. Instead you wanted to do things your own way and: (1) use a non-Seam-standard project layout (2) deploy to multiple app servers (3) use your own tools instead of the ones we primarily target Now, you can certainly do 1,2,3 and still use Seam, but it is going to be a bit more work. So you can have cake, or you can eat it, but not both at once. Hey, I could make Seam super-ultra-easy to set up and configure, by building on top of JBoss-specific APIs and essentially building Seam into the application server. Then there would be no need for web.xml, faces-config.xml and ejb-jar.xml at all. But because I *do* target multiple platforms, and EE5 standards, I need these files. That definitely increases the "getting started" overhead. Hey, I personally *hate* the whole over-engineered EAR archive structure and would prefer to package everything into the WAR. And again, I could make that work on JBoss. But it would not work on other platforms. So, the exact opposite of your initial assertion is true: your problems were caused by the fact that we do have real, working (non-"BS") multi-platform support. And targeting multiple platforms is always a bit of a pain, in *any* framework. If you want to avoid that pain, don't target multiple platforms.
    I'm not really saying that all of the complexity and difficulties are caused by Seam itself, it's more like Seam has chosen very demanding ingredients to work with, and does a sub-optimal job providing decent meal from them, in part of the cases.
    I'm always looking for ideas on how we can do better. You've provided two useful bits of feedback, which are: * use the Eclipse WTP style project layout (we were working on this already) * better document deployment to other appservers (we will work on this) Apart from that, you have not told me what we could do better. If we are "sub-optimal", give me an example of an optimal solution. Does some other framework that supports EE5, EJB3, in-IDE integration testing and exploded directory deployment with zero-turnaround solve these problems better? Well, I know the answer to this question: no, there is no other framework that does do better than Seam, because no other framework provides these features. Anyway, its the weekend, my girl is yelling at me for having my laptop open :-)
  27. Re: Okey, the core of all this ...[ Go to top ]

    The trouble is that you were NOT using the "holistic" solution. Instead you wanted to do things your own way and:
    The trouble was not that i would have to do bit of work. It was that when i moved out of the seam-gen path i fell of the cliff, to an evil, un-documented place. We also use word 'holistic' in entirely different ways here. I was refering to framework creators' responsibilities, not 'one click' RoR:ish framework (i'm not a fan of RoR btw, and it's not what i seek). Moreover, i didn't merely want to do things my own way, instead i _had_to_ do them the way how my clients and IDEs want things to be done, and this was not supported by Seam.
    So, the exact opposite of your initial assertion is true: your problems were caused by the fact that we do have real, working (non-"BS") multi-platform support.
    There were absolutely no app-server specific documentation, and as i said to Bill what i had to do was "build example projects, then unpack the archives to see what config file goes where, and then do about 100 deployments in trial-and-error style to find the correct settings for config files and required library dependencies". That simply does not qualify as "supported" for me. Possible: Yes, supported (without seam-gen): No.
    give me an example of an optimal solution.
    -- Document what features are available with different platforms (i.e. what i'll actually miss if i deploy on tomcat or J2EE server instead of JEE5), clarify benefits of EJB3 vs JavaBean based components, clarify differences/benefits of using MicroContainer vs Embedded JBoss. -- Open new chapter that contains specifics of each app srerver, down to every single config file, their exact location and exact contents (i.e. jndi-patterns), as well as exact list what jars are needed for which app servers and should they be app server java modules or go to web-app's lib dir. -- At later stage, create a build system that abstracts all those app server issues and is flexible regarding project structure. For example it could fist copy config files from platform dir (JEE5,J2EE or JSE), then add or override some files from appserver specific dir (JBoss, WebLogic, Tomcat..), then do variable substitution (for cases where config files are only slightly different between app servers), and finally run APT with velocity templates to take care of the ejb-local-refs. /Henri Karapuu
  28. I'v managed to get Seam running in Glassfish 1 and WebLogic 10, but that took me all afternoon of trial and error. /Henri Karapuu
    Actually, let me re-cast this as a success story:
    In just a single afternoon, I managed to get a Seam application up and running in Glassfish 1, WebLogic 10 and JBoss AS 4! /Henri Karapuu
    Just *one afternoon*. And you're *complaining*?? Wow, tough crowd around here ;-) I'm trying to imagine what could satisfy you ... do you expect to be able to develop a cross platform application running on three servers in under an hour? hmmmmm.....
  29. Re: not so deep comparing to spring ;-)[ Go to top ]

    Am I the only one who tied of jboss ads on server side? ;-)
    I don't know about that, but I'm sure I'm not the only one tired of Spring guys coming in to bang their drum at someone else's party.
  30. Different tools for different jobs[ Go to top ]

    I think the article should be renamed to
    "SEAM - not so deep integration framework"

    IMHO if there is an integration framework it's name is Spring

    Am I the only one who tied of jboss ads on server side? ;-)
    I try to stay out of the silly (IMO) Jboss-Spring politics, but on this particular point, I think you are not entirely correct. Each technology has its pros and cons. You have most likely not actually tried to use EJB3/JEE5/JSF with Spring. Although Spring offers some limited integration with these new technologies, Seam does a far superior job in this area. Obviously Spring provides a number of integrations that Seam doesn't provide, so as with anything in Java server development, you need to evaluate the pros and cons of both solutions. As an aside, I don't consider this article as egregious an advertisement for a particular technology as some of the more obvious product "announcements" that make it to the TSS front page. That said, it would be nice to see TSS adopt some sort of ethics standard requiring posters of articles to indicate that they have a vested interest in promoting a particular company or technology. A lot of posters do this in their signatures (Bill, Cameron, etc), but unfortunately not all article submitters are required to do the same.
  31. As an aside, I don't consider this article as egregious an advertisement for a particular technology as some of the more obvious product "announcements" that make it to the TSS front page. That said, it would be nice to see TSS adopt some sort of ethics standard requiring posters of articles to indicate that they have a vested interest in promoting a particular company or technology. A lot of posters do this in their signatures (Bill, Cameron, etc), but unfortunately not all article submitters are required to do the same.
    Michael is an employee of JBoss and the author of Seam's Quartz integration and is also responsible for most of the portability testing (ie. other appservers). AFAIK, he did not submit this post (he simply emailed the article to Joe, who posted it). I'm sure Michael would have been perfectly happy if Joe had identified him as a Seam contributor in the original post.
  32. so I strongly suggest you guys to shut those demos down, because it's very bad publicity. you may find my criticism offensive, so I may find this official documentation line, as well (from the link you've provided) "(...)This is the easy way to get your feet wet with Seam, and gives you some ammunition for next time you find yourself trapped in an elevator with one of those tedious Ruby guys ranting about how great and wonderful his new toy is for building totally trivial applications that put things in databases.(...)" this arrogant statement is also bad publicity. these ruby guys may be tedious (I am not a ruby fan), but at least, they're shaking the market with innovative ideas, helping to improve the standards and forcing jboss to work on better products - that even Seam can be one day
  33. so I strongly suggest you guys to shut those demos down, because it's very bad publicity.
    Good idea.
    you may find my criticism offensive, so I may find this official documentation line, as well (from the link you've provided) "(...)This is the easy way to get your feet wet with Seam, and gives you some ammunition for next time you find yourself trapped in an elevator with one of those tedious Ruby guys ranting about how great and wonderful his new toy is for building totally trivial applications that put things in databases.(...)" this arrogant statement is also bad publicity.
    "Welcome to TSS. Please check your sense of humor at the door." Sorry folks, Ima keep baiting zealots till the day I die :-)
    these ruby guys may be tedious (I am not a ruby fan), but at least, they're shaking the market with innovative ideas, helping to improve the standards and forcing jboss to work on better products - that even Seam can be one day
    In the past week I received emails from two different RoR users who are now evaluating a shift to Seam because they had run into limitations with Rails after several months of development. That's two projects, both with similar complaints. Just a datapoint for you. :-) Of course, I can't publish these private emails, but here is a little taste, I hope the author does not mind:
    After evaluating Spring, Struts 2.0, Tapestry, Wicket, Grails, etc., we're moving to Seam. We are starting with our XXXXX application, and will role the other 3 major applications subsequently. We accomplished a lot with RoR, but simply outgrew it.


  34. Of course, I can't publish these private emails, but here is a little taste, I hope the author does not mind:

    After evaluating Spring, Struts 2.0, Tapestry, Wicket, Grails, etc., we're moving to Seam. We are starting
    with our XXXXX application, and will role the
    other 3 major applications subsequently. We
    accomplished a lot with RoR, but simply outgrew it.
    +1 for Seam. We re-implemented a b2b web site for thousands of clients using seam (originally implemented with servlets, xml, xsl) adding much more complexity and taking in something like 1/5 of coding and testing time than the original project. I will describe soon in my blog as success story...I'll keep you and seam community post. /Stefano Maestri
  35. Hi Gavin, Sorry I missed your timely reply. Yes, my suggestion as such was pointed at the TSS editor(s) (maybe it's only Joe :) and not at Michael. Of course my reply to yours is so late, no one will probably ever see it ;) I suppose I can email Joe directly and ask him if he'd consider amending the editorial policy to include the author's "credentials", as most other technical publications do. In fact, I'm hoping to be able to catch Michael's talk at NEJUG in Burlington (MA) in October! Peter
  36. Correct Link[ Go to top ]

    http://www.theserverside.com/tt/articles/article.tss?l=JBossSeamFramework
  37. non-web apps[ Go to top ]

    What I think is going to become even more interesting is when the Seam team streamlines it so you can use Seam in non-web apps for things like orchestration and coordination. Add integration with things like an ESB and then you'll truly have a unified programming model. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  38. Could you elaborate?[ Go to top ]

    This part sounds interesting - "use Seam ...for things like orchestration and coordination". Is work being done on that? And what advantages would it bring?
  39. Re: Could you elaborate?[ Go to top ]

    I think it was meant Seam's integration with jBPM (http://www.jboss.com/products/jbpm)
  40. integration with wicket[ Go to top ]

    Excellent article, thanks! I'm looking forward to see a good integration with Wicket. Regards, Flavio.
  41. Re: integration with wicket[ Go to top ]

    Excellent article, thanks!
    I'm looking forward to see a good integration with Wicket.
    Regards,

    Flavio.
    Check this out.
  42. Re: integration with wicket[ Go to top ]

    Excellent article, thanks!
    I'm looking forward to see a good integration with Wicket.
    Regards,

    Flavio.


    Check this out.
    *yawn* has it been a year already? :-)
  43. Re: integration with wicket[ Go to top ]

    Excellent article, thanks!
    I'm looking forward to see a good integration with Wicket.
    Regards,

    Flavio.


    Check this out.


    *yawn* has it been a year already?

    :-)
    :) Time goes by fast when you're having fun. There is certainly still stuff that Seam can do to make integration with other frameworks easier. One would be to make a minimal distribution (I'd prefer something that could just run on JSE) with a minimal number of dependencies (there are quite a few currently, including JSF). Updated maven support would be another great thing imho (but I know not everyone agrees). I was initially thinking in the wrong direction when looking for Seam integration for Wicket. I was thinking along the lines of how it supports JSF. And that in turn depends a lot on EL in the view layer. Pretty incompatible with Wicket. It turned out that it was better to look at it as a DI library, though this time with support for scopes. And that works pretty nice actually! I'm sure there is potential for a lot more, but we're waiting for Seam to hopefully work on a more minimal distribution someday and/ or a good maven distribution, and for more feedback from both Gavin and the Wicket community. Right now the integration is a proof of concept rather than a well rounded project.
  44. Re: integration with wicket[ Go to top ]

    Excellent article, thanks!
    I'm looking forward to see a good integration with Wicket.
    Regards,

    Flavio.


    Check this out.


    *yawn* has it been a year already?

    :-)


    :) Time goes by fast when you're having fun.

    There is certainly still stuff that Seam can do to make integration with other frameworks easier. One would be to make a minimal distribution (I'd prefer something that could just run on JSE) with a minimal number of dependencies (there are quite a few currently, including JSF). Updated maven support would be another great thing imho (but I know not everyone agrees).

    I was initially thinking in the wrong direction when looking for Seam integration for Wicket. I was thinking along the lines of how it supports JSF. And that in turn depends a lot on EL in the view layer. Pretty incompatible with Wicket. It turned out that it was better to look at it as a DI library, though this time with support for scopes. And that works pretty nice actually! I'm sure there is potential for a lot more, but we're waiting for Seam to hopefully work on a more minimal distribution someday and/ or a good maven distribution, and for more feedback from both Gavin and the Wicket community. Right now the integration is a proof of concept rather than a well rounded project.
    I'm looking forward to playing with this stuff :-)