(This is the third try to post this messsage as it seems that the previous messages didn't go through...) Hello, In order to help people use Seam on WebSphere, I have currently ready to be committed, the artifacts to build a functional "booking" application under WebSphere v7 The artifacts are grouped under a "websphere7-resources" directory that groups the files tailored for WebSphere v7 and there is a "build-websphere7.xml" file to build the ear file.

With this, this it is just a matter of running the build file, declaring a connection pool in WebSphere and deploying the ear file on WebSphere to get the "booking" application running on WebSphere v7 I plan also to review the section of the doc related to the usage of seam on WebSphere v7 as what is in there is over-complicated and there are may errors (and many jar are out opf date with seam 2.2 ...), and also to include a section on how to configuire JNDI name resolution for Seam with WebSphere v7 as it seems that many people have problems with this

Q: - is the "booking" sample the right example to proposes this kind of thing?

- should it be better if I move my files from the "booking" sample to the "je55/booking" sampleand make this work there? what is the difference between both? - is the structured proposed ok? ie the websphere7-resources directory that contains the files specific to was and the build-webssphere7.xml (very similar to what is done done in the "jpa" sample app)

I could commit this as soon as v2.2GA is out.. Thanks Denis _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Hi Denis, Great work :-) On 27 Jul 2009, at 09:15, Marek Novotny wrote: > denis.forveille(a)gmail.com píše v Ne 26. 07. 2009 v 22:12 -0400: > >> (This is the third try to post this messsage as it seems that the >> previous messages didn't go through...) >> >> Hello, >> >> In order to help people use Seam on WebSphere, I have currently ready to >> be committed, the artifacts to build a functional "booking" application >> under WebSphere v7 >> > I think the correct place to put this work is for the jee5/booking example, not the plain booking example. The jee5 example is a port of the booking example to any jee5 server. You'll also find we have WLS, OC4J etc, GFv2 support there. The artifacts are grouped under a "websphere7-resources" directory that >> groups the files tailored for WebSphere v7 and there is a >> "build-websphere7.xml" file to build the ear file. >> > > thanks for that, regarding file and directory names, it should be the > same as we have in jpa example -> directory resources-websphere7. build > file name is fine. > The correct approach with the jee5/booking example is not to have extra resource directories or build scripts, but to add in any changes needed as comments, and describe the process in the readme. The aim of this is to show how to make an app work on each app server, for people to follow with their own application.

>> With this, this it is just a matter of running the build file, declaring >> a connection pool in WebSphere and deploying the ear file on WebSphere >> to get the "booking" application running on WebSphere v7 >> >> I plan also to review the section of the doc related to the usage of >> seam on WebSphere v7 as what is in there is over-complicated and there >> are may errors (and many jar are out opf date with seam 2.2 ...), and >> also to include a section on how to configuire JNDI name resolution for >> Seam with WebSphere v7 as it seems that many people have problems with >> this >> > Agree, one notice, the refdoc for WAS was last updated for version > 2.1.2.CR1. > >> >> Q: >> - is the "booking" sample the right example to proposes this kind of >> thing? >> > Originally booking example in jee5 directory was for interoperability > with Glassfish, WAS, Weblogic AS etc. Seam is now deployed into JBoss AS > 5, which is JEE5 certified, so there is a question if it is still > required to have both jee5/booking and booking examples in distribution. > > Pete and Dan, what do you think? > Yes, let's stick with this for Seam 2.2. > - should it be better if I move my files from the "booking" sample to >> the "je55/booking" sampleand make this work there? what is the >> difference between both? >> > Yes, as above, use jee5/booking. The booking example is designed to run ootb with no changes on JBoss 5 and Tomcat 6 / embedded - lets keep the example simple, for people getting started. - is the structured proposed ok? ie the websphere7-resources directory >> that contains the files specific to was and the build-webssphere7.xml >> (very similar to what is done done in the "jpa" sample app) >> > As I wrote above, please synchronize the structure with jpa example. > No, use the pattern i describe above for jee5 :-) >> I could commit this as soon as v2.2GA is out.. >> >> Thanks >> Denis >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > -- > Marek Novotny > -- > JBoss Seam Product Lead > > Red Hat Czech s.r.o. > Purkynova 99 > 612 45 Brno > > Email: mnovotny(a)redhat.com > Office phone: +420 532 294 287, ext. 82-62 087 > mobile: +420 608 509 230 > > ------------------------------------------------------ > Looking to carve out IT costs? > www.europe.redhat.com/promo/carveoutcosts/ > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev >

On 27 Jul 2009, at 15:34, Denis Forveille wrote: I understand the concept, but it is quite confusing for the end user: > - There is a "booking" sample that is dedicated to JBoss. Fine. I will > not change/commit anything there. (The readme shoud state that this sample > is taylored for JBoss and if the user as another AS it should look at the > je55/booking sample instead > Agreed, can you add this?

- there is a jee5/booking sample which is supposed to be AS "agnostic", > but in fact it's not > (eg. the build process included specific JBoss libs, > Like?

there are specific lines for OC4J at various places etc..) > Sure, if you look at the readme, you'll see that it tells you to uncomment certain lines to add dependencies needed by other app servers. At the end of the day, no app server can run an app "unmodified".

- the jpa sample took another approach, ie a resource-per-AS directoy + > abuild file per AS... > > On your advice, I could describe what to do to get the > booking/"agnostic-like" app to build and run on WAS, but IMHO as an end user > discovering seam, it is much easier and faster to run a script that builds > the ear file ready-to-be deployed and then inspect what's in the ear to > mimic/adapt their own projects. > Yes, I personally prefer this approach. What do others think?

If not, i would have to describe the content of two files for the user to > create by hand (copy/paste from the PDF which is tedious and error prone) > and to describe the changes in half a dozen files the user haas to change by > hand (build.xml, persistence.xml etc, component.xml, web.xml etc...) and > also that the content of some files is not optimal for WAS (eg the ejb-ref > in ejb-jar.xml is not necessary for WAS depending on how you configure > JNDI for seam etc.., nor the ones in web.xml etc....-or i could just say > "remove those lines-). The procedure will be a list of "add this line to > that file", "remove those set of lines from those files" etc... > Well, I would suggest including instructions for getting it working with minimal changes in the readme. You can add a comment to the specifc file like <!-- Not required in WAS 7 -->, and write in the ref guide that you don't need these (but they don't hurt) etc.

> Also should I put the WAS specific lines in the files themself (has it has > been partially done for OC4J and GF) ? in this case the todo list would be > something like : "uncomment those lines" instead of "add those lines" but we > will still have the "remove those lines" tasks.. > Exactly, that is the scheme. > As a compromise, maybe we could have a specific build.xml file per AS > (that's includes all the required lib per AS) and a place to put artifact > (files specific for an AS) that the end-user could copy itself by hand at > the right place before building...but that is very close to have a full > resource-websphere7 + build-websphere7.xml files... > Right, if we change, IMO it should be to the jpa scheme. > Another point, the je55/booking/build.xml is not up to date (missing slf4j > and still includes cglib, asm etc..) and the content of the META-INF > directory should be split in two: the thing that goes at build time in the > ear file and the files that goes into the ejb-jpa.jar file. > Ok, can you update this?

On 27 Jul 2009, at 17:57, Denis Forveille wrote: (eg. the build process included specific JBoss libs, > > Like? > > jboss-common-core.jar and concurrent.jar > IIRC these are Hibernate dependencies... Well, I would suggest including instructions for getting it working with > minimal changes in the readme. You can add a comment to the specifc file > like <!-- Not required in WAS 7 -->, and write in the ref guide that you > don't need these (but they don't hurt) etc. > > But as this sample is likely the application people start with, IMHO it > would be better to have an application that shows the "best way to run Seam > on your AS". > eg, in the doc I will describe three ways to configure the application to > let Seam smoothy find the beans in the JNDI WAS namespace. If I give > instructions to modify the sample app "with minimal changes" (see your > comment below) to run on WAS, it will use the worse way (IMO) to do it (ie > maintain the ejb3 ref in the config files) and people will build their apps > on this without any real sample app that will use the best approach. > If you are OK with it, for WAS, I will give instructions to build the > booking application and get the "best way to run Seam on WAS v7", this will > include a few extra steps (like remove the ejb-ref etc..) > I would suggest describing both the minimal and recommended. In other words "If you are getting started with WAS you can do XYZ" "Now that you've got the app up and running, you may be wondering if you can simplify the configuration. You can by doing PQRST (remove ejb-refs etc.)" So, we get people up and running with minimum deviation from the EE spec - the most portable app. Then we show how to tweak for WAS.

> On your advice, I could describe what to do to get the > booking/"agnostic-like" app to build and run on WAS, but IMHO as an > end user discovering seam, it is much easier and faster to run a > script that builds the ear file ready-to-be deployed and then > inspect what's in the ear to mimic/adapt their own projects. Yes, I personally prefer this approach. What do others think?

2009/7/28 Dan Allen <dan.j.allen(a)gmail.com&gt; > On your advice, I could describe what to do to get the > booking/"agnostic-like" app to build and run on WAS, but IMHO as an > end user discovering seam, it is much easier and faster to run a > script that builds the ear file ready-to-be deployed and then > inspect what's in the ear to mimic/adapt their own projects. Yes, I personally prefer this approach. What do others think? While I think the instructions are important, because they emphasize the changes that have to be made, I wish there was a build that would automate the modifications so that we lower the barrier to getting hands on. And yes, now that JBoss AS 5 is out, the jee5 app should be the first example any newcomer to Seam tries. Is there a place where we asterisk the default example? If so, we should asterisk the jee5 one. OK.. What I could do as an example for the jee5/booking sample: - commit the build-websphere7.xml file and resource-websphere7 directory like for the jpa sample (with tailored web.xml, persistence.xml, ejb-jar.xml file etc...) AND explain in the doc what to do if you want to do it by hand, starting from the "vanilla" resource/build files to get to the WAS v7 tailored files This could be done also for JBoss5, GFv2 and OC4J as this sample is mainly target for those AS and the bookingsample could then be deprecated...

WDYT? Two other ideas: 1) I would like that the general sample build proc look first for files in the resource-<as specific> dir THEN in the resource genral dir (ie copy the general resource dir in a temp place then override with specific files from theresource-<as specific> dir) . With that, we could only put in the resource-<as specific> dir, files that are really different from the base and not all the files as for now. The end user would directly see whant files have been changes (eg pages.xml, faces-config.xml,application.xml etc....never change )

2) I also would like to get 3 sub dirs in the "resource" folder: "META-IINF" for files that goes in the ear (ie application.xml), WEB- INF for the web module and JPA for file that go into the jpa-ejb jar

I've added this statement to the examples/readme.txt file "If you are just getting started with Seam, it's highly recommended that you study the jee5/booking example first. This example is designed to run unmodified on a Java EE 5-compliant application server. Of course, the real world is never so ideal. Therefore, you'll find modifications that you need to make for various application servers in the example's readme.txt file. These instructions can also be found in the Seam reference documentation." -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan

> 2) I also would like to get 3 sub dirs in the "resource" folder: > "META-IINF" for files that goes in the ear (ie application.xml), WEB- > INF for the web module and JPA for file that go into the jpa-ejb jar > This is a big change, but again, we need to address the entire way we structure examples in Seam 3, and align with JBoss Tools so that our examples work ootb there. This means adopting the JBT structure for projects I think. Again, we need to start a wiki page for this :-)

