Hi David,
I see it at both levels but in a phased manner. In the first phase, we
can use the OSGi to manage the run time and component code and leave let
OFBiz containers and load using OFBiz component model. This is the part
my prototype addresses and can help us creating binary releases.
I have not thought much about the how to replace the OFbiz component
model with the OSGi one. However, I see no reason it cant be done using
the standard MANIFEST files of OFBiz. We would need to extend the OSGi
(creating one bundle to handle this stuff) similar to the way Spring and
Eclipse do.
Thanks,
Raj
David E Jones wrote:
I like many of the ideas about OSGi (even if it isn't quite what some people
think it is).
>From your point of view, how specifically do you see OSGi used in OFBiz? Are
you thinking it could replace the OFBiz component functionality or just be used to
deploy java code arbitrarily at run-time?
If you are thinking it could be used to replace the OFBiz component stuff, how
would you handle each part of the ofbiz-component.xml file (especially the
non-classpath parts)?
I've looked into it, but not enough to get past that, so any thoughts you (or
anyone else) has would be interesting.
-David
On Mar 12, 2010, at 1:53 AM, Raj Saini wrote:
Hi David,
One thing could be useful in the long run is moving to OSGi based components.
There are numerous benefits of OSGi and you can find a a lot about it on the
net. The kind of modularity OSGi brings is not possible in other components
modules. Dynamic bundle loading and unloading is useful during development and
run time. During development, for example if you have changed some Java code in
one of the bundle, you do not need to restart the complete server to load the
new code. Just update or stop/start the bundle and you are ready to test. One
more advantage I see is exporting OFBiz services as web services or distributed
OSGi services. Eclipse ECF and Apache CXF provide distributed OSGi
implementation. Integration with other applications such as ServiceMix should
also be very easier as they are already run on OSGi platform.
Thanks,
Raj
I recently completed a prototype to run the OFBiz framework embedded in the
Equinox OSGi runtime and it worked fine with little changes here and there.
David E Jones wrote:
If you could change anything about the OFBiz framework (not related to a
specific tier), what would it be? This could be about how OFBiz is deployed,
how the tools fit together, how application components are written and
organized, and so on.
All comments are welcome. If there is another tool you'd like to see used, please describe what you
like about it (like "I've found the aspect oriented inversion of control approach nice because
I can plugin all sorts of tools and the full life cycle of the tools are managed for me")
instead of just mentioning the tool (like "let's use Spring!").
Why am I asking? This topic comes up every once in a while, and it's true that
many suggestions never get enough support to actually happen (or on further
research it is decided that the idea is not tenable), but brainstorming about
them to get ideas in the open is still a great thing. The history of OFBiz is
full of things like this where users and more casual contributors had ideas and
saw possibilities that others, even more involved contributors, totally missed
or never looked at that way. What I think would be fun, and ultimately useful
too, is to keep this mostly to brainstorming and not do too much comparing of
ideas.
BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or
UI tiers) please use the other threads on those.
-David
