On 12/8/12 3:55 AM, Mark Thomas wrote:
> 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
>> spec.
>>
>> 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
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation