On 1 September 2011 22:20, Mark Diggory <mdigg...@atmire.com> wrote:
> On Thu, Sep 1, 2011 at 2:11 PM, Mark H. Wood <mw...@iupui.edu> wrote:
>
>> > But, I agree with your point. It does seem like we can find ways to make
>>
> > this easier post-1.8.0. You should be able to Install DSpace and then
>> > "drop in" some add-ons & configure them as needed.
>> >
>> > Technically, you can basically do the "jar drop-in" thing with custom
>> > Curation Tasks or separately-released Curation Tasks (like Replication
>> > Task Suite, https://jira.duraspace.org/browse/DS-876).
>>
>>
> Well, we need a framework for doing this... Ironically, this is what OSGi
> is, I don't think folks get that, we should be watching DuraCloud and
> Sakai CLE (http://sakaiproject.org/sakai-cle) both are Felix based, both
> provide a framework to inject "addons" into a running instance of the
> application. I hope we do not reinvent the wheel simply because we can't
> grok the acronym OSGi, even the Attlasian folks get this (
> http://confluence.atlassian.com/display/DEVNET/Atlassian+Plugin+SDK+Documentation
> )
>
>
Yes, OSGi makes it possible to dynamically load and unload modules, to
dynamically wire service points. It gives you a framework to formally
specify what those service points are. It makes it possible to develop the
kind of small footprint, dynamically delivered systems comprised of
functionality / applications split into logical packages that the kind of
environment that OSGi was created for depends on.
It makes all of that possible. But only when you carefully design what those
modules are. Only when you take care to understand and respect what the
specification lays out your responsibilities to be. When you take care over
where your modules interact, and how they communicate with each other.
There is nothing 'magic' about OSGi - it's a registry/wiring of services,
and gives each module it's own ClassLoader. If you don't take care of making
sure you do things well, then whilst OSGi is capable of delivering good
reliable systems, it's all too easy to end up with a system that may appear
to work to a degree, but:
a) may be bloated through multiple copies of the same code loaded in
different modules/bundles
b) may be bloated through multiple revisions of the same module/bundle being
loaded in memory
c) may have runtime failures through illegal access of objects across
different ClassLoaders
As I say, there is nothing about OSGi that prevents you from running into
these issues. You need to understand the requirements, have a good design,
and implement it correctly.
I'm not saying that to be negative about OSGi, because really, it is what
you make of it. But even without OSGi, there are enough specifications and
technologies that we are working with right now, that we need to be able to
understand properly, respect, and implement correctly. Because OSGi will not
make us better at doing that, it will give us more ways to make our systems
worse.
G
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
