mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: MINA as pure OSGi bundles?
Date Mon, 04 Sep 2006 02:36:03 GMT
Hi John,

On 9/2/06, John E. Conlon <jconlon@verticon.com> wrote:
> Hi Trustin,
> On Fri, 2006-09-01 at 12:17 +0900, Trustin Lee wrote:
> > Cool.  I really appreciate your will!  One question: where would these
> maven
> > projects should be located?
> > I think the MINA OSGi bundles should be
> > splitted into multiple bundles as we did for MINA JARs (mina-core,
> > mina-filter-ssl, ...).  If so, placing these directories directly under
> > trunks/mina will not look really good.  Here's my suggestion for the
> > directory structure:
> >
> > trunks/mina
> > - core
> > - filter-ssl
> > - filter-codec-asn1
> > - filter-codec-netty2
> > - integration-spring
> > - integration-osgi
> > ---- core (OSGi bundle for core)
> > ---- filter-codec-asn1 (OSGi bundle for filter-codec-asn1)
> > ...
> >
> > Of course, we wouldn't need this hierarchy if maven-osgi-plugin can
> generate
> > multiple buldles with one project.
> >
> > WDYT?
> Initially we can just add the osgi plugin specifications to the existing
> projects' pom.xml files and not create any new projects. Adding the
> plugin specifications will create the necessary metadata in the jar when
> it is built allowing the jar to also act as an OSGi bundle. In other
> words the jar still acts like it did before - for any non-osgi
> application, but it also works as an OSGi bundle. (Sort of like Clark
> Kent and Superman. Clark still goes to work at the Daily Planet:)
> For the first Mina OSGi effort I suggest offering Mina packages and
> classes to other bundles in the OSGi framework - in other words Mina at
> first will be a set of OSGi library bundles. This is relatively easy.
> Have already done this for the Mina core project by adding the OSGi
> plugin specs to the core project ( will soon post a patch to Jira)
> pom.xml.  Will begin filter-ssl, filter-codec-asn1, and filter-codec-
> netty2 today.  Once done Mina becomes a first class OSGi citizen. (Good
> bye wrapper projects.)

Very cool enough! ...and the superman analogy makes me smile.  :D

The sexy stuff can come latter - Dynamic OSGi configuration of Mina will
> require something more than just offering libraries to clients. Dynamic
> configuration will require Mina support for OSGi Configuration Admin
> support and possibly Initial Provision service support in order to offer
> on-the-fly creation of servers from metadata stored in a standard OSGi
> configuration repositories. (Of course for us this means the ADS!)

Yes.  Providing smaller components as a OSGi library bundle and providing
bigger integration bundles sound like a greate approach.  I second your

To answer your original question I think Mina projects may end up
> looking like very much like they do today. With the possible addition of
> an osgi-configuration project and maybe an osgi-agent project.
> trunks/mina
> - core
> - filter-ssl
> - filter-codec-asn1
> - filter-codec-netty2
> - integration-spring
> - osgi-configuration ?
> - osgi-agent ?

It's a kind of integration project, so I think
integration-osgi/(configuration/agent) would look better.

To imagine this more objectively I will need to better understand how
> Spring is being used today for Mina application creation and
> configuration.

The spring integration is used to configure the filter chain and to bind the
IoHandler and IoServiceConfiguration to a certain port.  It is very
inconvenient to do that in Spring out-of-the-box, so Niklas created the
beans that calls bind() and other filter manipulation methods.

Trustin, I have seen the JavaDocs for the Spring integration, but can
> you direct me to any document describing the overall requirements that
> you have for how Spring is used to configure Mina applications?  Or if
> that is lacking can you share with me a set of Spring xml docs to show
> me a variety of configuration scenarios?

I think this might help you.  We need to merge this patch into our trunk,
too. :)


what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message