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? Also are there people that depend on the
renamed com.sun.grizzly.* packages? If not I don't see a problem with
just renaming them back to the old package names.
- 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