Community
Participate
Working Groups
The Connectivity runtime framework currently requires OSGi framework services for its operation. This enhancement calls for enabling support to run on OSGi-less platform, if needed, such as in a J2EE application without OSGi.
Created attachment 190464 [details] Initial Patch Initial patch on the o.e.d.connectivity and o.e.d.connectivity.sqm.core plugins.
Created attachment 190506 [details] Revised patch to include externalization of resource message
Linda, does this require Eclipse Indigo (3.7)? Or can I test it on Helios SR2 (3.6.2)?
Ok, a few things... It's difficult to separate the changes you've made to add convenience methods to the ConnectivityPlugin class vs. actual changes to support the OSGi-less platform. Obviously the PluginResourceLocator class is a big part of it. Can you describe what your changes do a bit so I have more context as I try diving into this code?
Another question and something we should discuss at the PMC level. Are we shifting to JDK 1.6 for the compile version in this release? Or are we staying at 1.5?
(In reply to comments #3, #4 and #5) It should work fine with Helios as well. RE: the kind of changes made, the Connectivity component has used the platform bundle services and default workspace services quite extensively. Without the Equinox OSGi platform, those services will not work. For example, Platform#getBundle call would return null. So in majority of the cases, I'd re-factored the calls made throughout the source code that calls directly to those platform services, to instead call the new utility methods in PluginResourceLocator and ConnectivityPlugin. Then in those utility methods, the implementation would first attempt to call the same platform services as before; and only if not available, it will then take the alternate approach. So, all the actual changes to support the OSGi-less platform are mostly encapsulated in those 2 utility classes. In the cases where Problem marker service is used, even though they are implemented in the Connectivity core component, they are not really relevant when running in a backend server environment. So I have simply added checking that if Bundle service is not available, it would skip the Problem marker processing. RE: the JDK 1.5 vs 1.6, all the changes made here would still compile under 1.5. So it seems to be a somewhat unrelated issue?
Linda, thanks for the context. That helps. Here's my take on this. My biggest concern is the lack of across the board unit tests that we could use to verify that this doesn't have unintended consequences. Overall I think the patch looks fine and should be ok. Condensing to a single way of locating resources makes a lot of sense. But as you pointed out in the PMC meeting yesterday, this will affect the enablement plug-ins and anyone who has enablement plug-ins outside of Eclipse such as the Oracle folks. I would send a broader message out to the DTP community at large asking for feedback on this before committing the changes. > RE: the JDK 1.5 vs 1.6, all the changes made here would still compile under > 1.5. So it seems to be a somewhat unrelated issue? It is and it's not related. My concern is that Eclipse is now being built on 3.6 and if we move to build in 3.6 we have build issues (in ConnectionAdapter in sqm.core at the very least). And we need to make that decision sooner than later to make sure all those bugs are taken care of. If we decide not to do it this release where we're already changing a number of core classes, when would we do it?
Patch looks ok with the reservations voiced in my previous comment.
(In reply to comment #7) Fitz, >> But as you pointed out in the PMC meeting yesterday, this will affect the enablement plug-ins and anyone who has enablement plug-ins outside of Eclipse That was not exactly what I meant. What I had pointed out was that some enablement plug-ins will also need enhancement in order to work in OSGi-less platform. I'm still working on those patches, and will open new BZ entries for them. RE: getting more extensive testing, it is no doubt needed. So to allow the community to be able to do more testing, it would be easier to test with a milestone build, instead of having to grab the source and apply the patch. And in fact, the sooner the changes are made available in a build, that would allow us more time to test and address related issues within the Indigo release cycle. RE: when to move to JDK 1.6, that is a good point and we should discuss it at our next PMC meeting. It is however beyond the scope of this BZ, and should be tracked and implemented separately. I don't think you are suggesting that such issue should hold up getting this enhancement in, right?
No, I'm not suggesting that it hold up delivery of this enhancement, just that the JDK issue needs to be addressed.
Great, thanks Fitz for the review. To make the changes available in a build for more extensive testing, I committed the changes for inclusion in the M6 build. Tagged with v201103110602. I will post a message to call for more community testing, after the build is available.
Here is to document how to specify the default workspace of the Connectivity plugin when running in OSGi-less platform. One can specify the directory path either 1) in a system property, under the name "{pluginName}_workspacepath" For example, in a VM argument: -Dorg.eclipse.datatools.connectivity_workspacepath=E:/myworkspace/org.eclipse.datatools.connectivity or 2) in an environment variable under the same name "{pluginName}_workspacepath" The system property, if a non-null value is set, takes precedence over that of the environment variable.
When you announce this to the community, it would be good to create a wiki that includes details like the summary of changes, what you can do now, and how to configure it as you just did. That way it's in one place and folks don't have to go hunting in BZ to find things. :)
My check-in has actually missed the M6 build today. That is probably better and less risky for such extensive changes anyway. The enhancement will thus get included in the beginning of the M7 cycle.
Created attachment 191561 [details] Iterative refinement of the PluginResourceLocator utility This patch includes refined enhancements in the PluginResourceLocator utility to support OSGi-less platform. Improved features include: * Added configurable parent workspace location, so a client appl won't need to specify separate workspace path property for each relevant plugin. When no workspace path is specifically defined for a plug-in, it will default to use the path named with the plug-in namespace, under a shared parent workspace path. The parent workspace path is the value of the system property named "org.eclipse.datatools_workspacepath" if set, or the value of the environment variable under the same name. * Locate a jar file entry in a bundle * Added caching of found plugin location to optimize repeated search * Added handling of multiple matching entries found for a plugin, e.g. when a plugin jar is installed in multiple paths on the Classpath * Remove trailing separator in the returned plugin path, to be compatible with the path returned by OSGi platform service Also added checking for the case when unable to locate the default cipher key file.
Fitz, Can you help take a look at the new patch (attachment 191561 [details])? It mainly refined the support for running in OSGi-less platform. To get this available in a build earlier for testing, I'd committed the patch; tagged with v201103191433. Let me know if you see any issues, and I can rollback if necessary. Thanks.
Linda, your patch looks fine. My concerns are the same as I had initially with making sure that we do as much testing of this as possible so there are no hidden issues. And we still need to make sure this is communicated with the community-at large.
Created attachment 192412 [details] Refactoring of PluginResourceLocator Another iteration of the PluginResourceLocator implementation. Includes exposing its utilities in public API (in a new package org.eclipse.datatools.connectivity.services) for other DTP plugins to consume. Also enabled the DTP Apache Derby implementation to locate its JDBC driver jars in an OSGi-less platform. Fitz, please help review. This should cover the planned implementation. If it looks ok, I plan to commit them at end of the week, and will then be ready for the community to test with, etc.
Created attachment 192475 [details] Refactoring of PluginResourceLocator v2 Slight refinement of the refactoring.
This looks pretty good actually. It certainly cleans up some of the gymnastics we had to go through to get the derby jar out of the plugin registry. Patch looks good.
Thanks Fitz. Committed latest patch (attachment 192475 [details]). Tagged with v201104090305.
A summary of this feature is documented on http://wiki.eclipse.org/DTP_1.9_M7_New_and_Noteworthy
Marking this enhancement as fixed. Please submit new Bugzilla entry for any new, related issues.
Created attachment 196719 [details] Patch to handle logging on OSGi-less platform Additional patch to use the JDK Logger, instead of Equinox Logger, when running on OSGi-less platform. Delivered patch to make the RC3 milestone. Tagged with v201105270956.