Does this mean you are using the maven project structure from now on? Or are you sticking with WebContent etc.?

Agreed. But I think this is a WTP default, not a JBT default. Max?

WTP uses a standard Eclipse preference to set the default web content folder. However, there isn't any UI to change the preference. If the user changes it, WTP won't save a new value. We can change the preference either by adding a preference page or by saving the value when the user has finished the Seam Web Project wizard.

As to JBDS, we can change the default value when starting a new workspace. This can also be done in JBoss Tools, but would break Eclipse fair play rule.

> As to JBDS, we can change the default value when starting a new > workspace. This can also be done in JBoss Tools, but would break > Eclipse fair play rule. > > > I don't understand why this was never a preference in Eclipse already. > It seems to me Eclipse is being too lame to be treated fairly in this > case. You can change just about ever other aspect of a project. Maybe > I should voice my concern on an issue report. Is there an open issue > in Eclipse to control this setting? > > I haven't found any, but the issue can be easily fixed.

On Mon, Aug 10, 2009 at 8:01 AM, Max Rydahl Andersen <max.andersen(a)redhat.com <mailto:max.andersen@redhat.com>> wrote: >> As to JBDS, we can change the default value when starting a new >> workspace. This can also be done in JBoss Tools, but would break >> Eclipse fair play rule. >> >> >> I don't understand why this was never a preference in Eclipse already. >> It seems to me Eclipse is being too lame to be treated fairly in this >> case. You can change just about ever other aspect of a project. Maybe >> I should voice my concern on an issue report. Is there an open issue >> in Eclipse to control this setting? >> >> > I haven't found any, but the issue can be easily fixed. > You are saying Eclipse WTP actually reads the default from a preference but it is not exposed in the preference pages ? Then sure, lets open that up and even better submit a patch to Eclipse WTP so it becomes available in the December release of WTP 3.2 which we will need for other reasons anyway ;) Here's the closes bug report I found: https://bugs.eclipse.org/bugs/show_bug.cgi?id=156417 I added my piece of mind to the issue report.

