View All Attachments for Bug 58239

This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Attachment #21840
email discussion	text/html	2005-04-22 19:25:06 UTC	8.70 KB	no flags	Details

<html>
<head>
<title>Re: Configuration file name collision: sun-web.xml</title>
<link rel="important stylesheet" href="chrome://messenger/skin/messageBody.css">
</head>
<body>
<table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td><b>Subject: </b>Re: Configuration file name collision: sun-web.xml</td></tr><tr><td><b>Wrom: LEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXC
<div class="moz-text-flowed">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.
<br>Do we have a issuzilla for this yet?
<br>
<br>-Nam
<br>
<br>Stepan Herold wrote:
<br>
<br><blockquote type=cite>Comments are bellow.
<br>
<br>Nam Nguyen wrote:
<br>
<br><blockquote type=cite>Stepan Herold wrote:
<br>
<br><blockquote type=cite>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?
<br>
<br>Nam, just to be sure, I guess this is not expected to work in 4.1, 
does it?
<br></blockquote>
<br>
<br>
<br>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).
<br>Stephan:&nbsp; more in-line...
<br>
<br><blockquote type=cite>
<br>Other comments inlined...
<br>
<br>Nam Nguyen wrote:
<br>
<br><blockquote type=cite>Stepan Herold wrote:
<br>
<br><blockquote type=cite>Nam Nguyen wrote:
<br>
<br><blockquote type=cite>Yeah maybe plugin provided loader might help but not completely 
solve this problem.&nbsp; The sun-web.xml files would live in the same 
directory same name.&nbsp; So we might have to say a web project once 
has been targeted to WS could not be retargeted to AS unless its&nbsp; 
information in sun-web.xml could be lost.
<br>
<br>Let me explain a bit more about the different filename 
work-around.&nbsp; WebServer sun-web.xml would live in source as 
sunws-web.xml.&nbsp; Build process would ask j2eeserver what is the 
destination path just like it currently did for 
conf/sun-ejb.xml.&nbsp; 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.&nbsp; I don't think it's that ugly.&nbsp; Of course it does not 
address the case of plugins for multiple versions of same server 
type.&nbsp; But maybe we can also solve this case without requiring 
plugin to write data loader?&nbsp; I think we need to try hard enough 
to avoid the requirement if possible.
<br>
<br></blockquote>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?
<br>
<br>WEB-INF/sun-web.xml - for appserver
<br>WEB-INF/sunws-web.xml - for webserver
<br>
<br>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
<br>
<br>1. Would users understand what is sunws-web.xml good for?
<br></blockquote>
<br>
<br>
<br>
<br>
<br><blockquote type=cite>2. Would they understand the relationship between the two?
<br>3. Wouldn't they try to edit sun-web.xml instead of sunws-web.xml?
<br></blockquote>
<br>
<br>
<br>
<br>
<br>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.&nbsp; Tool tip and online help and solution for 4,&nbsp; 
would be useful in this case.
<br></blockquote>
<br>
<br>
<br>
<br>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).
<br>
<br><blockquote type=cite>
<br><blockquote type=cite>4. What would be the editor title of the sunws-web.xml? Would it 
be sunws-web.xml or sun-web.xml?
<br></blockquote>
<br>
<br>
<br>
<br>
<br>How about &lt;server type shortname + module type&gt;, which also solve 
the sun-ejb-jar + sun-cmp-mapping problem.
<br>
<br><blockquote type=cite>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?
<br>...
<br></blockquote>
<br>
<br>
<br>
<br>
<br>If our IDE is sucessful, user would rarely need to look into the 
build/dist.&nbsp; In rare cases that they have to, the two names are 
close enough to be intuitive :-).
<br>
<br><blockquote type=cite>
<br>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.
<br>
<br>However, if we would like to offer a better support for back and 
forth target switching, we could name the backup copies like
<br>
<br>sun-web.xml.backup_appserver
<br>sun-web.xml.backup_webserv
<br>
<br>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.
<br>
<br>I think this solution would be much more straightforward, user 
would understand what's going on and it would be also easier to 
implement.
<br></blockquote>
<br>
<br>
<br>
<br>
<br>This solution assumes mutually exclusive usage b/w AS and WS.&nbsp;&nbsp; I 
dont think we want stick with that assumption.&nbsp; I believe, a system 
integrator or a application vendor would want to have multiple 
server platform support.for each application.&nbsp; This means both 
sun-web.xml and sunws-web.xml needs to be version controlled at the 
same time.
<br>
<br></blockquote>
<br>You are right that being able to edit sun-web.xml for both app &amp; 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?
<br>
<br></blockquote>Sorry, I don't have hard data on this.&nbsp; But the fact that we have 
both AS and WS, I feel that we really don't want&nbsp; to lock ourselve 
out of one of potential use case, esp. when we are in doubt.
<br>
<br><blockquote type=cite>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.
<br></blockquote>
<br>
<br>
<br>I am fine with this behaviour.&nbsp; But the thing is we want to have them 
both in VCS.&nbsp; sun-web.xml and its backup file names are just the 
similar solution in this regard but even more confusing.
<br></blockquote>
<br>
<br>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 &amp; 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.
<br>
<br>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.
<br>
<br>CC'ing Jirka.
<br>
<br><blockquote type=cite>
<br><blockquote type=cite>You will have to switch target servers in order to test it on both 
servers anyway.
<br>
<br>It would be useful to know how many people develop for multiple 
servers really in the same time and would possibly benefit from it.
<br>
<br>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.
<br>
<br>Thanks,
<br>
<br>Stepan
<br></blockquote>
<br>
<br>
<br>
<br></blockquote></blockquote>
<br>
<br></div></body>
</html>