search

evantrimble / force-metadata-jdbc-driver

Automatically exported from code.google.com/p/force-metadata-jdbc-driver
1 stars 0 forks source link

Driver is still dependent on Axis and it's dependencies #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
When reading this page:
http://code.google.com/p/force-metadata-jdbc-driver/wiki/Useage
...there is an implication that only release 1.2 and lower are dependent on 
Axis and it's dependencies.  However, I found that even with the latest 
release, 1.4, the Service.java is still implemented with Axis and stuff from 
javax.xml.rpc.  

I re-implemented Service.java to use the new web service client:

http://code.google.com/p/sfdc-wsc

This gets rid of Axis and it's dependencies as well as any references to 
javax.xml.rpc.  Also since WSC uses pull-parsing, it may be faster.

The code is here:

http://chriswolf.heroku.com/page_attachments/0000/0022/force-metadata-jdbc-drive
r-1.4.cw-sources.jar

Original issue reported on code.google.com by cw10...@gmail.com on 31 Jan 2011 at 4:27

GoogleCodeExporter commented 9 years ago 
These code changes were based on release 61 from svn.

Original comment by cw10...@gmail.com on 31 Jan 2011 at 4:31

GoogleCodeExporter commented 9 years ago 
If cutting down dependencies is the aim, wouldn't it be better to just move to 
JAXB 2 which is in Java 6 so no extra JARs would be needed at all?

Original comment by keith.clarke.claimvantage@gmail.com on 31 Jan 2011 at 4:36

GoogleCodeExporter commented 9 years ago 
You're right - if reducing dependencies was the sole motivation, but the other 
motivation is the better performance of
pull-parsing.  For example, they are using WSC in the Android (mobile) 
Salesforce API client because JAXB is known to
be too heavy weight for mobile use.  Also consider a user, that for some 
reason, may want to use JDK-1.5, in that case,
JAXB is not included, so it would be better to have two jar dependencies then 
six.  Last point is that the implementation
of Service.java is a bit more straight-forward then with JAXB/Axis.

    -Chris

Original comment by cw10...@gmail.com on 31 Jan 2011 at 9:11

GoogleCodeExporter commented 9 years ago 
I've added the sentence "The jars contained in depends.zip including the Axis 
jars are required in both cases" to 
http://code.google.com/p/force-metadata-jdbc-driver/wiki/Useage to make the 
dependency explicit rather than implicit.

Wanting to use a different web service stack is more of a change request than a 
defect.

Original comment by keith.clarke.claimvantage@gmail.com on 13 Feb 2011 at 1:28

GoogleCodeExporter commented 9 years ago 
Switching from Axis to WSC was minor compared to all the other changes I needed 
to implement to use the driver with other then SchemaSpy, i.e. getTypes(), 
indexed column getters on ForceResultSet, etc.  Were you planning to integrate 
those changes?

Original comment by cw10...@gmail.com on 13 Feb 2011 at 1:40

GoogleCodeExporter commented 9 years ago 
Agreed - see my comment on the other issue you created.

Original comment by keith.clarke.claimvantage@gmail.com on 13 Feb 2011 at 1:50

GoogleCodeExporter commented 9 years ago 
Ok, back to the issue with Axis vs. WSC.  I still don't understand the 
advantage of using Axis. It's slower and requires more dependencies.  You said 
it's "baked" into 1.6, however, the only part 1.6 gives you is XML data binding 
(i.e. "JAXB", package "javax.xml.bind.*").  

If you consider Salesforce developer docs to be authoritative, you will see 
they got rid of any reference to Axis in their "Getting Started" doc, including 
the sample code, which used to be based on Axis, but now is using WSC.

http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_quickstart_st
eps.htm#step_3_import_the_wsdl_file_into_your_development_platform

Original comment by cw10...@gmail.com on 16 Feb 2011 at 11:24

GoogleCodeExporter commented 9 years ago 
If we limit ourselves to the 3 choices of Axis, JAXB and WSC then I agree that 
Axis is the least attractive. I only chose it because at the time it seemed to 
be the most commonly used approach.

