Re: [jetty-users] Validation Errors after update from 9.0 to 9.2

[Lothar Kimmeringer <job@xxxxxxxxxxxxxx>]

Am 07.05.2015 um 15:40 schrieb Joakim Erdfelt:
> On Thu, May 7, 2015 at 6:15 AM, Lothar Kimmeringer <job@xxxxxxxxxxxxxx <mailto:job@xxxxxxxxxxxxxx>> wrote:
> 
>     I've seen that part in the source of WebDescriptor-class before
>     asking the question since I haven't seen a way to add my own
>     redirections (and I already have these files residing in my
>     installation - just in another directory than javax/servlet/)
> 
> 
> 
> Don't change the directories of the jetty-schema.jar stuff, that's not going to work.

I haven't. The structure I was speaking of was established ten years ago.

>     > So I gotta ask, how are you using jetty?
> 
>     Embedded into an application to provide HTTP-functionalities
>     using the jetty-all.jar and additional jars for servlets and JSP.
>     First version was AFAIR version 4.
> 
> 
> Using jetty-all is a mistake.
> 
> The jetty-all artifact only exists to demonstrate jetty from a purely
> command line role in the jetty documentation.  It is not appropriate
> for anything but the most trivial of applications.

I don't see our application as trivial ;-) But HTTP is just a small
part of it and is basically a small subset of what's possible today
(AS2 is based on HTTP/1 or TLS, same goes for GWT). We give the users
of that application the ability to add their own stuff if necessary.

> Contrary to its name, it does not have all of Jetty. 
> 
> Having all of Jetty in a single aggregate jar is currently impossible
> as there are many competing alternative component implementations that
> cannot co-exist with each other.  The jetty-all aggregate also does not
> (and cannot) merge the various service metadata required by several
> other components. (as having more than 1 service on some metadata is
> not possible).  Some features cannot be enabled if they exist in the
> same jar as the rest of Jetty (due to Xbootclasspath requirements and such).

I see your point. The Jar provides all functionality that is needed
"here", so I'm happy with it.

>     > Or ... can you upgrade the WEB-INF/web.xml to say servlet spec 2.5
>     > at least? (this error will go away)
> 
>     I can do that for the set of config-files that we include with
>     new installations but I try to avoid to be forced to change them
>     with existing ones since they might have been changed by their
>     corresponding users and I don't want to create a "know-it-all"-
>     parser that is able to change these files in all circumstances.
>     I already had this kind of "fun" with the changed syntax of the
>     jetty-configuration-files between Jetty 7 and Jetty 9.0 and -
>     now again - between 9.0 and 9.2
> 
> 
> 
> More changes in the configuration coming in 9.3

I'm not surprised.

> But if you are using embedded, why are you using the XML configuration stuff?
> That's really for the jetty-distribution way of accomplishing things.

Because it's a kind of mixture. The e.g. AS2-Server-Part sets up its
Servlet by calling the correspdonding methods of the Server-instance.
In addition we allow a user of the system to add own stuff (e.g. an
own servlet or restrict access to parts of the webroot) by configuring
it with the configuration XML-files (otherwise I have to invent my own
configuration-syntax to just provide the same functionality that
is already there).

>     The Jar solved my immediate problem but I still would like to know
>     how I can add my own redirections as part of Jetty being embedded
>     that is something more standard than
> 
>     [a really bad hack, horrible to look at]
> 
>     ... which doesn't work in all circumstances.
> 
> 
> You are officially the first person to ever need or want to muck with that.

I'm the first one complaining which isn't necessary the same ;-)
I know that the situation I described is kind of special. A webserver
generally has access to Internet (what else is a webserver for) but
there are reasons for that, e.g. if the server should only be
accessed internally or it runs in the DMZ and the firewall only
allows incoming traffic (which isn't that rare of a situation).

If a user adds his own web-app that might contain configuration-
files with non-standard schemes I will again run into the problem
I described in this thread. So while I don't need above hack right
now (with jetty-schemas.jar provides the standard files) but
"next week" there might be a support-ticket coming up because
a customer can't access his web-app after the update of the server.

So to solve this (at the moment theoretical) problem, I need some
way to tell the XmlParser globally to redirect a particular
resource-request to a local file. The hack was what I was coming
up with but I don't like it, I see that it will fail in some
circumstances and I don't like it. Hence my question if there
is some "official" way I just missed. But I just fear that there
is no "offical" way like there is none to prevent
ServletHandler$Default404Servlet to be added by default as I asked
a month ago and never received an answer about that. The hack I
finally came up with to solve that I don't like, either. But what
has to be done, has to be done ;-)


Best regards,

Lothar Kimmeringer