search

PILLUTLAAVINASH / google-enterprise-connector-manager

Automatically exported from code.google.com/p/google-enterprise-connector-manager
0 stars 0 forks source link

Support Tomcat 6.0 & JRE 5 #119

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

Please use labels and text to provide additional information.

Original issue reported on code.google.com by mgron...@gmail.com on 28 Jan 2009 at 10:24

GoogleCodeExporter commented 8 years ago

Original comment by mgron...@gmail.com on 28 Jan 2009 at 10:24

GoogleCodeExporter commented 8 years ago

Original comment by Brett.Mi...@gmail.com on 26 Feb 2009 at 11:27

GoogleCodeExporter commented 8 years ago 
Look for replacing StringBuffer uses with StringBuilder.
For instance:
projects/connector-manager/source/java/com/google/enterprise/connector/servlet/G
etConnectorInstanceList.java
  r1554   line 128:
128:         StringBuffer buffer = new StringBuffer();
Too bad we're not on JDK 1.5 yet - this should really use StringBuilder.

Original comment by Brett.Mi...@gmail.com on 10 Mar 2009 at 6:11

GoogleCodeExporter commented 8 years ago

Original comment by jl1615@gmail.com on 10 Mar 2009 at 7:32

GoogleCodeExporter commented 8 years ago 
Move to Java 5 syntax added to Connector Manager trunk with revision r1704 on 
15 April 2009:

This change modifies the Connector Manager sources to compile cleanly
under Java 5 (1.5).  Neary all Collections, Lists, Sets, Maps, etc,
and several interfaces (like Comparable) were appropriately parameterized.

Particular attention was made to the SPI.

In general, I avoided easy-outs like <?> parameters and @SuppressWarnings,
however, they were often necessary when dealing with Spring getBean(),
JSON, and Properties.  [I have no idea why Properties.properyNames()
returns Enumeration <?>, rather than Enumeration <String>, or why Properties
implements Map <?, ?>, rather than Map <String, String>.]

I modified build.xml javac task as follows:
  - changed -target and -source switches from 1.4 to 1.5
  - additional warnings with "-Xlint -Xlint:-serial" which turns on most
    warnings, except serializaion UUID warnings.
  - javatest target aslo disables "deprecated" warnings to avoid flagging
    tests for deprecated features.

Going into this, my understanding of Generics was less than ideal,
so some things might have been done better.

There is probably some improvement that can be with parameterization
with Spring.

I replaced many uses of StringBuffer with the faster StringBuilder.

I used boxing/unboxing a half dozen times.

I replaced many Iterator based-loops with for-each loop syntax.

I replaced the Iterator<String> return with Set<String> return for
Instantiator.getConnectorNames() and Instantiator.getConnectorTypeNames().

I removed unnecessary casts.

I added @Override annotations for methods that override superclass methods.

Original comment by Brett.Mi...@gmail.com on 16 Apr 2009 at 10:19

GoogleCodeExporter commented 8 years ago

Original comment by mgron...@gmail.com on 6 May 2009 at 9:37

GoogleCodeExporter commented 8 years ago

Original comment by Brett.Mi...@gmail.com on 16 May 2009 at 8:45

GoogleCodeExporter commented 8 years ago 
Current testing has not revealed any issues.

Original comment by mgron...@gmail.com on 20 May 2009 at 1:17

GoogleCodeExporter commented 8 years ago 
Subject:    CM 2.0 & Tomcat 6.0 deployment notes
From:   Brett.Michael.Johnson
Date:   May 17, 2009 6:50:18 PM PDT

As requested by Rakesh, I have updated the deployment spreadsheet at:
http://spreadsheets.google.com/ccc?key=pdpgETbhi0LvmZdiYp2DjTw&hl=en
I made changes to most pages of the spreadsheet, not just Connector
Manager.

Our plan is to deploy this using Tomcat 6.0.18 requiring only a
Java 5 JRE.  Previous installations required a JDK.

Packaged in the archive I uploaded are the modified setclasspath
scripts from Tomcat that will be required to use the connector-logging
package.

Several of our connectors wish to load jars into Tomcat's shared/lib
directory.  In Tomcat 6, this directory is no longer created on
deployment, nor is it on the default classloader.  We should determine
whether these jar files need to be in Tomcat/shared/lib or if it is
sufficient to place them in Tomcat/webapps/connector-manager/WEB-INF/lib.
If we still need to use Tomcat/shared/lib, information on configuring
its use can be found at:
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
http://marc.info/?l=tomcat-user&m=116230356524071&w=2

One connector (sharepoint?) wanted catalina.jar in Tomcat/shared/lib.
Does it still rely on Tomcat internal classes?

I believe the Documentum connector will no longer require commons-httpclient.

In the past, json.jar seems to have been part of the Connector Manager
deployment.  AFAIK, the Connector Manager doesn't use json in deployment
(although it does use it in tests).  Perhaps this could get installed with
the one or two connectors that use it.  I do notice that the Documentum
Connector installs a separate license file for json.  We should make sure
that its license is installed if the jar file is.  If if will continue to
be installed by the CM, we should make sure its separate license is installed
as well.

Original comment by Brett.Mi...@gmail.com on 20 May 2009 at 5:35