Sharing an interface jar with multiple modules

Content Server 6.7 SP2 P06

Composer 6.7 SP2 P06

It seems there is no easy way to avoid duplication. I have an interface jar that contains an interface that is used for multiple modules. If I create a jardef and reference the jardef in each module I get a warning indicating that the jardef should only be referenced in one module and I should use a library to share with multiple modules, however, when I create a library and reference the library in each of the modules, the interface is not found. The only solutions appear to be to ignore the warning, or to create a duplicate jardef for each module with a different name but containing the interface. I'd really rather not do either of these.

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

PanfilovAB

Abstract classes are not interfaces, it's implementation. So, you should mark jar, containing AbstractJobMethod as implementation jar. Also, I have found a bug in composer - switching jar type sometimes has no effect until composer restarted.

All comments

PanfilovAB


when I create a library and reference the library in each of the modules, the interface is not found.

Does that happen when you're installing dar, or when you're trying to instantiate module, or it's a composer message?

fainemr

Sort of both, it's a composer warning message that I see whenever I select the class name under the General Tab, Core Jars. I haven't tried to deploy it like this in a while but I do recall getting a ClassNotFoundException when I ignored the message and attempted to deploy it anyway.

PanfilovAB

Hm, can't reproduce that in 6.7SP2P7

20-02-2014 6-27-31 AM.jpg

If you able to share your project I could spend some time investigating your problem.

fainemr

I don't know, maybe you have the interface in your implementation jar?

PanfilovAB

fainemr

Well, that is helpful. Of course, I'm aware that abstract classes are not interfaces but I've been told that for the purposes of Composer they should be treated as such and it hasn't caused any problems before. Still, whatever works. I think this may have fixed it but it is too soon to tell. I have to make a few adjustments, deploy, and test. Thanks!

PanfilovAB

BTW. We tried to use libraries in one project (actually for the same reason as your: misleading composer warning), but later we realized that that was a mistake: standalone jar deployment is more flexible, at least you should avoid putting implementation jars into library: dfc does not reload libraries in runtime, so it turns normal development in permanent restarting of application server, jms, etc.

fainemr

That explains a lot. The last time I was doing Composer deployment and testing ( a week or two ago) I could not get it to deploy the new code without clearing the bof cache and restarting the content server. After a while I just gave up and made clearing the cache and restarting the server part of the testing procedure. It was a real pain. I think I now know what was going on. I'll check it out. Thanks

lastnitescurry

Sandboxing your java libraries will allow for hot deployment. see:

Hot deployment in BOF – yes or no? | Say Scheveningen

PanfilovAB

Sandboxing brings another issues

fainemr

This is what I've been doing, so far so good. I probably should have updated this post to say so. Thanks

fainemr

What issue? I've not noticed any problems yet, seems like it's always something with Documentum, especially with BOF.

PanfilovAB

Primarily ClassCast exceptions

fainemr

Thanks, haven't seen any so far but I'll keep an eye out for it.

lastnitescurry

Have hit the ClassCast exceptions but have been able to sort them out in last few years/projects.

BOF has its pains but would rather work with them than try and roll out an updated jar, which is what I have to do on env I am supporting atmo