Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Validation Errors after update from 9.0 to 9.2
On Thu, May 7, 2015 at 6:15 AM, Lothar Kimmeringer <job@xxxxxxxxxxxxxx> wrote:
Am 07.05.2015 um 14:38 schrieb Joakim Erdfelt:
> Yow ... web-app_2_3.dtd
>
> That was part of J2EE 1.3, back in Sept 2001
> <http://en.wikipedia.org/wiki/Java_EE_version_history#J2EE_1.3_.28September_24.2C_2001.29>.

I know. That was the status when the first version of our app
was published ;-)

> Ok, this old of a web dtd isn't tested by our own tests it seems.
> But we do have that dtd in our jetty-schemas.jar <https://github.com/eclipse/jetty.toolchain/blob/master/jetty-schemas/src/main/resources/javax/servlet/resources/web-app_2_3.dtd>
> Which the jetty-webapp.jar and its org.eclipse.jetty.webapp.WebDescriptor.class knows about <https://github.com/eclipse/jetty.project/blob/jetty-9.2.10.v20150310/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebDescriptor.java#L93> and sets up for internal redirect <https://github.com/eclipse/jetty.project/blob/jetty-9.2.10.v20150310/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebDescriptor.java#L145-L147>.

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.

 

> 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.  

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).

The name 'jetty-all' is a historical name from back when it was still possible for all features and components of Jetty to exist in a single jar.  (the march of the Servlet spec, http/2, alpn, websocket, and the various client libraries have made this artifact less and less useful for integrating into a proper project)

JSP is not included in jetty-all.jar anymore (at least not in the way you expect)

Setting up JSP in embedded is especially tricky now that the specs have moved on.
Be careful of Instance types, classloader separation, classloader heirarchy, classloader types, and initializers



 

> If embedded, or maven plugin, or just about anything that isn't the
> jetty-distribution, then what are the dependencies you use?

We're not using Maven so we replace the old jars residing in
lib/jetty by new ones. After that we start our testcases and
check, what's failing. Since all major version changes came
with completely new APIs, we end up with compile-errors most
of the time anyway, so it's expected to be a manual process
and there is no real advantage to use Maven for that.


Then don't use maven, use gradle, or ant+ivy, or buildr, or groovy grape, or sbt, or even leiningen.
Use anything but the manual process, this is important.

 

> 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



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.

 

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

    try{
        WebDescriptor wd = new WebDescriptor(Resource.newResource("")){
            @Override
            public void ensureParser() throws ClassNotFoundException {
                super.ensureParser();
                _parserSingleton.redirectEntity("mywebdtd1.dtd",dtd1);
                _parserSingleton.redirectEntity("mywebdtd2.dtd",dtd1);
                _parserSingleton.redirectEntity("mywebdtd3.dtd",dtd1);
                _parserSingleton.redirectEntity("mywebdtd4.dtd",dtd1);
                _parserSingleton.redirectEntity("mywebdtd5.dtd",dtd1);
            }
        };
        wd.ensureParser();
    }
    catch(Exception e){
        e.printStackTrace();
    }

... which doesn't work in all circumstances.

You are officially the first person to ever need or want to muck with that.
Know that for the WebDescriptor to work, you *NEED* to have the schema content in the same format and directory locations in the classpath as the jetty-schema.jar (yes, even the duplicates in the different directory)
You also need all of the schemas and dtds, don't pick and choose, don't prune, use all of them.

Since you said you are using JSP this is doubly important, as the JSP implementations expect the content in both places (it has its own XML validation setup)

- Joakim

Back to the top