So that leaves us the choice between moving to WSC or moving to JAXB. My 
opinion is that JAXB makes more sense so that there are no additional jars 
required. If you have data that shows performance is an issue then that would 
be a factor but here we are only dealing in small amounts of metadata. I'm 
wondering if Java 1.6 is really an issue anymore given how long its been 
available; I also note that WSC's jars are compiled for 1.6 by default.

Original comment by keith.clarke.claimvantage@gmail.com on 16 Feb 2011 at 11:55

GoogleCodeExporter commented 9 years ago 
If you would like to discuss offline, my email address is cw10025   AT gmail.

Original comment by cw10...@gmail.com on 16 Feb 2011 at 4:04

GoogleCodeExporter commented 9 years ago 
Per offline discussion, I offer a parameterized Service implementation which 
detects the runtime JRE version.  If it's 1.5 it will use an implementation of 
MetaDataService (a new interface extracted from the former Service class) which 
is implemented with WSC and will use the partner-20.jar (WSC generated classes) 
you will also need the wsc-20-1.5.jar (WSC compiled with java-1.5).

If it's running 1.6 it will use an implementation of MetaDataService which is 
implemented using the built-in JAX-WS stack of JRE-1.6, in this case you use 
the partner-jaxws-21.jar (JAX-WS generated classes).

In summary, running with java-1.5 requires one additional jar, wsc-20-1.5.jar.  
Either 1.5 or 1.6 will need it's own partner.jar corresponding to the WS 
service stack in use, i.e. 

 * for 1.5: force-metadata-jdbc-driver-1.4.2.cw.jar + partner-20-1.5.jar + wsc-20-1.25.jar
 * for 1.6: force-metadata-jdbc-driver-1.4.2.cw.jar + partner-jaxws-21.jar

I also implemented an additional property called "wsimpl" to force the use of a 
particular stack, i.e. wsimpl=jaxws forces JAX-WS, while wsimpl=wsc forces 
using WSC,
this property is NOT required and is only added for development.

Alternatively, two "jumbo" jars could be assembled composed of the two above 
combinations of jars, such that only one jar is required and there are two 
variations corresponding to the version of the JRE being used.  

I think the code in source control still has JDBC-3/JRE-1.6 stuff added, so I 
could not compile with 1.5, therefore I patched the same code I sent earlier, 
sorry about that.

In the "jumbo" jar case, if it was me, I would just build everything 
with JDK-1.5 and use WSC and forget about JAX-WS, such that you have a 
single jar (force-meta + wsc + partner) to run either on 1.5 or 1.6.

Original comment by cw10...@gmail.com on 17 Feb 2011 at 10:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Do not use "force-metadata-jdbc-driver-1.4.cw-sources.jar" which I attached in 
my last comment - use "force-metadata-jdbc-driver-1.4.2.cw-sources.jar.

I am also attaching the jars needed for WSC (built with 1.5).

Original comment by cw10...@gmail.com on 17 Feb 2011 at 10:34

Attachments:

GoogleCodeExporter commented 9 years ago 
FYI, in the attached code, in class "com.claimvantage.force.jdbc.Service", in 
the default constructor, I accidentally left debugging logging on, so you would 
want to change the line that reads, "logger.setLevel(Level.ALL);" to 
"logger.setLevel(Level.INFO);"

Original comment by cw10...@gmail.com on 17 Feb 2011 at 10:51

GoogleCodeExporter commented 9 years ago 
Here is the Eclipse project for the JAX-WS implementation.

Also I already discovered a minor bug in the uploaded code - the timing code
to measure login time and getSObjectTypes time is off by a factor of 1000 - 
since it's using System.nanoTime(), we need to divide by 1000000 to arrive at 
milliseconds (the code is dividing by 1000).

Original comment by cw10...@gmail.com on 17 Feb 2011 at 11:03

Attachments: