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 > >>> > > > > >
