OFBiz libraries versus Hot-deployed component ones

[Kévin Sailly]

Hello,

I have searched on forum, documentation and on the code and didn't find an answer to this question:
Is it possible to force a hot-deployed component to use it's own libraries rather than concurent ones used by OFBiz?

Thanks a lot,
Kévin Sailly

[Chris Snow-3]

I think each component gets its own class loader, so this should be
happening anyway.

Kévin Sailly wrote:

> Hello,
>
> I have searched on forum, documentation and on the code and didn't find an
> answer to this question:
> Is it possible to force a hot-deployed component to use it's own libraries
> rather than concurent ones used by OFBiz?
>
> Thanks a lot,
> Kévin Sailly
>  

[Kévin Sailly]

Thanks for replying,

That's what I am doing, here is my ofbiz-component.xml

<?xml version="1.0" encoding="UTF-8"?>
<ofbiz-component name="nova"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:noNamespaceSchemaLocation="http://www.ofbiz.org/dtds/ofbiz-component.xsd">
    <resource-loader name="nova" type="component"/>
    <classpath location="build/lib/*" type="jar" />
    <classpath location="lib/*" type="jar"/>
   
    <service-resource loader="nova" location="servicedef/services.xml" type="model"/>
   
    <webapp name="nova"
       title="NOVA OFBiz Application"
       server="default-server"
       location="webapp/nova"
       mount-point="/nova"/>     
</ofbiz-component>

But it still using a library from OFBiz rather than one declared on the classpath.

May be I should set-up my class loader called "nova" somewhere else?

[Adam Heath-2]

Christopher Snow wrote:
> I think each component gets its own class loader, so this should be
> happening anyway.

No, there is a single classloader for all of ofbiz.

[Chris Snow-3]

Adam Heath wrote:
> Christopher Snow wrote:
>  
>> I think each component gets its own class loader, so this should be
>> happening anyway.
>>    
>
> No, there is a single classloader for all of ofbiz.
>
>  
Thanks for clarifying Adam.

[Adam Heath-2]

Christopher Snow wrote:

> Adam Heath wrote:
>> Christopher Snow wrote:
>>  
>>> I think each component gets its own class loader, so this should be
>>> happening anyway.
>>>    
>>
>> No, there is a single classloader for all of ofbiz.
>>
>>  
> Thanks for clarifying Adam.

It's actually slightly more complex.

start.jar begins, and it can only see itself.

It is then hard-coded(sorta, thru the use of internal properties files
embedded in the jar) to find all libraries in framework/base/lib, and
add then to an initial classloader.

This classloader contains the container and component loading logic.
That finds the rest of ofbiz, and creates a second classloader.  Note,
that this second classloader has duplicate framework/base libs, and
that the first one might have framework/base libs that it shouldn't,
because the ofbiz-component.xml for base may not include some library
folder.

Then, all the containers start.  One of those is catalina.  For each
web-app, it does create a separate classloader, and it might be
possible to override libraries there, by using WEB-INF/lib.  But this
is not the standard ofbiz way.

[Chris Snow-3]

Adam Heath wrote:

> Christopher Snow wrote:
>  
>> Adam Heath wrote:
>>    
>>> Christopher Snow wrote:
>>>  
>>>      
>>>> I think each component gets its own class loader, so this should be
>>>> happening anyway.
>>>>    
>>>>        
>>> No, there is a single classloader for all of ofbiz.
>>>
>>>  
>>>      
>> Thanks for clarifying Adam.
>>    
>
> It's actually slightly more complex.
>
> start.jar begins, and it can only see itself.
>
> It is then hard-coded(sorta, thru the use of internal properties files
> embedded in the jar) to find all libraries in framework/base/lib, and
> add then to an initial classloader.
>
> This classloader contains the container and component loading logic.
> That finds the rest of ofbiz, and creates a second classloader.  Note,
> that this second classloader has duplicate framework/base libs, and
> that the first one might have framework/base libs that it shouldn't,
> because the ofbiz-component.xml for base may not include some library
> folder.
>
> Then, all the containers start.  One of those is catalina.  For each
> web-app, it does create a separate classloader, and it might be
> possible to override libraries there, by using WEB-INF/lib.  But this
> is not the standard ofbiz way.
>  

OSGi would be a nice solution to this problem!

[Adam Heath-2]

Christopher Snow wrote:

> Adam Heath wrote:
>> Christopher Snow wrote:
>>  
>>> Adam Heath wrote:
>>>    
>>>> Christopher Snow wrote:
>>>>  
>>>>      
>>>>> I think each component gets its own class loader, so this should be
>>>>> happening anyway.
>>>>>            
>>>> No, there is a single classloader for all of ofbiz.
>>>>
>>>>        
>>> Thanks for clarifying Adam.
>>>    
>>
>> It's actually slightly more complex.
>>
>> start.jar begins, and it can only see itself.
>>
>> It is then hard-coded(sorta, thru the use of internal properties files
>> embedded in the jar) to find all libraries in framework/base/lib, and
>> add then to an initial classloader.
>>
>> This classloader contains the container and component loading logic.
>> That finds the rest of ofbiz, and creates a second classloader.  Note,
>> that this second classloader has duplicate framework/base libs, and
>> that the first one might have framework/base libs that it shouldn't,
>> because the ofbiz-component.xml for base may not include some library
>> folder.
>>
>> Then, all the containers start.  One of those is catalina.  For each
>> web-app, it does create a separate classloader, and it might be
>> possible to override libraries there, by using WEB-INF/lib.  But this
>> is not the standard ofbiz way.
>>  
> OSGi would be a nice solution to this problem!

What problem?

[Chris Snow-3]

Adam Heath wrote:

