Define core deployment about jetty.project HOT 8 OPEN

if needed we can create our own maven packaging type (and plugin) to help users.

Sure, but my point is that we don't need to, as there already exist one that is widespread and supported by IDEs (ours won't be) and tools.

from jetty.project.

One idea is to re-use the *.war format, with no WEB-INF/web.xml but a WEB-INF/jetty-web.xml.

We already support WEB-INF/jetty-web.xml for eeN deployments, so we should be able to reuse all the code.

This solution has the benefit that people can develop webapps using the IDE, the m-war-p, without having to resort to special build configurations (for example, using the m-dependency-p to figure out all the transitive dependencies that must go into lib).

It would also benefit of the fact that WEB-INF is protected from remote access, while it is not clear (or currently strongly defined) for foo-webapp.d.

from jetty.project.

The minimal requirements for deploying a core application is just a context.xml file. It is entirely plausible for such an app to take all it's classes from the containers classpath, maybe even only using utility handlers, or perhaps some application code dropped into $jetty.home/lib.
If fact your example is kind of wrong as you should not need to provide either jetty-util nor jslf4j-api jars to a core application. We do not hide any "server" jars from a core application.

I think we should look at an example of creating and deploying a core application with our module system, which already has the ability to move jars into lib, config into etc (or a .d) and to deploy an xml in webapps. I think one of the main advantages of a core application is that it blurs the line between container and application, so it could be thought of as a server component.

However, I agree that is not the only way that users might look at a core application and having a single file deployable is also a good idea. But I don't think we should try to invent our own single file deployment format... but I'm not opposed to reusing the war format (even if it is not very good for purpose). I'm not sure how much code reuse we can achieve, as a core app will be based on a ContextHandler not a WebAppContext, so it will not have the Configuration mechanism used to configure an EE webapp. That is not necessarily a bad thing, as the EE webapp deployment stuff is already insanely complex with programmatic, annotated, descriptor, convention based configuration from many generations of specification with a smear of CDI influence on top. Adding more conditions to that code is probably not a great idea - it needs to stay focused on meeting the spec. To rewrite some code that will use the contents of a core-war as the resourceBase and protect the WEB-INF subdirectory is not that difficult. We probably would want to extract some common code for unpacking (but again that is already so much more complex than you'd think).

from jetty.project.

The minimal requirements for deploying a core application is just a context.xml file. It is entirely plausible for such an app to take all it's classes from the containers classpath, maybe even only using utility handlers, or perhaps some application code dropped into $jetty.home/lib.

Yes, but my point is that developers would rather have a clear path of what to do.
The suggestion to use JETTY_HOME/lib kinda goes against our JETTY_BASE concept, so it works, but not ideal.
Sure we can document to use the ext Jetty module, but that would be accessible to all webapps, which perhaps it's not ideal.

If fact your example is kind of wrong as you should not need to provide either jetty-util nor jslf4j-api jars to a core application. We do not hide any "server" jars from a core application.

Fair enough, mine was an example.

think one of the main advantages of a core application is that it blurs the line between container and application, so it could be thought of as a server component.

But there is also the case where I just want to deploy a better integrated Jetty webapp as if it was a normal webapp.

For example, CometD 8 has now a CometDHandler, so the deployment of such CometD webapp would be:

$JETTY_BASE/webapps
├── cometd.xml
└── cometd.d
       ├── classes
       │   └── org
       │       └── acme
       │           └── cometd
       │               └── MyCometDService.class
       └── lib
           ├── cometd-java-server-http-jetty-8.0.2.jar
           ├── ...
           └── jetty-util-ajax-12.0.10.jar

In particular:

• Need to have all the CometD jar dependencies, but only for this webapp, in cometd.d/lib.
• I can reuse the Jetty server dependencies exposed in the server class-path, provided that they are exposed to webapps, but for example I doubt jetty-util-ajax.jar is exposed by the server, so likely needs to be in cometd.d/lib.
• cometd.xml contains the declaration for CometDHandler (from CometD), and possibly other Jetty utility handlers (from the server class-path).

I would say that for a non-trivial Jetty core webapp, we need <app>.d/classes and <app>.d/lib in almost all cases, plus app.xml.

With a *.war format it would be:

$JETTY_BASE/webapps
└── cometd.war
       ├── index.html
       ├── cometd.js
       └── WEB-INF
           ├── jetty-web.xml
           ├── classes
           │   └── org
           │       └── acme
           │           └── cometd
           │               └── MyCometDService.class
           └── lib
               ├── cometd-java-server-http-jetty-8.0.2.jar
               ├── ...
               └── jetty-util-ajax-12.0.10.jar

The root of the *.war would contain the CometD JavaScript files to serve to clients, as well as HTML, CSS, etc.

With this, we would not need the <app>.d (we may have it, but it would not be mandatory like it is now, as the *.war is self-contained), and reuse a well known deployment format that would be familiar to developers.

from jetty.project.

One idea is to re-use the *.war format, with no WEB-INF/web.xml but a WEB-INF/jetty-web.xml.

We already support WEB-INF/jetty-web.xml for eeN deployments, so we should be able to reuse all the code.
It would be a matter of copying the code up into jetty-core somewhere as reading of WEB-INF/jetty-web.xml is read by the JettyWebXmlConfiguration class, and Configuration classes are not part of jetty-core.

This solution has the benefit that people can develop webapps using the IDE, the m-war-p, without having to resort to special build configurations (for example, using the m-dependency-p to figure out all the transitive dependencies that must go into lib).

It would also benefit of the fact that WEB-INF is protected from remote access, while it is not clear (or currently strongly defined) for foo-webapp.d.

Again, IIRC WEB-INF is not protected in jetty-core, but by the eeX specific webapp modules.

I'm not sure I like reusing WEB-INF directory for this purpose. We could use META-INF instead as maven already supports putting stuff in there? In fact, the jetty-osgi code already has a series of extra headers defined for MANIFEST.MF that allows it to deploy a plain .jar file that contains classes, lib ,context.xml and static content. Maybe we could look at that type of solution?

from jetty.project.

@janbartel it would be complicated to set up for users.
Right now with the m-war-p everything is automatic with almost zero POM configuration.

Rebuiliding exactly the same structure under META-INF would be a lot more POM configuration with possible errors, etc. for exactly the same structure, but now you have to use also the m-dependency-p, the m-jar-p, etc.

from jetty.project.

if needed we can create our own maven packaging type (and plugin) to help users.
so the user setup would be as simple as adding a line such

<packaging>jetty-core-or-whatever-name-we-prefer</packaging>

from jetty.project.

I'm not sure I like reusing WEB-INF directory for this purpose. We could use META-INF instead as maven already supports putting stuff in there? In fact, the jetty-osgi code already has a series of extra headers defined for MANIFEST.MF that allows it to deploy a plain .jar file that contains classes, lib ,context.xml and static content. Maybe we could look at that type of solution?

I think we should protect both WEB-INF and META-INF in a core single file deployment, not least because I can imagine a real war being accidentally deployed as core and we should not expose its web.xml and other WEB-INF content. I don't mind this as it is convention over configuration.

I also think that if OSGi has a single file format that we should look at supporting that as well... maybe even both at the same time.

from jetty.project.