Skip to main content

[jsr356-experts] Two AppConfig options for Server deployment

  • From: Danny Coward < >
  • To:
  • Cc: Mark Thomas < >
  • Subject: [jsr356-experts] Two AppConfig options for Server deployment
  • Date: Mon, 10 Dec 2012 16:56:36 -0800

On 12/8/12 3:55 AM, Mark Thomas wrote:
" type="cite">
On 07/12/2012 23:25, Danny Coward wrote:
Thanks Mark.

Let me see if I can turn what we have concluded into a proposal for our

We define an ApplicationConfig type in the API that returns, on demand,
a list of endpoints that must be deployed. Web Socket developers may
include ApplicationConfigImpls in the WAR file (including in sub-JAR
files). The websocket implementation must deploy the union of all the
endpoints returns by all the ApplicationConfigImpls.

If no ApplicationConfig's are present in the WAR file, the websocket
implementation must deploy all the endpoints in the WAR file that are
the result of the SCI scan.

Then developers can:-

deploy all the endpoints in a WAR file just by including the code for
them, [no config/nothing excluded from the scan]
deploy precisely which endpoints in a WAR file we want by providing one
or more ApplicationConfigImpls
Limit the scanning performed by the SCI by excluding contained JARs from
the SCI scan

Additionally, I think this means the ApplicationConfigImpls themselves
cannot be discovered by scanning, and we will need to define a
servlet-context parameter to be able to make them discoverable by the
web socket implementation.
I don't think we'll need that. If scanning is disabled completely, there
will be no need for implementations of ApplicationConfig. I think it is
reasonable to say if you want to use scanning and filter the results
then your ApplicationConfig has to be in a JAR that will be scanned.
OK I think I see what you are saying: your ApplicationConfig is filtering the results of the scan of the JAR file its in, and it is itself found by the container as a result of a scan.

So if there is no scan, it doesn't need to be called, because its function is to filter the results of a scan. So it doesn't need to be discovered itself when there is no scan. So there doesn't need to be a mechanism for the container to find this kind of ApplicationConfig in a JAR if there is no scan.

The ApplicationConfig I was thinking of was always found by the container, and always returns a list of endpoints to be deployed whether or not a scan of the JAR it is in takes place. And because it always needs to be found by the container, it cannot rely on being found by a scan, because there may not be a scan to find it.

Let's call the first kind an ApplicationConfigFilter and the second an ApplicationConfigGenerator just so its clear :)

I think either way, its reasonable to put a higher configuration burden on developers creating massive WAR files. And we should have a very low burden on developers creating simple WAR files. Either way, developers can turn off scanning. And can get precise control over what gets deployed too. Both modes meet the requirements we had for this. Further comparisons:-

Both ways, the simple 'deploy everything in my WAR' case is simple: no need for any ApplicationConfigXXX class.

The ApplicationConfigFilter doesn't need the extra servlet context initialization parameter :)

The ApplicationConfigGenerator works even if all the scanning is turned off :)

The ApplicationConfigFilter may be less optimal performance-wise with big JARs when you only want a couple of the endpoints in it (you have to do the scan).

The ApplicationConfigFilter idea is a bit simpler in that it is an adaptation of the existing servlet scan mechanism. The ApplicationConfigGenerater is layering another idea on top, even if it is close to what JAX-RS does.

I think I'm ok with the ApplicationConfigFilter one. If we need a way to pick it up when there is no scan, we could ways define a way to do that in a future release.

If I hear no more on this, I'll write that one up for the spec.

- Danny

" type="cite">

Danny Coward
Java EE
Oracle Corporation

[jsr356-experts] from Rajiv: Re: Server deployment

Danny Coward 12/07/2012

[jsr356-experts] Re: from Rajiv: Re: Server deployment

Mark Thomas 12/07/2012

[jsr356-experts] Re: from Rajiv: Re: Server deployment

Danny Coward 12/07/2012

[jsr356-experts] Re: from Rajiv: Re: Server deployment

Mark Thomas 12/08/2012

[jsr356-experts] Two AppConfig options for Server deployment

Danny Coward 12/11/2012

Message not available

Message not available

[jsr356-experts] Re: from Rajiv: Re: Server deployment

Mark Thomas 12/08/2012
Please Confirm