Salut,
Rajiv Mordani wrote:
>
>
> Jeanfrancois Arcand wrote:
>>
>> Salut,
>>
>> Rajiv Mordani wrote:
>>> Proxying would lead to generating proxies for a lot of classes and
>>> maintaining can become a problem. Is there any reason for not
>>> renaming the classes back to the original org.apache.* packages? What
>>> is the motivation for the rename?
>>
>> Because it will breaks 75% of Grizzly based application.
>
> These applications depend on these classes directly?
Yes, they depend on com.sun.grizzly.tcp (previoulsy org.apache.coyote)
Or is it more that
> the grizzly classes that are exposed to developers depend on these?
All http extension/application uses those classes.
>
>>
>>
>> Also are there people that depend on the
>>> renamed com.sun.grizzly.* packages?
>>
>> Yes. Many many many :-)
>
> Sorry wrong question - are there people that depend on the renamed
> org.apache.* packages in Grizzly?
No, because we renamed at the very beginning on Grizzly (when we went
standalone). Hence org.apache.* classes never showed up in Grizzly.
If so should they be is the question?
>
>>
>>
>> If not I don't see a problem with
>>> just renaming them back to the old package names.
>>
>> I think renaming just to support mod_jk in GlassFish is not a good
>> reason. The easiest way for us (in GlassFish) will be to recompile the
>> mod_jk classes to use the com.sun.grizzly.* mod_jk is just ~15 classes.
>
> Well but that would mean that people would have to use our version of
> mod_jk as opposed to the ones available from either apache or part of
> standard linux distros.
It is the .so that ship with linux IIRC. The java side still need to be
added (unless you grab it from Tomcat).
Also it would mean maintaining that codebase as
> well. Not a good idea.
Well, we already forked Tomcat :-) jk has been there at the beginning,
but we removed it during 8.2 -> 9.0 for code coverage reason. So I don't
think maintaining JK in our forked Tomcat will increase our workload
honestly.
A+
-- Jeanfrancois
>
> - Rajiv
>
>>
>> Anyway, still looking for a solution that will *not* impact this
>> community :-)
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>>
>>> - Rajiv
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> Igor Minar wrote:
>>>>> just a thought: how about creating proxies that just inherit from
>>>>> the original classes (and by doing so delegating everything to the
>>>>> original classes)?
>>>>
>>>> yes, that sound much better than renaming all the classes to
>>>> accomodate GlassFish. Actually I was almost ready to send an email
>>>> saying this is not a good idea at all.
>>>>
>>>> I will explore the proxy :-)
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>>
>>>>> /i
>>>>>
>>>>> On Aug 26, 2008, at 10:21 AM, Jeanfrancois Arcand wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> charlie hunt wrote:
>>>>>>> Would it help to rename them to;
>>>>>>> com.sun.grizzly.org.apache.coyote and
>>>>>>> com.sun.grizzly.org.apache.tomcat.util ?
>>>>>>
>>>>>> No because external component like mod_jk requires
>>>>>> org.apache.coyote.*
>>>>>>
>>>>>> I'm trying to find a way to avoid breaking backward
>>>>>> compatibility....quite a challenge :-)
>>>>>>
>>>>>> A+
>>>>>>
>>>>>>
>>>>>>> charlie ...
>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> when we released Grizzly 1.5.x, we took classes from
>>>>>>>> org.apache.coyote/tomcat to com.sun.grizzly. So far it worked
>>>>>>>> well but it gives trouble when we:
>>>>>>>>
>>>>>>>> + want to port fixes from Tomcat directly (always have to find
>>>>>>>> the associated classes)
>>>>>>>> + breaks backward compatibility with GlassFish when Apache
>>>>>>>> mod_jk is used, because mod_jk requires classes with org.apache.* .
>>>>>>>>
>>>>>>>> So I would like to rename those classes back to their original
>>>>>>>> package so the process will be simpler. The issue I'm having is
>>>>>>>> it MAY breaks ***a lot*** of applications that were using packages:
>>>>>>>>
>>>>>>>> com.sun.grizzly.util.*
>>>>>>>>
>>>>>>>> I don't have any better solution unfortunately. If someone has a
>>>>>>>> better idea, please let me know.
>>>>>>>>
>>>>>>>> Thanks!!!
>>>>>>>>
>>>>>>>> -- Jeanfrancois
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>