Hi Ramesh, thanks. So can I assume server-api and server-core does are always used as a pair? In that case, I can open a jira and suggest to create a separate OSGi bundle containing both jars, as it doesn't harm packaging two in one bundle. It's just not nice to have to create an extra jar for OSGi, though.
If the current two server-api and server-core jars need to become two separate bundles, there is no simple way to fix the cyclic dependency problem. Either changing the API so that server-api can use another CL to load server-core classes or using an not-as-nice workaround of using TCCL. So, is the first approach preferrable, namely making one bundle from two jars? In that case, I can update OLINGO-632 to create bundles accordingly. regards, aki 2015-04-27 15:10 GMT+02:00 Ramesh Reddy <[email protected]>: > Aki, > > Use of TCCL is not preferred IMO. I suggest you open a JIRA with suggestion > to fix it. > > Ramesh.. > > ----- Original Message ----- >> My question comes from the osgi-bundlization of olingo4. >> >> If server-api and server-core are always paired, we could avoid TCCL >> (that means, make no change) but just create one bundle containing >> both parts. Maybe this is preferred? In that case, we create two >> classic jars and one bundle jar that contains both. >> >> regards, aki >> >> >> >> 2015-04-27 14:22 GMT+02:00 Aki Yoshida <[email protected]>: >> > Hi, >> > have a question about the way how an OData instance is instantiated >> > using the current API. >> > >> > Currently, the OData.newInstance() method of server-api tries to load >> > ODataImpl of server-core using its classloader. For this to work, >> > server-api needs a dependency to server-core and since server-core has >> > dependency to server-api, there will be a cyclic dependency. >> > >> > One way to avoid this would be to use TCCL first to load the class if >> > this is set, which is a normal jee approach. In this way, all jee apps >> > will work and modular apps like OSGi will then need to explicitly >> > assign its bundle classloader to its TCCL. But in any case, they will >> > both work in this case without creating a cyclic dependency between >> > server-api and server-core. >> > >> > Another approach would be to change this interface so that you can >> > pass the impl name along with its classloader to load this class. >> > >> > I am wondering if something of this kind of customization is planned. >> > In other case, I think it would be a good idea to add the TCCL based >> > classloading in newInstance() method, as this requires no practical >> > change. >> > >> > How do you think? >> > >> > Thanks. >> > regards, aki >>