Can't the JBT wizard simply offer a better default when the project

Here's the closes bug report I found: https://bugs.eclipse.org/bugs/show_bug.cgi?id=156417 I added my piece of mind to the issue report. I think that you are referring to the wrong bug. The user wanted to change the web content folder in the existing web project using a project property. That's really all I could find. Do you think we should just create a new issue?

> Can't the JBT wizard simply offer a better default when the project is being setup? I thought you wanted to configure a default web content folder for new projects. Right, that's what I mean. BTW, if m2eclipse imports an existing web project, it will set the web content folder according to maven settings. If you don't set warSourceDirectory to maven-war-plugin, the web content folder will be /src/main/webapp (the maven default web folder). Yep. But I figure without Maven 2, it should still offer a way to configure the location, as we have already mentioned elsewhere in the discussion.

Does this mean you are using the maven project structure from now on? Or are you sticking with WebContent etc.? Please let us use the damn Maven 2 standard and end this battle. IMHO, "WebContent" is the most ridiculous folder name when put next to "src". It's almost as bad as "My Documents" from Windows. We might as well just call it "My Web Files".

On Mon, Aug 10, 2009 at 7:55 AM, Max Rydahl Andersen <max.andersen(a)redhat.com <mailto:max.andersen@redhat.com>> wrote: Dan Allen wrote: > > > > Does this mean you are using the maven project structure from > now on? > Or are you sticking with WebContent etc.? > > > Please let us use the damn Maven 2 standard and end this battle. > > IMHO, "WebContent" is the most ridiculous folder name when put > next to "src". It's almost as bad as "My Documents" from Windows. > We might as well just call it "My Web Files". I completely agree, but please report it to eclipse WTP please ;) note: it's always been configurable. Just not through the UI. The Maven 2 eclipse:eclipse plugin sets it to src/main/webapp, so clearly it works by tweaking the .settings file.

