Hey Richard.
I can imagine. It was not my intention to present my perspective as
FUD. Sorry 'bout that.
From a consumer of technology point of view our notion of "standard"
is slightly different - especially since Brad and I work in a space
where the use of "standardized" technology is becoming paramount (two
guesses, and the first one doesn't count). In many cases our ability
to utilize any given tech depends on if it is based on an "open"
standard - or not. That said, it is an easier sell to stay close to
the spec.
I completely appreciate segregation of spec and implementation. I
believe you are correct that a spec or standard should and can not
limit the growth of its implementation. And ... not knowing anymore
about iPojo than what has been made available here I'll shut up now,
and go back into my hole. ;)
Kit
On Oct 28, 2008, at 2:32 PM, Richard S. Hall wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
