Done.
https://issues.apache.org/jira/browse/OFBIZ-4153
Raj
On Friday 28 January 2011 01:07 PM, Adrian Crum wrote:
There is no doubt there will be problems. We can tackle them one at a
time in a Jira issue.
I wasn't aware that entity-ext depends on the service engine. Maybe a
Jira sub-task could break that dependency.
I think the entityengine.xml file issue can be resolved through
standard Java resource loader methods. In other words, applications
will name their XML files according to a pre-defined format, and the
entity-engine jar file will find and load all matching XML files. Just
think of them as a resource file. Again - these details should be
discussed further in a Jira issue.
-Adrian
On 1/27/2011 11:23 PM, Raj Saini wrote:
I tried to use the entity engine exactly the way you have described.
I faced the problems as entity engine depends entity-ext (for some
cache management) and entity-ext depends on service engine. If we
resolve this dependency, entity engine can certainly be a standalone
jar and as you said it can be packaged as OSGi bundle. We will also
need to take care of entityengine.xml configuration so that it can be
loaded from a pre-defined location instead of a classpath.
Raj
On Friday 28 January 2011 12:28 PM, Adrian Crum wrote:
I was picturing the entity engine as a lower level artifact - like a
jar file. I don't have all of the details worked out yet, but what I
picture is this:
1. An application needs a database-agnostic data store.
2. The application accesses the data store though the entity engine
API/ jar library.
Ofbiz has a very convenient way of defining databases, tables, and
views as XML files. Plus, it has the ability to create/modify
table/index structures during start-up. I believe that would be a
very handy tool for anyone wanting to create any application that
requires data storage.
Wrapping the entity engine jar file in an OSGI bundle would be trivial.
If anyone is interested in exploring this further, then they should
create a Jira issue and we can take it from there.
-Adrian
On 1/27/2011 10:21 PM, Raj Saini wrote:
I will certainly be glad to help in this. I had re-packaged the
entity engine as and OSGi bundle and exposed the delegator as osgi
service. I found minor issues like loading of entityengine.xml from
classpath and this did not go well with the OSGi. Let us wait for
the the restructuring of the OFBiz project.
Thanks,
Raj
On Friday 28 January 2011 10:58 AM, Adrian Crum wrote:
Cool. If anyone is interested in working on that, I am available
to help.
-Adrian
On 1/27/2011 9:23 PM, Raj Saini wrote:
Yes, I agree. Entity Engine and Service Engine are two such
marvellous pieces of technologies. Entity engine can very well
compete with Java Persistence API (JPA) if it is separated from
the OFBiz runtime.
Raj
On Friday 28 January 2011 10:26 AM, Adrian Crum wrote:
I have suggested that in the past. OFBiz has spawned some great
technology that, if modified to be stand-alone subsystems, could
be their own projects.
-Adrian
On 1/27/2011 8:52 PM, Raj Saini wrote:
One thing I would like to see is to use the OSGi runtime for
framework. This will help modularising efforts. For example
entity engine, service engine, security etc. will be OSGi
bundles running on top of OSGi framework such Apache Karaf.
Apache ServiceMix is already using Karaf
(http://karaf.apache.org). I did a prototype and embedded the
OFBiz in OSGi runtime
(http://sourceforge.net/projects/ofbiz-osgi/) and it worked well.
Thanks,
Raj
On Thursday 27 January 2011 03:01 PM, Pierre Smits wrote:
Hi All,
This thread is about where you want the community to go with
the underlying
core components of OFBiz (aka the Framework).
The framework is the enables of all applications and business
processes and
users of the product. It is about security, and about a future
proof and
reliable platform for developing applications on.
What do feel is important? What should be removed from the
framework. what
should be included? What can be enhanced? And what not?
Please let all of us know what you think is important
regarding the
framework so that we (the community) can take stock and draw
up a plan for
comming releases.
Regards,
Pierre