src/main/webapp is the default web content folder, but it can be configured using warSourceDirectory within maven-war-plugin http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html Right. But what I'm saying is that Eclipse can accept different values via the .settings file, which Maven 2 happens to write to. So from the WTP perspective, it is configurable, but via the project files only ATM. So we seem to agree on the current state. The question is, do we move forward with a new Eclipse issue report? In the meantime, you could add the preferences screen to tied folks over.

> Max, > If you agree, I can add the following functionalities: > - a project property page to change the web content folder of an existing > project > This is what is missing - and I would say this should be submitted to eclipse ASAP :)

Dan Allen wrote: > > > > Does this mean you are using the maven project structure from now on? > Or are you sticking with WebContent etc.? > > > Please let us use the damn Maven 2 standard and end this battle. > > IMHO, "WebContent" is the most ridiculous folder name when put next > to "src". It's almost as bad as "My Documents" from Windows. We might > as well just call it "My Web Files". I completely agree, but please report it to eclipse WTP please ;) note: it's always been configurable.

wrote:

2) I also would like to get 3 sub dirs in the "resource" folder: "META-IINF" for files that goes in the ear (ie application.xml), WEB- INF for the web module and JPA for file that go into the jpa-ejb jar This is a big change, but again, we need to address the entire way we structure examples in Seam 3, and align with JBoss Tools so that our examples work ootb there. This means adopting the JBT structure for projects I think. Again, we need to start a wiki page for this :-) One thing that should help is that we know integrate with m2eclipse allowing you to at least use maven. I still don't know (haven't had time to look into it) how we are going to handle (in any IDE) that there are multiple deployment/configuration descriptors in one project - most non-jbosstools-tools assumes a specific structure (i.e. persistence.xml is in META-INF and not called something else) - but maybe maven's profile feature can be used for it....something to explore at least.

Again, we need to start a wiki page for this :-) > > > One thing that should help is that we know integrate with m2eclipse > allowing you to at least use maven. > > I still don't know (haven't had time to look into it) how we are going to > handle (in any IDE) that there are > multiple deployment/configuration descriptors in one project - most > non-jbosstools-tools assumes > a specific structure (i.e. persistence.xml is in META-INF and not called > something else) - but maybe > maven's profile feature can be used for it....something to explore at > least. > I think Maven 2 profiles are the answer, or at least to cover 90%. A tool should be able to do property replacement between Maven 2 properties and the replacement tokens in the files. I'm not sure if this is m2eclipse's responsibility or JBoss Tools (users really don't need to know the details here). This works because Maven 2 behavior is predictable and well defined. With Ant, it's just wild west which files get filtered and where the tokens come from. And the Seam 2 examples use Ant in the most gnarly way. As for the last 10% (or however many edge cases there are), we can address those on a case-by-case basis in a way that impacts the tooling the least. In the worst case scenario, you have to comment out some code in the source files to support one app server or the other. But I think this is acceptable in small amounts given that once you decide to target an app server, you keep using the same one while developing (so it's not something you have to do over and over). Let's just push profiles as far as they are willing to go. We'll be Maven ninjas by the time the examples are all setup, no doubt. Maven profiles doesn't solve this afaik. It only generates the "right" layout in the deployment location which is an area an IDE ignores. If Maven has support for maintaining an "intermedate" location that the IDE think is the actual source/resource being deployed will work. Again - I need to play more with this, but a few months ago it was still a problem (i.e. the IDE just become a fancy notepad :)