> Christopher Snow wrote:
>  
>> Adam Heath wrote:
>>    
>>> Christopher Snow wrote:
>>>  
>>>      
>>>> Adam Heath wrote:
>>>>    
>>>>        
>>>>> Christopher Snow wrote:
>>>>>  
>>>>>      
>>>>>          
>>>>>> I think each component gets its own class loader, so this should be
>>>>>> happening anyway.
>>>>>>            
>>>>>>            
>>>>> No, there is a single classloader for all of ofbiz.
>>>>>
>>>>>        
>>>>>          
>>>> Thanks for clarifying Adam.
>>>>    
>>>>        
>>> It's actually slightly more complex.
>>>
>>> start.jar begins, and it can only see itself.
>>>
>>> It is then hard-coded(sorta, thru the use of internal properties files
>>> embedded in the jar) to find all libraries in framework/base/lib, and
>>> add then to an initial classloader.
>>>
>>> This classloader contains the container and component loading logic.
>>> That finds the rest of ofbiz, and creates a second classloader.  Note,
>>> that this second classloader has duplicate framework/base libs, and
>>> that the first one might have framework/base libs that it shouldn't,
>>> because the ofbiz-component.xml for base may not include some library
>>> folder.
>>>
>>> Then, all the containers start.  One of those is catalina.  For each
>>> web-app, it does create a separate classloader, and it might be
>>> possible to override libraries there, by using WEB-INF/lib.  But this
>>> is not the standard ofbiz way.
>>>  
>>>      
>> OSGi would be a nice solution to this problem!
>>    
>
> What problem?
>
>  

Control over which version of a library you depend on without having to
setup and manage your own classloader.

[Kévin Sailly]

I have try this :

<classpath location="webapp/nova/WEB-INF/lib/*" type="jar"/>

This giving me an error on runtime :

interface javax.persistence.NamedQueries is not visible from class loader

any idea?

[rajsaini]

Libraries in the WEB-INF/lib are automatically placed in web app
classpath. I do not think you need to specify this anywhere in the
classpath. You may want to check if you have the right jar files in the
lib folder.

Thanks,

Raj

Kévin Sailly wrote:

> I have try this :
>
> <classpath location="webapp/nova/WEB-INF/lib/*" type="jar"/>
>
> This giving me an error on runtime :
>
> interface javax.persistence.NamedQueries is not visible from class loader
>
> any idea?
>  

[Kévin Sailly]

Not specifying the classpath makes ant build to not embed the libs, so it does not work.

[rajsaini]

You can copy the files in the WEB-INF/lib folder of the web app or
create a ant target and copy those files at the build time.

Thanks,

Raj

Kévin Sailly wrote:
> Not specifying the classpath makes ant build to not embed the libs, so it
> does not work.
>  

[Kévin Sailly]

It does not work for me, if you have some other suggestion please let me know.

[Jacques Le Roux]

Hi Kévin,

Something that might interest the community is your ultimate goal... A shared goal gives more opportunities...

Jacques

From: "Kévin Sailly" <[hidden email]>
>
> It does not work for me, if you have some other suggestion please let me
> know.
> --
> View this message in context: http://n4.nabble.com/OFBiz-libraries-versus-Hot-deployed-component-ones-tp1573363p1576214.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Kévin Sailly]

Hello Jacques,

I want to use some packaged services from another development in OFBiz, the goal is to prevent me to redevelop this services, then I tried to put the jar and dependants libraries in a webapp to expose this services as OFBiz services.

The problem is that some of the libraries on which my packaged services depends on are the same that some of the OFBiz ones, but on another version.
Prior, my webapp using OFBiz libraries rather than mine, then causing runtime exceptions like NoSuchMethodException, ClassNotFoundException.

The final goal could be seen as using OFBiz capabilities without putting all my existing code on a trash!

Hope this more clear,

Thanks,
Kevin

[Kévin Sailly]

I found the reason why this is not possible from an older problem :
http://www.mail-archive.com/[e-mail]/msg04764.html

May be concurent libraries will be managed in a future release?

Thanks a lot,
Kévin

[Jacques Le Roux]

From: "Kévin Sailly" <[hidden email]>
> I found the reason why this is not possible from an older problem :
> http://www.mail-archive.com/ofbiz-dev@.../msg04764.html

Good catch!

> May be concurent libraries will be managed in a future release?

We have not discussed that recently

Jacques


> Thanks a lot,
> Kévin
> --
> View this message in context: http://n4.nabble.com/OFBiz-libraries-versus-Hot-deployed-component-ones-tp1573363p1578198.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Jacques Le Roux]

Hi Kévin,

You could run the old instance and call services from there.
Else I can't see any easy way to do this. I'm afraid you will have to get your hands dirty.

Jacques

From: "Kévin Sailly" <[hidden email]>

> Hello Jacques,
>
> I want to use some packaged services from another development in OFBiz, the
> goal is to prevent me to redevelop this services, then I tried to put the
> jar and dependants libraries in a webapp to expose this services as OFBiz
> services.
>
> The problem is that some of the libraries on which my packaged services
> depends on are the same that some of the OFBiz ones, but on another version.
> Prior, my webapp using OFBiz libraries rather than mine, then causing
> runtime exceptions like NoSuchMethodException, ClassNotFoundException.
>
> The final goal could be seen as using OFBiz capabilities without putting all
> my existing code on a trash!
>
> Hope this more clear,
>
> Thanks,
> Kevin
> --
> View this message in context: http://n4.nabble.com/OFBiz-libraries-versus-Hot-deployed-component-ones-tp1573363p1576381.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Kévin Sailly]

Hello Jacques,

My old services does not running on an older instance of OFBiz, but are based on some other java technologies.

I am looking for other solution now.

Thanks,
Kévin