Bugzilla – Full Text Bug Listing
| Summary: | Contribution of JAX-WS DOM tools | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Webservices | Reporter: | Danail Branekov <danail.branekov> | ||||||||||||||
| Component: | jst.ws.jaxws | Assignee: | Project Inbox <wtp.inc.jaxws-inbox> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Shane Clarke <shane_clarke> | ||||||||||||||
| Severity: | enhancement | ||||||||||||||||
| Priority: | P3 | CC: | bogdan.vatkov, keith.chong.ca, oisin.hurley | ||||||||||||||
| Version: | unspecified | Keywords: | plan | ||||||||||||||
| Target Milestone: | 3.2 M3 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | jaxws | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Danail Branekov
Hi Danail, Thank you for the contribution. I've had a look at the code and can run it successfully and see the items outlined above and it looks great. I do have a question regarding the execution environment and plug-in dependencies for some of the plug-ins. All but one of the plug-ins have a required execution environment of JavaSE-1.6 and the version ranges for the plug-in dependencies are set to a minimum level or Eclipse 3.5 Would it be possible to lower the required execution environment to J2SE-1.5 and the required versions of the plug-ins to Eclipse 3.4.x levels? I ask because the minimum requirements for the current code base is Eclipse 3.4.x, WTP 3.0.x with it's dependencies (EMF 2.4.x, GEF 3.4.x) plus some bundles from Orbit (javax.jws, javax.xml.ws ...). I did try lowering the execution environment and plug-in dependencies here to those levels. Fixed the compilation errors and it seemed to run fine. It wasn't an exhaustive test but the Project Explorer, properties view and validation all looked to be working. Hi Shane, These tools were originally developed for Java-1.5, Eclipse 3.3 and WTP 2.0.x. Later on we increased the execution environment due to adopting newer Eclipse releases and JDK6. You can in fact remove all plugin dependencies restrictions. They are automatically added by the plugin.xml editor and this is the reason that they exist. I will provide a patch with these changes later on. Best regards, Danail Hi Danail, I'm going to start putting together a few contribution questionnaires to get the process going. A couple of questions about the jMock jars. Are they all unmodified? And have you got links to the source code for those jars? Also for the unit tests i noticed a reference to an internal Sun ByteInputStream class in there. Would it be possible to replace that with public API? Thanks, Shane Created attachment 142101 [details]
JAX-WS DOM tools plugins (v2)
Hi Shane, Please find attached a version which lowers the execution environment to J2SE-1.5 and removes the required bundle versions. The usage of the internal ByteInputStream class is also removed. And here are the answers to your questions - All org.jmock plugin jars are not modified - Check http://jmock.org/repository.html for getting the JMock latest source code and http://www.jmock.org/dist/ for downloading JMock 1.1 (included in the org.jmock plugin) binaries and source code - Check http://sourceforge.net/projects/cglib/files/ for downloading the cglib-nodep-2.2 binary and source code BTW, do you have any very rough estimation when this contribution could get out of its incubation phase? We need to somehow estimate when we should adapt our JAX-WS dependend code with regards to adoption of newer Eclipse releases. Regards, Danail Hi Danail, Thank you for the update and the links. >BTW, do you have any very rough estimation when this contribution could get out >of its incubation phase? We need to somehow estimate when we should adapt our >JAX-WS dependend code with regards to adoption of newer Eclipse releases. This contribution if approved will graduate from incubation as part of the JAX-WS Tools 1.0 release. We haven't officially set a date to aim for just yet for that 1.0 release. But right now looking at the resources available and what's left to do to bring it up to the standard of a 1.0 release i'd be looking at next June as an estimate. Outside of all the enhancements and bugs there are other requirements that we'll need to satisfy as well before graduating including building up the committer, user and adopter communities: http://wiki.eclipse.org/Development_Resources/HOWTO/Incubation_Phase Speaking of committers. Could i get the name(s) of the committer(s) you'd like nominate to work on the contribution/integration and we'll look to start the election process as well. Also just wanted to check to see if there's any possibility in using EasyMock instead of jMock for the unit tests. I ask because EasyMock has already gone through the Eclipse IP process and has been approved. We'd just have to apply to reuse it. If not, then that's not a problem and i'll start on the jMock submission. Hi Shane, I would nominate myself for committer. In case you need more information besides name, employer and e-mail, let me know. Regarding JMock - refactoring existing tests to use EasyMock instead of JMock would definitely be quite an effort. I think that getting JMock in Eclipse is worth the approval process since in my opinion it sometimes lets developers implement expectations much easier than in EasyMock. Of course, EasyMock is the better choice in other situations. However, we could consider getting JMock2 instead of JMock1 in the org.jmock plugin. At the time we started writing these tests JMock2 was still unavailable. According to the JMock documentation, it should not be a big deal to run JMock1 tests with JMock2. Speaking of test frameworks, has Abbot (http://abbot.sourceforge.net/doc/overview.shtml) passed the approval process? The web service wizards implementation, which we plan to contribute in near future as well, uses Abbot for UI testing. Regards, Danail > I would nominate myself for committer. In case you need more information > besides name, employer and e-mail, let me know. Excellent. I think i have all the information i need. > However, we could consider getting JMock2 instead of JMock1 in the org.jmock > plugin. At the time we started writing these tests JMock2 was still > unavailable. According to the JMock documentation, it should not be a big deal > to run JMock1 tests with JMock2. I downloaded jMock 2.5.1 to have a look, replacing the jars in the attached org.jmock plugin. I'm not really familiar with jMock but 2.5.1 looks to be a completely different API to that found in jMock 1.1.0 for writing tests. Leads to unresolved imports and compilation errors in the test plugins. It also mentions porting in the jMock 1 to jMock 2 upgrade documentation. So it looks like there could be a good deal of effort required to port from one version to the other. > Speaking of test frameworks, has Abbot > (http://abbot.sourceforge.net/doc/overview.shtml) passed the approval process? > The web service wizards implementation, which we plan to contribute in near > future as well, uses Abbot for UI testing. No, it looks like Abbot has never been submitted for use by any Eclipse project. Hi Danail, Could we rename the navigatorContent name label in the org.eclipse.ui.navigator.navigatorContent extension point in org.eclipse.jst.ws.jaxws.sapnw.dom.integration plug-in. from 'SAP Naviagator Content WS' to 'JAX-WS Web Services Elements' or similar. It'd be more readily identifiable in the customize view dialog given the context. > Could we rename the navigatorContent name label in the
> org.eclipse.ui.navigator.navigatorContent extension point in
> org.eclipse.jst.ws.jaxws.sapnw.dom.integration plug-in.
>
> from 'SAP Naviagator Content WS' to 'JAX-WS Web Services Elements' or similar.
Yes, of course. I thought that I have removed all SAP naming from the plugins, but it seems I have missed this one. Would you prefer a patch file, or a ZIP with all plugins? I am working against my own CVS locally and I am not sure whether a patch file for it would be useful for you
Regards, Danail
A zip file with the updated plugins would be best. Thanks. Created attachment 142262 [details]
JAX-WS DOM tools plugins (v3)
Here is the ZIP with SAP labels removed
Regards, Danail
The last stable release of jMock 1 was version 1.2.0 so i think it's best to go with that version. Created attachment 142348 [details]
JAX-WS DOM tools plugins (v4)
This is the next version of the source code which incorporates JMock 1.2.0.
I have run all tests with it to verify that everything is OK.
Regards, Danail
HI Danail, It looks like there's a strong possibility that the cglib-nodep jar will not make it through the Eclipse due diligence review process. We're trying to resolve the issues to move the process on and i've contacted the cglib team to try and do that but looking at previous attempts to resolve those same issues it's unlikely. So i think we need to start looking at alternatives to jMock/cglib for implementing the tests. Hi Danail, I've got some questions back from the Eclipse IP team that they need clarification on that i'll need your help with. The questions are mostly related to the CGLIB, jMock and test related source code in the contribution. And those questions are: 1. There are a few more @authors tags that appear in the contribution. Plamen Pavlov Mladen Tomov d042817 d038406 Can you confirm that these authors are employees of SAP and does d042817 or d038406 equate to anyone else already listed as an author. 2. CGlibMockCL.java contains a comment of "* is based on CGLIB, so it's capable of mocking classes and interfaces". What does "based on" mean in this situation? 3. There's a question about AbstractMockObjectTestCase.java. Did this file originate from jMock? 4. Can you confirm the origin of BeforeAfterEnabler.java and/or provide some input of what this file is used for? Thanks, Shane Hi Shane, It is a shame for me that I have missed to mention my colleague Plamen Pavlov among the contributed source code authors. He definitely deserves credits for his work. The other authors are also SAP employees. I will substitute their internal IDs with the real names. "d042817" is a colleague called Joerg Dehmel and "d038406" stands for Andre Hildebrandt. They have small contribution to the DOM tools implementation but you will see their names in the WS wizards integration. Regarding CGlibMockCL - this class is an extension of the standard JMock proxy (org.jmock.core.AbstractDynamicMock) and uses CGLib means to mock classes (this is what "based on CGLIB" in the javadoc means). The class indirectly extends the standard JMock proxy class and "enriches" it via the CGLib net.sf.cglib.proxy.Enhancer API. Further on, the org.eclipse.jst.ws.jaxws.sapnw.testutils.jmock.MockObjectTestCase (the parent of all our JMock tests) class creates instaces of CGlibMockCL in its mock() methods. The very tests use these instances instead of creating mocks via calling "new org.jmock.Mock()" by themselves. The org.eclipse.jst.ws.jaxws.sapnw.testutils.jmock.AbstractMockObjectTestCase class is meant to be the parent class of all our jmock tests. This class is implemented within SAP and its purpose is to extend the standard JMock test fixture (org.jmock.core.MockObjectSupportTestCase) with generics thus making writing junit tests a bit easier. BeforeAfterEnabler is also implemented within SAP. Its purpose is to override the "runBare" method of junit's TestCase and provide plugs for executing code before and after test methods execution (besides the standard "setUp" and "tearDown"). The is achieved via the provided IBeforeAfterEnabled instance in the class constructor. The very usage of the BeforeAfterEnabler class is in org.eclipse.jst.ws.jaxws.sapnw.testutils.jmock.MockObjectTestCase. You can see that it overrides the "runBare" method and delegates to BeforeAfterEnabler.runBare() Regards, Danail Hi Danial, Could you give me an idea of what your thoughts are on the jMock/cglib situation? So far I haven't been able to get any feedback from the cglib team on their devlist to move the cglib-nodep submission forward. And the cglib-nodep submission is blocking the jMock submission. We can continue to take a wait and see approach there but i don't think that's going to get us anywhere. Is there a possibility in reimplementing the tests? Thanks, Shane Hi Shane, Refactoring junit tests from JMock to EasyMock will be definitely a significant effort but the absence of cglib would be a problem. The reason to insist on getting cglib in eclipse is that as far as I am aware, this is the most famous byte code modification framework. It is also used in the EasyMock class extension - http://easymock.org/EasyMock2_0_ClassExtension_Documentation.html , section Requirements. I know that JUnit gurus disregard such an approach, but there are situations where this is inevitable. For example, in our code we have a JUnit test which tests the action which navigates from the web service node to the EJB node in project explorer. In order to create the very action instance you need an instance of org.eclipse.jface.viewers.StructuredViewer (check the org.eclipse.ui.internal.navigator.extensions.CommonActionExtensionSite cinstructor). The StructuredViewer class does not have an interface which means that if one cannot mock StructuredViewers, then he would have to take a real structured viewer and pass it as parameter. Thus the junit test isolation is broken because it involves interraction with real StructuredViewers whose implementation might or might not be adequate. Extending StrucutredViewer with some test implementation is a solution which is superfluous and would prevent the test from compiling in case StrucutredViewer "interface" changed in an incompatible manner in future. Does eclipse offer some approved library for bytecode modification? We could research how we could substitute CGLib with it. Regards, Danail Hi Danail, > Does eclipse offer some approved library for bytecode modification? We could > research how we could substitute CGLib with it. ASM http://asm.ow2.org/ versions 3.1 and 3.2 have been approved. That's used by CGLIB. BCEL http://jakarta.apache.org/bcel/ version 5.2 has also been approved. Both are available from Orbit http://download.eclipse.org/tools/orbit/downloads/drops/R20090529135407/ Thanks, Shane OK, then I could try refactoring the test plugin to start using ASM or BCEL. This would however take some time and efforts. I think that the most feasible approach (in case everything with JMock itself is fine) would be to remove CGLib and the tests which fail because of its absence. These are a couple of tests which represent a pretty insignificant piece of all tests. Later on, when I either implement class mocking or refactor the implementation to use interfaces I could contribute them as well. Or you would prefer to get everyhting right in one step? Regards, Danail (In reply to comment #23) > OK, then I could try refactoring the test plugin to start using ASM or BCEL. > This would however take some time and efforts. > > I think that the most feasible approach (in case everything with JMock itself > is fine) would be to remove CGLib and the tests which fail because of its > absence. These are a couple of tests which represent a pretty insignificant > piece of all tests. Later on, when I either implement class mocking or refactor > the implementation to use interfaces I could contribute them as well. > Or you would prefer to get everyhting right in one step? > > Regards, Danail > I agree, i think the best approach would be to remove the cglib-nodep and jmock-cglib jars along with the cglib references in the source and update the submissions. JMock will still however have to complete a review once the cglib dependency is removed. Hopefully everything will be ok there. I think there's some value in bringing in the code in two tranches, having the material that is independent of cglib encumbrance arrive in CVS first, and have the rest follow later after refactor/approval. Created attachment 143478 [details]
JAX-WS DOM tools plugins (v5) - no CGLib
Here is the next version of the tools. Changes refere to test plugins only:
- The CGLib libraries (jmock-cglib-1.2.0.jar and cglib-nodep-2.2.jar) are removed from the org.jmock plugin
- The org.eclipse.jst.ws.jaxws.sapnw.testutils.jmock.CGlibMockCL class has been deleted
- The org.eclipse.jst.ws.jaxws.sapnw.testutils.jmock.PrefixPackageNamingPolicy class has been deleted
- Due to CGLib absence the following failing tests have been deleted:
* org.eclipse.jst.ws.jaxws.sapnw.dom.integration.tests.navigator.actions.NavigateToImplementationActionTest
* org.eclipse.jst.ws.jaxws.sapnw.dom.integration.tests.navigator.actions.OpenWSResourceActionTest
* org.eclipse.jst.ws.jaxws.sapnw.dom.integration.tests.navigator.actions.WSActionProviderTest
These tests are going to be provided later on.
Created attachment 144509 [details]
JAX-WS DOM tools plugins (v6)
Gave credits to Shay Banon for the original idea of org.eclipse.jst.ws.jaxws.sapnw.testutils.jmock.testcases.BeforeAfterEnabler
Main part of this contribution has been approved. We're still waiting on JMock. I've checked in the feature and main plug-ins. I'll wait for the ok on JMock before checking in the tests. The feature and plug-ins can be found here (dev.eclipse.org): /cvsroot/webtools/incubator/webservices/features/ /cvsroot/webtools/incubator/webservices/plugins/ I had to make a few changes to the feature and plug-ins: Plug-ins: For each plug-in i added an about.html file and i added the word incubation to the bundle.name. It's a requirement. For the org.eclipse.jst.ws.jaxws.sapnw.dom.runtime plug-in i added a dependency on javax.jws (import-package) to fix a compilation problem caused by the drop to Java 1.5. Feature. I added a .feature suffix to the org.eclipse.jst.ws.jaxws.sapnw.dom feature name and added a license.html, epl-v10.html, eclipse_update_120.jpg image and a feature.properties file. The feature.properties file contains a text version of the feature update license and SAP AG copyright information. I've also added an additional feature (org.eclipse.jst.ws.jaxws.sapnw.dom_sdk.feature) in preparation for integrating into the build system. For the tests they'll be checked into: /cvsroot/webtools/incubator/webservices/tests/ There are a couple of compilation problems in the tests all of which are related to the drop to Eclipse 3.4.x and Java 1.5. I can fix these before or after i checkin the code. org.eclipse.jst.ws.jaxws.sapnw.dom.integration.tests.navigator.actions.WSActionAbstractTest Line 810. We can remove the "myPluginid" argument in the call to CommonActionExtensionSite(). (Eclipse 3.5 constructor) org.eclipse.jst.ws.jaxws.sapnw.dom.runtime.tests.dom.persistence.Jee5WsDomRuntimeExtensionTest Line 127. We can change the call to the IOException constructor to pass in the localized message. (Java 1.6 constructor). The drop to Java 1.5 is also causing two tests to fail: org.eclipse.jst.ws.jaxws.sapnw.dom.runtime.tests.dom.persistence.sync.MethodParamsSynchronizationTests * test_voidMethodWithNonParameterizedHolderParam() Line 157 * test_voidMethodWithParameterizedHolderParam() Line 170 Failure was junit.framework.AssertionFailedError: expected:<INOUT> but was:<IN> I've looked into it and javax.xml.ws.Holder cannot be resolved. org.eclipse.jst.ws.jaxws.sapnw.dom.runtime.persistence.sync.ParameterSynchronizer Line 125 returns null. If we can configure the test project used in those tests with Java 1.6 it should resolve that problem. We setup the existing test cases that way so it should be doable. Hi Shane, Once you get the tests source code in CVS I could check the failing tests and fix them. Regards, Danail Hi Danail, jMock has received preliminary legal approval that allows us to check it into CVS. It's now checked in along with the test plug-ins. We can discuss integrating the code on the wtp-incubator dev list. Marking this bug as fixed. Code is in CVS and a committer elected. Thanks, Shane Comment on attachment 144509 [details]
JAX-WS DOM tools plugins (v6)
Adding iplog flag
|