On Sep 1, 2010, at 10:09 AM, Justin Lee wrote:
> I've updated the grizzly poms to mark those dependencies as provided, rebuilt glassfish, and run quicklook. All the quicklook tests pass and the dependencies no longer show in extras/embedded/nucleus. I can't test that nucleus itself is functional without it but what tests I've run pass.
>
> On 9/1/10 12:27 PM, Oleksiy Stashok wrote:
>>> yes, reflection is bad but adding dependencies is not much better especially on packages we are *not* allowed to ship in nucleus like the servlet API.
>> Servlet API should be easy (if it's really Grizzly, who pulls it in), cause we shouldn't have direct import dependencies on it.
>>
>>> so let me ask why there is such a dependency from EmbeddedHttp class. what is this class anyway ? do we use in v3 ?
>> GrizzlyEmbeddedHttp is part of grizzly config. It checks the domain.xml configuration and builds up the network listener accordingly.
>> So depending on comet-enabled or websockets-enabled attribute in the <http> element - it either adds or not corresponding Filter to the Grizzly chain.
>> This is the place we have dependency on comet and websockets modules.
can't the dependency be reversed ?
meaning, you give the config objects to the websockets and comet modules and they figure out if they need to install anything...
jerome ?
>>
>> One interesting question I have (probably it's me or Justin who has to answer it), how this worked in 3.0.1? Ok, we didn't have websockets there, but comet was on the same place. For sure I suppose we run nucleus tests as part of QL or other testset.
>>
>> WBR,
>> Alexey.
>>
>>>
>>> jerome
>>>
>>> On Sep 1, 2010, at 8:45 AM, Justin Lee wrote:
>>>
>>>> Reflection is a nonstarter. It's a horrible hack that makes project management incredibly fragile. I'd rather have extra deps in nucleus than introduce that kind of "fix" in grizzly.
>>>>
>>>> On 9/1/10 11:36 AM, Oleksiy Stashok wrote:
>>>>> Hi Jerome,
>>>>>
>>>>> we will investigate this.
>>>>> Just wanted to check one thing.
>>>>>
>>>>> The core EmbeddedHttp class, which represents a network listener has hardcoded import for comet and websockets packages.
>>>>> If we will remove comet and websockets modules from the nucleus, won't that lead to NoClassDefFoundError? Should we use reflections or is there better solution you can advice?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>>
>>>>> On Sep 1, 2010, at 7:40 , Jerome Dochez wrote:
>>>>>
>>>>>> Oleksey,Justin
>>>>>>
>>>>>> In 3.1 nucleus distribution, I am seeing 11 grizzly jars while we only had 6 in 3.0.1
>>>>>>
>>>>>> -rw-r--r-- 1 dochez staff 29765 Aug 31 20:35 grizzly-comet.jar
>>>>>> -rw-r--r-- 1 dochez staff 93873 Aug 31 20:35 grizzly-config.jar
>>>>>> -rw-r--r-- 1 dochez staff 243121 Aug 31 20:35 grizzly-framework.jar
>>>>>> -rw-r--r-- 1 dochez staff 49337 Aug 31 20:35 grizzly-http-servlet.jar
>>>>>> -rw-r--r-- 1 dochez staff 175103 Aug 31 20:35 grizzly-http.jar
>>>>>> -rw-r--r-- 1 dochez staff 55385 Aug 31 20:35 grizzly-lzma.jar
>>>>>> -rw-r--r-- 1 dochez staff 19583 Aug 31 20:35 grizzly-portunif.jar
>>>>>> -rw-r--r-- 1 dochez staff 10405 Aug 31 20:35 grizzly-rcm.jar
>>>>>> -rw-r--r-- 1 dochez staff 489476 Aug 31 20:35 grizzly-utils.jar
>>>>>> -rw-r--r-- 1 dochez staff 46078 Aug 31 20:35 grizzly-websockets.jar
>>>>>>
>>>>>> those were added and should not be shipped in nucleus.
>>>>>>
>>>>>> -rw-r--r-- 1 dochez staff 55385 Aug 31 20:35 grizzly-lzma.jar
>>>>>> -rw-r--r-- 1 dochez staff 46078 Aug 31 20:35 grizzly-websockets.jar
>>>>>> -rw-r--r-- 1 dochez staff 49337 Aug 31 20:35 grizzly-http-servlet.jar
>>>>>> -rw-r--r-- 1 dochez staff 29765 Aug 31 20:35 grizzly-comet.jar
>>>>>>
>>>>>> can you look into this.
>>>>>>
>>>>>> thanks, jerome
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>