No offense taken, just trying to dispel common misconceptions.
As Clement already stated, iPOJO is in no way tied to Felix. It is just
a bundle that runs on top of any OSGi framework.
The Felix community takes "pure OSGi" seriously. We would never try to
tie anyone to Felix for any of our subprojects, unless there was no way
around it. This should be a FAQ.
Additionally, if we keep letting people think that the only way a bundle
should be used is if the OSGi Alliance has "blessed" it, we will surely
stunt the growth of OSGi acceptance.
From the OSGi Alliance's perspective, it might be nice if we were the
center of the universe, but I believe everyone knows that this is not
realistic. It is only worthwhile to standardize things when multiple
implementations are actually possible and/or beneficial. Further, it is
not good to standardize rapidly changing technology. We need experience
with it first.
-> richard
Kit Plummer wrote:
Hey Richard.
Sorry...didn't mean to put anyone on the defensive. My point really
was around using core OSGi interfaces versus Felix iPOJO "stuff" - and
that notion. I should also apologize because I'm familiar with Brad's
work. But, noting specification (OSGi) versus standard probably is
worthy too.
The real concern is being tied to Felix, rather than just OSGi,
nothing more.
Kit
On Oct 28, 2008, at 9:43 AM, Richard S. Hall wrote:
Kit,
I would be interested in the issues that concern you. I believe it
should be possible to create components in iPOJO that use basic DoI
techniques that would travel well. Clearly, you can use more advanced
features that won't, but no one forces you to do that.
I am not really sure what "standardness" has to do with the point,
since I am not really aware of a standard in this area, unless you
are talking about DS or the Spring-DM work within the OSGi Alliance.
If so, I would say that there is nothing special about being run
through the OSGi Alliance spec process, other than getting more
feedback.
-> richard
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]
---------------------------------------------------------------------
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]
