Add the connectorInstance.xml file in the connector instance directory on creating a new connector instance

[GoogleCodeExporter]

What steps will reproduce the problem?
1. The connectorInstance.xml is part of each connector jar which has
certain advanced configuration options 
2. Users need to extract this file explicitly, update it and place it in
the connector-instance directory manually

What is the expected output? What do you see instead?
The Connector Manager should extract the connectorInstance.xml and place it
in the connector instance
directory(/connector-manager/WEB-INF/connectors/sharepoint-connector/instance_of
_connector/)
when a new connector is created.

This will mean that the users can directly edit the file without having the
hassles of extracting it and placing it in the connector-instance directory
manually.

This will also mean that the connector instances will have access to the
connectorInstance.xml and can make use of the configuration information
right from the time the connector is created.

Original issue reported on code.google.com by rakeshs101981@gmail.com on 16 Dec 2008 at 6:15

[GoogleCodeExporter]

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

• Added labels: Priority-High, Type-Enhancement

[GoogleCodeExporter]

We should address the sprouts design when we do this. I think we need to have 
two XML files, one for the 
sprouts and one for the defaults. Since connectorInstance.xml is already 
public, we should probably use that 
for the sprouts and create a new file, which does not get copied out of the JAR 
file, for the defaults. Naming 
ideas: connectorDefaults.xml, connectorPrototype.xml, connectorAbstract.xml I 
think I like defaults; the 
Livelink connector's sprout is called "Livelink_Enterprise_Server" (matching 
the connector type) while the 
defaults bean is called "Livelink_Enterprise_Server_Defaults".

We should also allow for the situation where sprouts are not split out into a 
separate file. I think that's 
straightforward, since then everything goes in the existing 
connectorInstance.xml, and there won't be a 
second file (or maybe it's easier if it exists but is empty).

Original comment by jl1615@gmail.com on 23 Feb 2009 at 6:59

[GoogleCodeExporter]

From:    johnl@vizdom.com
Subject: Upgrading connectorInstance.xml files
Date:    April 8, 2008 4:18:46 PM PDT

We're looking at the issues surrounding upgrading  
connectorInstance.xml when customers have custom copies. I think  
we've come up with a solution, which naturally requires changes to  
the Connector Manager. ;-)

If the default value of a property changes, or a new property is  
added, or even if an existing property is deleted, a customer with a  
custom connectorInstance.xml might have to merge their changes with  
the updated version in the connector jar file. This is of course not  
documented, and is an annoying step even if it were documented.

We looked around for a solution, and I think it's straightforward.  
The current beans look something like this:

        <bean id="Livelink_Enterprise_Server"

class="com.google.enterprise.connector.otex.LivelinkConnector">
            <property name="foo" value="bar" />
            <!-- ... -->
        </bean>

If we could split the default property values into one bean, located  
in the connectorInstance.xml file within the jar, and let customers  
specify another bean in a custom connector, then customers would not  
need to merge files when the standard copy changed, unless a  
customized property is deleted. Also, separating the customized  
properties from the default values for all the properties makes it  
easier to see at a glance what has been customized. Spring provides  
for just this scenario with child beans (Brett wants to call them  
sprouts). The new beans would look like this:

        <bean id="Livelink_Enterprise_Server"

class="com.google.enterprise.connector.otex.LivelinkConnector"
                parent="Livelink_Enterprise_Server_Defaults">
            <property name="foo" value="hoyhoy" />
        </bean>

        <bean id="Livelink_Enterprise_Server_Defaults">
            <property name="foo" value="bar" />
            <!-- ... -->
        </bean>

In this example, the customer has customized the foo property, but is  
using the default values for all of the other properties. This much  
works today so long as both beans are contained in the same  
connectorInstance.xml file. I'm planning on shipping with this  
variation in the 1.0.3 release this week. Even in the same file, with  
the merging headaches that entails, this cleanly separates customized  
property values from the default values.

