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.
Also are there people that depend on the
> renamed com.sun.grizzly.* packages?
Yes. Many many many :-)
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.
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
>