Hello Chris,
Thanks for pulling this initial page together. Having not worked directly
with Guice, I am not in a position to advocate for or against it. Has anyone
else used Guice first hand?
Digging deeper into the "Module+Architecture+Development" wiki page, I would
like to expand on a point mentioned in the "OSGi-friendliness" section.
You mention the favorable practice of separating the interfaces and
implementations into different packages. Using the mentioned
"maven-bundle-plugin"
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
automatically generates project jar (or war) artifacts that have the
necessary META-INF/MANIFEST.MF enabling the artifact to be installed into an
OSGi container as a proper bundle.
The MANIFEST created by this plugin exports all packages of the project to
the OSGi container with the exception of:
. (default package)
impl (any package containing 'impl')
internal (any package containing 'internal')
So naming implementation packages with either 'impl' or 'internal' will have
the desired effect of not exposing implementation classes to other
services/bundles in the container.
Also, is there a particular reason behind your recommendation to use
constructor injection over property injection in addition to not requiring
getters/setters and knowing that a class has been fully initialized?
Andrew
On Thu, Mar 4, 2010 at 1:46 PM, Chris Wilper <[email protected]> wrote:
> Hi all,
>
> I've started a page as a followup to the London meeting discussion
> about OSGi and dependency injection frameworks.
>
>
> http://fedora-commons.org/confluence/display/FCREPO/Module+Architecture+Development
>
> At the meeting, folks seemed pretty comfortable with the idea of
> moving forward with Spring for DI, but as Eddie noted on Tuesday's
> call, it would be good for us to answer the question: Why not Guice?
> I've only had direct experience with Spring, but have heard positive
> things about Guice. In an effort to try to understand the
> differences, I've done some investigation and put up a simple
> comparison matrix on the above page. Note that I included
> PicoContainer for good measure, but there is very little info out
> there on its OSGi-friendliness.
>
> I am currently leaning slightly toward Spring (vs Guice), mainly
> because it offers an "out of box" way to wire up dependencies up
> without recompiling. I'm aware of the "xml hell" and type-safety
> critiques of Spring's external configuration approach, but we clearly
> need to continue to have a way for people to reconfigure, and plug in
> alternate implementations (e.g. for storage impls) without writing
> java code. Although this is possible with approaches like
> guice-xml-config, it just doesn't seem to be done often in the Guice
> world, which makes me think it might not be a good fit.
>
> The other thing, which can probably be worked around by sticking to
> constructor injection (as I hope we can anyway), and using finalize()
> for de-initialization, is that Guice currently doesn't have a way for
> classes to get startup/shutdown event callbacks. I'm thinking that a
> replacement for Fedora's current Module.shutdownModule() would be good
> to have...
>
> I'd very much like to hear other ideas/opinions on this.
>
> Thanks,
> Chris
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Fedora-commons-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