Now the Connector Manager is using XmlBeanFactory to instantiate the  
beans, which restricts us to a single XML file containing beans.  
XmlBeanFactory is a trivial wrapper on the DefaultListableBeanFactory  
and XmlBeanDefinitionReader classes. If you use the other two classes  
directly, you can load bean definitions from multiple files. There is  
also provision for beans of the same name, and you can decide whether  
the first definition or the last definition wins. (I'm not sure why,  
since you can also of course vary the order in which you load the  
multiple files. It may be the case that wiring beans together forces  
a fixed order on the loading, so the option allows you to specify how  
duplicate definitions are treated.)

I haven't test this part, but I believe that we can then specify the  
following beans in the connectorInstance.xml within the jar files:

        <bean id="Livelink_Enterprise_Server"

class="com.google.enterprise.connector.otex.LivelinkConnector"
                parent="Livelink_Enterprise_Server_Defaults">
            <!-- THIS BEAN INTENTIONALLY LEFT BLANK -->
        </bean>

        <bean id="Livelink_Enterprise_Server_Defaults">
            <property name="foo" value="bar" />
            <!-- ... -->
        </bean>

Then users can customize the property values just by creating a  
custom connectorInstance.xml with the following bean:

        <bean id="Livelink_Enterprise_Server"

class="com.google.enterprise.connector.otex.LivelinkConnector"
                parent="Livelink_Enterprise_Server_Defaults">
            <property name="foo" value="hoyhoy" />
        </bean>

We can load both XML files, with the custom definition of the  
"Livelink_Enterprise_Server" bean overriding the standard definition.

In this model, the connector implementations can add new  
configuration properties and change existing default values without  
requiring customers to update their existing custom  
connectorInstance.xml files. In addition, customers only need to  
specify the customized properties, rather than copying all of the  
available properties, which is easier to maintain. Finally, connector  
implementations do not need to change to take advantage of this new  
capability. The existing bean definitions and the custom copies of  
them will work exactly the same under this model as they do under the  
current model. The use of sprouts is completely optional.

I wanted to see what everyone thought of this.

John L

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

• Changed state: Accepted

[GoogleCodeExporter]

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

• Changed state: Started

[GoogleCodeExporter]

I modified InstanceMap.makeConnectorDirectory() to extract
the connectorInstancePrototype resource (connectorInstance.xml)
from the TypeInfo and write it out to a connectorInstance.xml
file in the newly created connector instance directory.

I modified InstanceMap.removeConnector() to delete the
connectorInstance.xml file, but only if it is unmodified from
the original.  The largely reflects the current behaviour,
but might need to revisited when fixing CM Issue 87.

Lastly, I modified InstanceInfo and TypeInfo to allow
connectors to load from two sources of bean definitions:
connectorInstance.xml (extracted from jar and modifiable)
and connectorDefaults.xml (internal to jar).  This allows
connectors to add new properties or change default property
values with future upgrades even if the customer has a
modified connectorInstance.xml.  See CM Issue 114 for more
details.

Change Log:
----------
M  connector-manager/source/java/com/google/enterprise/connector/instantiator/In
stanceMap.java
   - makeConnectorDirectory() extracts connector instance prototype
     file into local connectorInstance.xml file.
   - removeConnector() deletes an unmodified local connectorInstance.xml file.

M  connector-manager/source/java/com/google/enterprise/connector/instantiator/In
stanceInfo.java
   - only have one string constant defined for "connectorInstance.xml"
   - replaced XmlBeanFactory with DefaultListableBeanFactory +
XmlBeanDefinitionReader
     so that we can load connector beans from both connectorInstance.xml and
     connectorDefaults.xml

M  connector-
manager/source/java/com/google/enterprise/connector/instantiator/TypeInfo.java
   - only have one string constant defined for "connectorInstance.xml"
   - add extraction and retrieval of connectorDefaults.xml resource,
     defaults for connectorInstance.xml

Original comment by Brett.Mi...@gmail.com on 17 Mar 2009 at 10:21

• Changed state: Fixed

[GoogleCodeExporter]

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

• Added labels: Milestone-Release_2.0.0