Cyclic dependency between Entity engine and Service engine

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Cyclic dependency between Entity engine and Service engine

rajsaini
Hi,

I am working on experimental project to run the OFBiz framework in a
OSGi kernel and thereby creating OSGi bundle from various framework
components. I have created bundles for entity and service engine and
could launch entity and service engine as OSGi Service. Although  entity
engine is fairly independent of service engine at compile, there is run
time circular dependency though entityext component because
org.ofbiz.entity.config.DelegatorInfo class (in entity component)  
depends on org.ofbiz.entityext.cache.EntityCacheServices and
org.ofbiz.entityext.cache.EntityCacheServices.depends on LocalDispatcher
class of service engine.

This circular dependency is stopping me a creating separate bundle for
entity and service engine. Is it possible to remove this dependency to
keep the entity engine independent of service engine?

Thanks,

Raj



Reply | Threaded
Open this post in threaded view
|

Re: Cyclic dependency between Entity engine and Service engine

Adam Heath-2
Raj Saini wrote:

> I am working on experimental project to run the OFBiz framework in a
> OSGi kernel and thereby creating OSGi bundle from various framework
> components. I have created bundles for entity and service engine and
> could launch entity and service engine as OSGi Service. Although  entity
> engine is fairly independent of service engine at compile, there is run
> time circular dependency though entityext component because
> org.ofbiz.entity.config.DelegatorInfo class (in entity component)
> depends on org.ofbiz.entityext.cache.EntityCacheServices and
> org.ofbiz.entityext.cache.EntityCacheServices.depends on LocalDispatcher
> class of service engine.
>
> This circular dependency is stopping me a creating separate bundle for
> entity and service engine. Is it possible to remove this dependency to
> keep the entity engine independent of service engine?

Huh?  There are no circular deps during the compile.  That class is
only referenced by use of a String.  GenericDelegator then tries to
load the class, and if it fails, just issues a warning.

So, is this really a problem?  I don't see that it is.

Reply | Threaded
Open this post in threaded view
|

Re: Cyclic dependency between Entity engine and Service engine

rajsaini
Hi Adam,

Yes, this is a problem inside a OSGi Bundle. This makes the entity
engine bundle depends on service engine bundle.

Thanks,

Raj
> Huh?  There are no circular deps during the compile.  That class is
> only referenced by use of a String.  GenericDelegator then tries to
> load the class, and if it fails, just issues a warning.
>
> So, is this really a problem?  I don't see that it is.
>
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Cyclic dependency between Entity engine and Service engine

Adam Heath-2
Raj Saini wrote:
> Hi Adam,
>
> Yes, this is a problem inside a OSGi Bundle. This makes the entity
> engine bundle depends on service engine bundle.

How can it be a problem?  The attempted class load is done in a try
catch, and if not found, ofbiz continues processing.  Are you saying
that any osgi bundle can't do any dynamic configuration, looking for
possible non-existant classes, and then auto-configure itself if it
does or does not find them?  If so, that is broken.

Reply | Threaded
Open this post in threaded view
|

Re: Cyclic dependency between Entity engine and Service engine

rajsaini
Sorry Adam, it was my mistake as I got confused with the logged stack
trace and added entityext as dependency to entity component.

Thanks,

Raj
 
Adam Heath wrote:

> Raj Saini wrote:
>  
>> Hi Adam,
>>
>> Yes, this is a problem inside a OSGi Bundle. This makes the entity
>> engine bundle depends on service engine bundle.
>>    
>
> How can it be a problem?  The attempted class load is done in a try
> catch, and if not found, ofbiz continues processing.  Are you saying
> that any osgi bundle can't do any dynamic configuration, looking for
> possible non-existant classes, and then auto-configure itself if it
> does or does not find them?  If so, that is broken.
>
>
>