Hi Henning,
Right now it is just one bundle wrapper and all the dependencies as OSGi
bundles. Creating one or more bundle shouldn't be difficult though it
will need some minor changes in the framework to resolve classpath issues.
Thanks,
Raj
Henning wrote:
Thanks Raj, that's really very interesting. Are you planning on
committing a modularized version or the bundle wrapper around the whole
of OfBiz?
Thanks,
Henning
Am Montag, den 06.07.2009, 17:00 +0530 schrieb Raj Saini:
I created OSGi bundles of OFBiz and running the framework as well as
applications inside OSGi kernel (Eclipse Equinox). I just took stock
ofbiz and created a OSGi bundle with any code changes in the OFBiz. I
think it creating separate components for OFBiz applications can make it
pretty modular.
As Henning said by my goal was to embed the OFBiz inside the Eclipse RCP
to create a Desktop application and integration was pretty cool except
that I could not modularize the stock ofbiz in various application
components at this moment. However, this should not be much difficult
making some minor changes in the framework.
I am in the process of setting up a Sanbox on sourceforge and commit the
code for people to play with.
Thanks,
Raj
Henning wrote:
David,
thanks a lot for that background information - I am still somewhat new
to OfBiz and for me this is great help for understanding.
Personally I wouldn't bet on EARs or anything else very specific, as
it is not clear wheter the whole industry - or the Java parts of it at
least - will really buy into it. All Java EE servers have their own
extensibility mechanism and unless you have one very monolithic
application you will have to implement vendor-specific interfaces /
declarations / packaging. OSGi looks like it's going to get quite far in
terms of defining some lowest common denominator of a standardized
module runtime system - but then who knows really? So, that said,
there's no disagreement w.r.t. what you decided to do about OfBiz's
infrastructure.
In most instances (I think) the best approach is to make sure whatever
you implement can (in principle - say w/o deep code changes) be
integrated as a library, e.g. like you can embed Jetty in your otherwise
completely regular Java app. So that the environment specific adaptation
(e.g. classpath metadata and service registration in OSGi) can all be
put into an adapter. For example, I think there should be nothing wrong
with using OfBiz in a Desktop app.
From what I can tell from experimenting around OfBiz is not far from
there.
Thanks,
henning
Am Sonntag, den 05.07.2009, 15:25 -0600 schrieb David E Jones:
Thanks for writing more about this Henning (and you too Marc in your
reply). This goes back to what has been one of the toughest parts of
OFBiz from day 1: the infrastructure to build it on.
I'll admit I had only been using more "standard" J2EE stuff for only a
couple of years before deciding to diverge from it. The lower level
stuff is mostly fine (though it would be nice if JDBC implementations,
aka drivers, where more consistent), but once you get above things
like JDBC, JTA, Servlets, etc things get pretty messy (and ugly IMO)
in the Java standards world. I guess fortunately they did split out
these lower level standards and build the higher ones on top of them
so that we can at least use them directly when the higher level ones
don't fit the bill.
The OFBiz component stuff was based on the concept of EAR files, but
created because EAR files leave a lot to be desired. If there was a
way to extend EAR files with some sort of plugin they might do the
job, but as-is even app servers (inconsistently) feel the need to
create extensions to it in order to get just the basic job done. The
ofbiz-component.xsd file describes just what we want to configure in
OFBiz for each component, though it is important to note that this
changes over time as we add new things, and in general it's nice to be
able to "plug-in" things since that's the only way to really make
components independent and create generic tools that reduce
dependencies between the components, at least on the configuration
side of things. Of course, the OFBiz component stuff doesn't have a
plugin mechanism either... we just take the easy way out of changing
it when the need arises (usually when something very new is added to
the framework).
Back to multi-tenancy: if there was a good standard (even if not
implemented yet) that we could use for it that would be great, but I'm
not sure that such a thing exists, or at least not in a form that
would be helpful. There certainly are things to facilitate running
multiple instances on a single server, even machine and OS level
virtualization, but those are inefficient and don't scale the way I
think people are talking about (ie thousands of lightly used instances
on a single server or pool of servers acting as one). So, my guess is
that we'll have to do something custom for this.
Anyway, something custom may make the most sense. With the entity
engine we could build something (like Marc, Harmeet, and others at
Emforium have done), and I like the idea of doing it so the user
interaction is like what the big ones do, ie determine your instance
by user, and that should be quite doable with a few variations (like
putting UserLogin and certain other entities in a separate database
(with their own entity-group)).
Some newer features should help with this too, like the "configurable
screen" (aka "portal") stuff, and the proposed security changes to
externalize permissions from implementation artifacts.
-David
On Jul 2, 2009, at 5:28 AM, Henning wrote:
Hi Experts,
I would like to embed OfBiz with a module environment (not OSGi - but
sufficiently similar to think OSGi if that helps) and for multiple
tenants on one VM. The latter is the the stronger requirement for me.
But as far as modularization is concerned, Ofbiz seems to be in good
shape: The individual logical projects (under framework and
applications) that are all packaged up as one Eclipse project can be
broken up into smaller projects that have a beautiful and meaningful
dependency chain and still compile (at least). Executing them is
probably another story.
Now in terms of multi-tenant usage, I would love to be able to run
different "instances" of OfBiz within the same server. So every tenant
would get its own OfBiz configuration (including its own data source
configuration). OfBiz features would actually be something additional,
integrated with another application and OfBiz would not be the leading
infastructure.
I remember having seen some similar discussions on the mailing list
some time ago - they all seemed to go nowhere. To me it seems that
using
OfBiz as the fundamental functional underpinning and toolbox for
anything eCommerce is a very natural path to follow, but it should not
have unbreakable ties to exactly one underlying infrastructure. I
understand that OfBiz has spent some effort into creating its own
module
system (kind of) - that's perfectly fine and seeing OfBiz run
out-of-the-box after 5min. is perfect. However, other places, other
infrastructures.
Anyway, if anybody has a pointer to something that is similar to what
I described above or some success story, it would be great, if you
could
let me know. Of course, if there is good reasons why this cannot work
w/o touching OfBiz in an unknown but huge number of places that would
also be valuable information.
If I end up getting it done myself and if there is interest, I will
be
happy to share my experience.
Thanks,
Henning
