Agree that we need to solve this issue carefully, maybe if possible in the general way, similar to the case of different versions of same server type.
Do we have a issuzilla for this yet?

-Nam

Stepan Herold wrote:

Comments are bellow.

Nam Nguyen wrote:

Stepan Herold wrote:

I wonder, do the web server guys know about this configuration files conflict problem at all? I know it's highly unlikely but isn't there even a tiny little chance of considering to rename it directly in the web server for the next release?

Nam, just to be sure, I guess this is not expected to work in 4.1, does it?

Mukesh, can you confirm my understanding that you have work-around for this name collision with AS (use different name/dir and rename the entry in the war at deploy time).
Stephan:  more in-line...

Other comments inlined...

Nam Nguyen wrote:

Stepan Herold wrote:

Nam Nguyen wrote:

Yeah maybe plugin provided loader might help but not completely solve this problem.  The sun-web.xml files would live in the same directory same name.  So we might have to say a web project once has been targeted to WS could not be retargeted to AS unless its  information in sun-web.xml could be lost.

Let me explain a bit more about the different filename work-around.  WebServer sun-web.xml would live in source as sunws-web.xml.  Build process would ask j2eeserver what is the destination path just like it currently did for conf/sun-ejb.xml.  Similar to the case of META-INF/sun-ejb.xml answer, j2eeserver will answer WEB-INF/sun-web.xml for the case of sunws-web.xml, base on additional attribute of layer.xml file entry.  I don't think it's that ugly.  Of course it does not address the case of plugins for multiple versions of same server type.  But maybe we can also solve this case without requiring plugin to write data loader?  I think we need to try hard enough to avoid the requirement if possible.

I don't know whether I got it right. Provided that I've created a project on app server and then switched the target server to web server, would I have these two files in my sources?

WEB-INF/sun-web.xml - for appserver
WEB-INF/sunws-web.xml - for webserver

If that's so, I really don't like it. I think it would be really confusing and it would bring a whole bunch of problems. Here are some questions that come to my mind

1. Would users understand what is sunws-web.xml good for?

2. Would they understand the relationship between the two?
3. Wouldn't they try to edit sun-web.xml instead of sunws-web.xml?

All good questions, but I think we need to be concerned only about the case of WS experienced users who are too familiar with sun-web.xml file.  Tool tip and online help and solution for 4,  would be useful in this case.

But couldn't be these WS experienced users - possibly NB newbies - confused that there is no sun-web.xml but only some "suspicious" sunws-web.xml (which would happen provided that they have never set app server as a target servet for their project).

4. What would be the editor title of the sunws-web.xml? Would it be sunws-web.xml or sun-web.xml?

How about <server type shortname + module type>, which also solve the sun-ejb-jar + sun-cmp-mapping problem.

5. Wouldn't they wonder why the sun-web.xml in the build differs from the one in the sources and why there is no sunws-web.xml in the build?
...

If our IDE is sucessful, user would rarely need to look into the build/dist.  In rare cases that they have to, the two names are close enough to be intuitive :-).

What about just a simple warning message "Your sun-web.xml cannot be handled by WS server and will be recreated (converted), the old version will be saved as sun-web.xml.backup". This approach would be much simpler and could be used also when switching between different versions of the same server. I guess that this switching scenarion is would not be very commond and therefor it could suffice.

However, if we would like to offer a better support for back and forth target switching, we could name the backup copies like

sun-web.xml.backup_appserver
sun-web.xml.backup_webserv

and when we switch for instance from webserver back to appserver, we can automatically save the current sun-web.xml as sun-web.xml.backup_webserv and replace it with sun-web.xml.backup_appserver.

I think this solution would be much more straightforward, user would understand what's going on and it would be also easier to implement.

This solution assumes mutually exclusive usage b/w AS and WS.   I dont think we want stick with that assumption.  I believe, a system integrator or a application vendor would want to have multiple server platform support.for each application.  This means both sun-web.xml and sunws-web.xml needs to be version controlled at the same time.

You are right that being able to edit sun-web.xml for both app & web server in the same time would be nice, but is it really needed? Is it really such a benefit set against the confusion it would be bind with?

Sorry, I don't have hard data on this.  But the fact that we have both AS and WS, I feel that we really don't want  to lock ourselve out of one of potential use case, esp. when we are in doubt.

I think that having to switch the target server before you can edit the other server config file, in case that both servers share the same file name, is quite expected and is nothing users might blame or hate us for.

I am fine with this behaviour.  But the thing is we want to have them both in VCS.  sun-web.xml and its backup file names are just the similar solution in this regard but even more confusing.

I see, the VCS is really a good and important argument. However, I still don't like this work-around very much. I don't think that we should make any special work-around for sun web & app server only. We should solve this for all servers in the same way, regardless whether the collision is between two different server types (web server vs. app server) or just two different server versions (appserver 8 vs. 9 or tomcat 5.0 vs. 5.5). We will have to solve this later anyway.

Since the consistent behaviour is one of the key issues for a good user experience we should not make any rush decision and designe it properly in a general way.

CC'ing Jirka.

You will have to switch target servers in order to test it on both servers anyway.

It would be useful to know how many people develop for multiple servers really in the same time and would possibly benefit from it.

I personally, from user's point of view, would prefer my solution but I'm sure there will certainly be users who will prefer yours, Nam. I think someone from the HIE should decide what would be best for users. Maybe we should move this discussion to issuezilla and CC J. Kopsa.

Thanks,

Stepan