Hi John, On 9/2/06, John E. Conlon <[EMAIL PROTECTED]> 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 idea. 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. :) http://issues.apache.org/jira/browse/DIRMINA-227 HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
