>>>>>>> On Tue, 1 Sep 2015 19:19:45 +0100, Mark Thomas <markt_at_apache.org> said:
MT> As I have said previously on this thread, web applications are meant
MT> to be independent of the context path at which they are
MT> deployed. Anything that encourages web application developers to
MT> think that they can code to a specific context path is a bad idea.
On 01/09/2015 21:40, Edward Burns wrote:
EB> May I paraphrase the spirit of your position as "don't make it any
EB> easier than absolutely necessary to do bad things."
>>>>> On Wed, 2 Sep 2015 08:22:26 +0100, Mark Thomas <markt_at_apache.org> said:
MT> No, that is not the spirit of my position. That is a secondary
MT> concern.
Thanks for correcting my misunderstanding.
MT> The spirit of my position is a combination of "Web applications should
MT> be independent of the context path at which they are deployed" and
MT> "deployment is not a developer concern".
I'm all for separation of concerns, but this position seems to run
counter to the spirit of devops.
SD> If tomcat required every deployment to explicitly have its context
SD> path specified I could understand your concern, but it
SD> doesn't. Instead it defaults to the name of the archive, so your
SD> default context path is already not independent from the application
SD> packaging.
SD> In some ways is very inconvenient, instead of leaving versions in
SD> filenames so it is immediately obvious what is deployed
SD> (foo-1.2.1.Final.war) developers simply follow the path of least
SD> resistance and rename the archive (foo.war).
/me raises hand.
>>>>> On Wed, 2 Sep 2015 11:24:21 +0100, Mark Thomas <markt_at_apache.org> said:
MT> I take the point that there is a dependency from the file name to
MT> the context path in the simple deployment case but it does not
MT> require the WAR to be unpacked, web.xml to be edited and the WAR to
MT> be re-packed.
The same argument applies to using annotations to describe configuration
information, but in that case you have the additional step of needing to
recompile some classes to affect the edited change. For example
@WebServlet(urlPatterns = {"/sendFile/*", "/uploadFile/*"})
public class MyServlet implements Servlet ...
SD> Also your assertion that 'deployment is not a developer concern' is
SD> not true for all organisations, especially not for any that have
SD> adopted devops principals.
MT> In the JavaEE spec, component development, application packaging and
MT> application deployment are clearly defined, separate roles. I think
MT> that logical separation should be retained (it encourages re-use of
MT> components) even for organisations that are going down the devops
MT> route.
Ahh, that old saw. I've tried to defend that separation of roles when
talking about EE at conferences and many times been heckled. [1] It's
not a bad idea but in practice the roles tend to be performed by one
person.
SD> At the end of the day this is a default, it can be changed, and it
SD> is a lot more flexible that the current default of renaming the
SD> archive.
EB> While I agree with the spirit of your position, in this case I think
EB> that spirit is trumped by several factors, in decreasing order of
EB> importance.
EB> 1. many containers already offer this in a proprietary fashion
MT> Many containers provide an in WAR method to define a preferred context
MT> path that can be overridden during deployment? References please.
>> On Wed, Sep 2, 2015 at 12:24 PM, Mark Thomas <markt_at_apache.org> wrote:
MT> I'm aware of application.xml for EAR files. Pointers to the docs for
MT> other containers would be appreciated since I don't know them at all.
On 02/09/2015 13:01, arjan tijms wrote:
AT> Just a couple of quick ones that weren't mentioned yet:
[...super useful list of containers and how they support the feature
deleted...]
>>>>> On Wed, 2 Sep 2015 14:54:06 +0100, Mark Thomas <markt_at_apache.org> said:
MT> - None of the docs speak to how conflicts are handled if two WARs
MT> specify the same path. If this feature is added to web.xml then the
MT> specification needs to address this so the behaviour is consistent
MT> across containers.
This is essential to clarify when specifying the feature. I'm very glad
you brought this up.
EB> 2. it sure would be convenient to offer it as a standard
MT> Convenient to who? For what use cases?
For cases when the developer and the deployer are the same person. It's
not hard to imagine a scenario where the deployment descriptors are
baked together at build time, including a parameterized context-root.
MT> The testing use case is the best argument made so far and I'm not
MT> convinced by that.
EB> 3. we can put it at the bottom of a priority list, allowing the
EB> preservation of out-of-webapp context-root specification
EB> 4. we can name the XML element sufficiently obviously to make it clear
EB> the priority is below other ways of specifying the context-root.
SWC> Yes, we should allow the container to override the context root
SWC> configuration. We can discuss more on the XML element name once we
SWC> agree to have this feature.
MT> Then as I stated above, Tomcat will *always* override whatever is set
MT> here - effectively ignoring it. I have no wish to deal with the
MT> inevitable conflicts that will result when multiple applications all
MT> want to be deployed with a context path of "".
EB> This is a good point. What do you do in Tomcat if multiple apps are
EB> attempted to be deployed with the same context root, even when it is ""?
MT> It is only possible to do this in Tomcat if the deprecated / strongly
MT> discouraged method of defining web applications in the main
MT> configuration file is used (which is bad because you have to restart
MT> Tomcat to make any changes). I'd need to look at the code to see what
MT> would happen. I think the second and subsequent apps with the same path
MT> will fail to start but it is possible that the entire container will
MT> fail to start.
MT> If using Tomcat's documented deployment approaches it simply isn't
MT> possible for a conflict to occur.
I'll leave it to Shing-wai to make the final call on this, since he
brought it up, but I believe we have discussed this fully enough and
have established a consensus that the feature is worthwhile to
standardize.
Some very important questions remain.
1. What precisely must be said in the specification about conflicts?
Is it possible to skirt any ordering related issues? Is it safe to
take a "first one wins" approach?
2. What precisely is the XML element name?
I favor a long and descriptive name conveying this is a default of
last resort.
Anything else?
Thanks,
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 44 Business days til JavaOne 2015
| 59 Business days til DOAG 2015
[1] http://presentationpatterns.com/glossary/#hecklers