You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by Chris Gamache <cg...@gmail.com> on 2011/09/06 19:42:21 UTC
Mina 1 vs Mina 2 version conflicts
I'm having some trouble with Mina 1.1 versus Mina 2.0 ... I'm using a
client-server product (Avis) built using Mina 1.1. Other services I've built
are using Mina 2.0. When the two get together in the same runtime
environment we get a version conflict explosion. Besides rewriting my
components to use Mina 1.1, or Avis to use 2.0, are there any tricks you
know of to segregate the two incompatible versions?
Re: Mina 1 vs Mina 2 version conflicts
Posted by Chris Gamache <cg...@gmail.com>.
I'm listening! Even though this problem is licked for me, if there was a good pattern to use to manage this issue with other libraries I would love to put it in my bag of tricks!
My app is the Mina 2 app. The 3rd party message app is written in Mina 1. There Is an experimental version built on Mina 2, and I packaged that into a library to use in the project. I think the general consensus is that the different versions of the software and the way Java handles loading classes, and the namespace collision between Mina 1 and 2 make the only sane solution to upgrade.
On Oct 1, 2011, at 4:53 AM, David Latorre <dv...@gmail.com> wrote:
> If, for any reason, you couldn't port your APP to Mina 2 (that's the safest
> choice), you can always use different classloaders for the applications
> (similar to the OSGI suggestion).
>
>
>
> 2011/9/6 Chris Gamache <cg...@gmail.com>
>
>> Understood. Unfortunately, it's not my application using Mina 1. There's a
>> nice guide at http://mina.apache.org/changes-between-2x-and-1x.html. I'll
>> see how far I can get porting someone else's application. Any other tips
>> would be most welcome!
>>
>>
>> On Tue, Sep 6, 2011 at 5:26 PM, Emmanuel Lécharny <elecharny@apache.org
>>> wrote:
>>
>>> On 9/6/11 10:56 PM, Chris Gamache wrote:
>>>
>>>> Thanks for the response. The services built on Mina specifically lack
>> that
>>>> kind of heavy framework. My exposure to OSGi is limited. Could you
>> explain
>>>> in more detail how OSGi would help here?
>>>>
>>> It was more or less ironic.
>>>
>>> Sadly, there is no simple way to make MINA 1 and 2 loaded on the same
>> JVM,
>>> unless you make the whole project a bundle. That mean you will have to
>>> integrate an OSGi container in your application. OSGi offers the big
>>> advantage to have a specific class loader which insolate each bundle from
>>> the others, allowing you to use two bundles depending on two different
>> sets
>>> of jars.
>>>
>>> Not that it's a complex task, but frankly, you'd better migrate your MINA
>> 1
>>> application to use MINA 2.
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>>
>>
Re: Mina 1 vs Mina 2 version conflicts
Posted by David Latorre <dv...@gmail.com>.
If, for any reason, you couldn't port your APP to Mina 2 (that's the safest
choice), you can always use different classloaders for the applications
(similar to the OSGI suggestion).
2011/9/6 Chris Gamache <cg...@gmail.com>
> Understood. Unfortunately, it's not my application using Mina 1. There's a
> nice guide at http://mina.apache.org/changes-between-2x-and-1x.html. I'll
> see how far I can get porting someone else's application. Any other tips
> would be most welcome!
>
>
> On Tue, Sep 6, 2011 at 5:26 PM, Emmanuel Lécharny <elecharny@apache.org
> >wrote:
>
> > On 9/6/11 10:56 PM, Chris Gamache wrote:
> >
> >> Thanks for the response. The services built on Mina specifically lack
> that
> >> kind of heavy framework. My exposure to OSGi is limited. Could you
> explain
> >> in more detail how OSGi would help here?
> >>
> > It was more or less ironic.
> >
> > Sadly, there is no simple way to make MINA 1 and 2 loaded on the same
> JVM,
> > unless you make the whole project a bundle. That mean you will have to
> > integrate an OSGi container in your application. OSGi offers the big
> > advantage to have a specific class loader which insolate each bundle from
> > the others, allowing you to use two bundles depending on two different
> sets
> > of jars.
> >
> > Not that it's a complex task, but frankly, you'd better migrate your MINA
> 1
> > application to use MINA 2.
> >
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
> >
>
Re: Mina 1 vs Mina 2 version conflicts
Posted by Chris Gamache <cg...@gmail.com>.
Understood. Unfortunately, it's not my application using Mina 1. There's a
nice guide at http://mina.apache.org/changes-between-2x-and-1x.html. I'll
see how far I can get porting someone else's application. Any other tips
would be most welcome!
On Tue, Sep 6, 2011 at 5:26 PM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 9/6/11 10:56 PM, Chris Gamache wrote:
>
>> Thanks for the response. The services built on Mina specifically lack that
>> kind of heavy framework. My exposure to OSGi is limited. Could you explain
>> in more detail how OSGi would help here?
>>
> It was more or less ironic.
>
> Sadly, there is no simple way to make MINA 1 and 2 loaded on the same JVM,
> unless you make the whole project a bundle. That mean you will have to
> integrate an OSGi container in your application. OSGi offers the big
> advantage to have a specific class loader which insolate each bundle from
> the others, allowing you to use two bundles depending on two different sets
> of jars.
>
> Not that it's a complex task, but frankly, you'd better migrate your MINA 1
> application to use MINA 2.
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: Mina 1 vs Mina 2 version conflicts
Posted by Emmanuel Lécharny <el...@apache.org>.
On 9/6/11 10:56 PM, Chris Gamache wrote:
> Thanks for the response. The services built on Mina specifically lack that
> kind of heavy framework. My exposure to OSGi is limited. Could you explain
> in more detail how OSGi would help here?
It was more or less ironic.
Sadly, there is no simple way to make MINA 1 and 2 loaded on the same
JVM, unless you make the whole project a bundle. That mean you will have
to integrate an OSGi container in your application. OSGi offers the big
advantage to have a specific class loader which insolate each bundle
from the others, allowing you to use two bundles depending on two
different sets of jars.
Not that it's a complex task, but frankly, you'd better migrate your
MINA 1 application to use MINA 2.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Mina 1 vs Mina 2 version conflicts
Posted by Chris Gamache <cg...@gmail.com>.
Thanks for the response. The services built on Mina specifically lack that
kind of heavy framework. My exposure to OSGi is limited. Could you explain
in more detail how OSGi would help here?
On Tue, Sep 6, 2011 at 2:41 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> On 9/6/11 7:42 PM, Chris Gamache wrote:
>
>> I'm having some trouble with Mina 1.1 versus Mina 2.0 ... I'm using a
>> client-server product (Avis) built using Mina 1.1. Other services I've
>> built
>> are using Mina 2.0. When the two get together in the same runtime
>> environment we get a version conflict explosion. Besides rewriting my
>> components to use Mina 1.1, or Avis to use 2.0, are there any tricks you
>> know of to segregate the two incompatible versions?
>>
> OSGi...
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: Mina 1 vs Mina 2 version conflicts
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 9/6/11 7:42 PM, Chris Gamache wrote:
> I'm having some trouble with Mina 1.1 versus Mina 2.0 ... I'm using a
> client-server product (Avis) built using Mina 1.1. Other services I've built
> are using Mina 2.0. When the two get together in the same runtime
> environment we get a version conflict explosion. Besides rewriting my
> components to use Mina 1.1, or Avis to use 2.0, are there any tricks you
> know of to segregate the two incompatible versions?
OSGi...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com