>> try {
>> addFilter(new com.sun.grizzly.comet.AsyncFilter());
>> } catch (NoClassDefFoundError e) {
>> }
>> }
>>
>> so we won't have the explicit imports in the class declaration. Need
>> to check if it will work.
>
> I believe it will fail on the IBM JDK and it will be hard to find and
> fix when doing e.g. an AIX port.
>
> The IBM JDK will try to resolve "com.sun.grizzly.comet.AsyncFilter"
> when
> your class is loaded (instead of when the if block is actually entered
> as the Sun JDK does). There is a workaround by setting a VM option
> (-Xverify:none) but that would affect your whole JVM, not just this
> class.
Yeah, it's what I was afraid of.
Thank you for the info.
WBR,
Alexey.
>
> Regards,
> Dies
>
>
>> -----Original Message-----
>> From: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
>> Sent: Thursday, 2 September 2010 03:06
>> To: dev_at_glassfish.dev.java.net
>> Subject: Re: 10 grizzly jars in nucleus
>>
>>>> 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...
>> I'll probably try some ugly solution like:
>>
>> if (isCometEnabled) {
>> try {
>> addFilter(new com.sun.grizzly.comet.AsyncFilter());
>> } catch (NoClassDefFoundError e) {
>> }
>> }
>>
>> so we won't have the explicit imports in the class declaration. Need
>> to check if it will work.
>>
>> WBR,
>> Alexey.
>>
>>>
>>>>>
>>>>> 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
>>>>
>>>
>>>
>>>
> ---------------------------------------------------------------------
>>> 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
>