Thanks Kit. My (current) theory is that the osgi standard uses packages
as the unit of reuse. The problem I'm having seems to originate with
that assumption. So its either give up or try something class-based.
The only justification for packages I've seen is that its "more
elegant". Anybody know a more comprehensive reason?
Kit Plummer wrote:
Brad,
I would warn against the non-standard nature of iPojo. Not to say that
it is a bad thing, but given the landscape and "components" I think
you'll struggle with different issues moving in that direction. Sure,
you may resolve component dependencies - cleaner. But, the risk is that
your component no longer travels well.
Kit
On Oct 28, 2008, at 8:04 AM, Brad Cox wrote:
I'm totally new to iPOJO but have been pusing components forever. But
I'm guessing this fine- vs coarse-grained distinction is precisely the
problem I've been struggling with org.jdom, with lots of hand-on help
from P. Kriens. So far its defeated both of us.
It seems JDOM is what you called a coarse-grained component, developed
long before this fine-grained ipojo stuff was around. Deeply entangled
with even lower-level dependencies, like Xerces. So I've started
looking at iPOJO to see whether that might be a way forward.
I'm hoping to find a way to include jdom+dependencies in one of my
ipojos so other ipojos can resolve it from there. Seems
straightforward on the surface, if I can avoid whatever is breaking
bnd now.
Clement Escoffier wrote:
Hi,
That’s an interesting question. I would say that it slightly depend
of your use case. However, in one level of abstraction, being
consistent sounds reasonable. To illustrate this, I’m going to
describe two different types of projects choosing the different
strategies: a universe of fine-grain components, and a universe of
coarse-grain components (using regular object collaborators).
In a project aiming to design and implement a residential gateway,
the granularity of components is rather fine-grain. The most part of
the functionalities are implemented inside components and are
available through services, such as devices, technical services, and
internal application services. For this latter case, using iPOJO
composite was crucial to maintain the isolation of internal services
that must not be accessible outside the application (by peer that are
not a part of the application). This granularity was chosen because
of the required flexibility for runtime evolution (application
updates, modifications of the environment…). In this use case,
“everything was dynamic”.
In the Jonas JEE server, the chosen granularity was coarse-grain
(Guillaume or/and Francois, correct me if I’m wrong). Each technical
services provided by the JEE server is implemented by iPOJO
components and provided as OSGi services. Two aspects motivated this
choice. First, the Jonas team wanted to reuse the most part of their
code (makes sense right?). Then, the unit of evolution (update) is
the technical service (coarse-grain). So, in conclusion, it’s an open
question ☺. There is no generic answer. iPOJO does not influence one
or another way, because IMHO it depends of the use case. The goal of
iPOJO was to provide functionalities to handle both cases.
Regards,
Clement
-----Original Message-----
From: Todor Boev [mailto:[EMAIL PROTECTED] Sent: lundi 27 octobre
2008 19:03
To: [email protected]
Subject: IPojo - universe of components?
Hello,
I was wondering what is iPojo's mission in life: just to make it a
bit easier to code in OSGi or the grand idea to lift the Java
language to a higher abstraction. This philosophical question is
important to me because iPojo like most other DI frameworks seems
highly viral.
For example suppose I start out with a single component class that
creates all it's collaborators with POJN (Plain Old Java New :). At
this point I will have to inject all service dependencies into this
uber-component and have it pass them on to the constructors of it's
collaborators. Soon I get sick of my bad style and decide to let
iPojo manage the collaborators and pass around the dependencies for
me. And as soon as the collaborators are under iPojo's wing all
classes that need them will also have to be iPojo managed. And so in
no time almost all my classes will be components. All that will be
left are light-weight data objects and static utilities. The former
could soon acquire behavior of their own and will inevitably become
components because they will likely need to collaborate with other
components. As for the static utilities: unless they are bundles of
stand-alone purely functional methods they are a bad style to begin
with and should be re-cast as singleton components. So if I go with
the flow I should have a universe of components.
Is this the way to work with iPojo? Or should restrict iPojo to only
the core graph of long-lived objects that form the basis of my
program and manage the construction, and lifecycle of the more
volatile object generations by hand?
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