What I don't understand--and please bear with my naivety about Eclipse plugin development--is why we can't offer some sort of "smart" editor that is aware of the properties defined in the pom.xml file and can resolve them when it needs a value (such as the JTA data source name). That is what I would like to do where we can - but will only work for our editors and projects. We don't control all of the IDE - sorry ;) Anyway, the editor is just *one* part of this - then there is the whole set of framework specific models in place, i.e. JSF and JPA provided by WTP has their own little model which expects things to be in a specific place and is not in any way extendable in this area (afaik). btw. jta datasource name is an example of something we don't really need to resolve since it only exists at runtime.... what we want to control is that when you want to do Hibernate queries from the IDE you use a persistence.xml that is configured to run in J2SE; but when deploying it should use the datasource name one - and this is not controllable with a mere property replacement because of how persistence.xml's are structured.

What I don't understand--and please bear with my naivety about Eclipse > plugin development--is why we can't offer some sort of "smart" editor that > is aware of the properties defined in the pom.xml file and can resolve them > when it needs a value (such as the JTA data source name). > > That is what I would like to do where we can - but will only work for our > editors and projects. We don't control all of the IDE - sorry ;) > Anyway, the editor is just *one* part of this - then there is the whole > set of framework specific models in place, i.e. JSF and JPA provided by WTP > has their own little model which > expects things to be in a specific place and is not in any way extendable > in this area (afaik). > > btw. jta datasource name is an example of something we don't really need > to resolve since it only exists at runtime.... > what we want to control is that when you want to do Hibernate queries from > the IDE you use a persistence.xml that is configured to run in J2SE; > but when deploying it should use the datasource name one - and this is not > controllable with a mere property replacement because of how > persistence.xml's are structured. > We'll need to discuss this in real time to make sound progress, likely JBossWorld. But I'll leave one statement/inquiry here. So you are saying that Eclipse basically has no native support for property substitutions of any kind in project files? I just don't see how the Eclipse developers missed this absolutely critical requirement for an IDE. For as long as anyone has been developing Java EE web applications, system administrators have been using all sorts of voodoo magic property replacement to get any deployable build artifact. Variations are just a huge fact of life. The IDE has to be able to deal with that reality and stop living in it's own ideal world that every value in a file is concrete. I'm saying *all* IDE's I know does not have property replacements support - not even intellij. If they have I missed it and would really like to get pointed to an example/docs anything. Please note there are two problems here: property replacement/understanding in editor/model and editors not being too much dependent on location of the file. Putting my problem solving hat back on, the best way I have found to deal with this situation, from many years of having to get the IDE to operate in the real world, is to have an environment switcher. It tears through the project and replaces configuration files intended for one app server with configuration files for another. Then, you can edit them...but of course when you are all done tweaking them (with permanent changes), you have to copy the files back to their source to check them in. Otherwise, the changes are just temporary for your immediate development needs. yes, that is what I've been doing too - or simply not depend on the IDE :) anyway, having such a environment switcher is "more or less" what the maven profile support does (except the destionation is always in the build result, anyone know if that can be changed/customzied?). What would be nice is to (for those locations where it is possible) to do the "inverse operation" by simply comparing the src and destination and just do an intelligent merge ;) Am I missing some obvious way to work? Put Maven completely aside for a moment and just focus on how to deal with different settings for different environment in any Java EE project. How is the problem solved? That is where we need to start when we discuss a solution. The problem is unfortunately normally solved with what I normally refer to as Ant voodoo ;) but yes, this is something better done face-2-face since its solution very much depend on what kind of 'property replacement' and what type of file you do it on.

I've added this statement to the examples/readme.txt file "If you are just getting started with Seam, it's highly recommended that you study the jee5/booking example first. This example is designed to run unmodified on a Java EE 5-compliant application server. Of course, the real world is never so ideal. Therefore, you'll find modifications that you need to make for various application servers in the example's readme.txt file. These instructions can also be found in the Seam reference documentation."