I thought about this a while because I didn't like the idea of adding another bundle specific jar.
I think we could opt for using DynamicImport-Packge to workaround the classloading issue in OSGi. In that way, we can keep the current design. Any other option will require more discussion. I'll update OLINGO-632 accordingly 2015-04-27 16:44 GMT+02:00 Aki Yoshida <[email protected]>: > 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 >>>
