wsimport - ObjectFactory and XmlSeeAlso annotation on generated SEI?

[metro-3]

I have a question re: use of wsimport and these classes called ObjectFactory.java.  

When running [i]wsimport[/i] against a WSDL generated for class containing the @WebService annotation where the WSDL imports XSDs that are also generated for common shared value types that we use in our project, we are running into an issue w/ references to ObjectFactory.java.


Here is the snippet of the WSDL for the web service:

<definitions name="ACSRoleManagerService" targetNamespace="http://role.ws.services.component.acme.com" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://role.ws.services.component.acme.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <types>
    <xsd:schema>
      <xsd:import namespace="http://role.ws.services.component.acme.com" schemaLocation="ACSRoleManagerService_schema1.xsd"/>
    </xsd:schema>
    <xsd:schema>
      <xsd:import namespace="http://exceptions.util.acme.com/" schemaLocation="ACSRoleManagerService_schema2.xsd"/>
    </xsd:schema>
    <xsd:schema>
      <xsd:import namespace="http://dvo.services.component.acme.com/" schemaLocation="ACSRoleManagerService_schema3.xsd"/>
    </xsd:schema>
  </types>
...
....
....

The XSD for the particular namespace  http://dvo.services.component.acme.com/: (most elements omitted to save text)

<?xml version="1.0" encoding="UTF-8"?><xs:schema targetNamespace="http://dvo.services.component.acme.com/" version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:complexType name="Client">
    <xs:sequence>
      <xs:element name="oid" type="xs:long"/>
      <xs:element name="clientTypeOid" type="xs:long"/>
  ---
  ---
        ---
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="Role">
    <xs:sequence>
      <xs:element name="roleOid" type="xs:long"/>
      <xs:element minOccurs="0" name="roleName" type="xs:string"/>
        ---
        ---
        ---
    </xs:sequence>
  </xs:complexType>
</xs:schema>



[i]wsimport[/i] winds up generating packages for [b]com.acme.component.services.dvo[/b]  which contains classes for Client.java and Role.java respectively.  No problem there.  We have these already defined in a separate JAR that will be used between client and service sides (not ideal, but a constraint we have to manage).  

In the generated package is an ObjectFactory.java file...it looks as follows:

        //
        // Generated By:JAX-WS RI IBM 2.1.1 in JDK 6 (JAXB RI IBM JAXB 2.1.3 in JDK 1.6)
        //
        package com.acme.component.services.dvo;
        import javax.xml.bind.annotation.XmlRegistry;
        /**
         * This object contains factory methods for each
         * Java content interface ....  (comments omitted for brevity)
         *
         */
        @XmlRegistry
        public class ObjectFactory {
            /**
             * Create a new ObjectFactory that can be used to create new instances of schema derived classes for package: com.acme.component.services.dvo
             *
             */
            public ObjectFactory() {
            }
            /**
             * Create an instance of {@link Role }
             *
             */
            public Role createRole() {
                return new Role();
            }
            /**
             * Create an instance of {@link Client }
             *
             */
            public Client createClient() {
                return new Client();
            }
        }

However, we'd really like to get rid of the entire generated pacakge since our client proxy project will have the shared JAR of classes already.  The complication is that in the client proxy package, where it generates the NEEDED request and response wrappers and SEI, there is this XmlSeeAlso annotation that is generated on the SEI which points to these ObjectFactory.java classes:

        @WebService(name = "ACSRoleManager", targetNamespace = "http://role.ws.services.component.acme.com")
        @XmlSeeAlso({
            [b]com.acme.component.services.dvo.ObjectFactory.class,[/b]
            com.acme.component.services.ws.role.ObjectFactory.class,
            com.acme.util.exceptions.ObjectFactory.class
        })
        public interface ACSRoleManager {
        ---
        ---
        ---
        }

Is there some way to supress this from happening when running [i]wsimport[/i]???

We can't hack up GENERATED code like this to get rid of the [i]XmlSeeAlso[/i] annotation and we really don't want to deal with custom binding and "episode" files, etc. to get around this problem if at all possible. Any input would be appreciated.

Thanks
[Message sent by forum member 'mcs130' (mcs130@...)]

http://forums.java.net/jive/thread.jspa?messageID=368475

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Just trying again to see if anyone, perhaps from the JAXB team, might have some insight into this problem with this ObjectFactory issue.  

Thanks

Mark
[Message sent by forum member 'mcs130' (mcs130@...)]

http://forums.java.net/jive/thread.jspa?messageID=369702

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Clive Brettingham-Moore-3]

You do realize that this is exactly what binding/episode files are for?
Without them ensuring the correct types are picked up is just faith
based engineering.
Referencing the ObjectFactory provides a safety net that ensures all
types are enrolled when building the service context, but most basic
type usages patterns will work without.

That said, and I know I'm going to feel bad about suggesting this, if
you set the wsimport target version to 2.0 instead of 2.1 it wont use
XmlSeeAlso since that was only added in 2.1 (2.0 targeted generated
classes will work fine with a 2.1 runtime).

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

First - thank you so much for replying.  I have had little luck getting anywhere with this and we have just "worked around it" for the time being.  Ironically, I have tried this binding file concept on another issue:  http://forums.java.net/jive/message.jspa?messageID=367700#367700  and had no luck getting it to do what I wanted so I reluctantly gave up on it.   We had another project that used this same approach of "sharing" a JAR w/ compiled "value object" classes and discarded the "generated" ones.  We noticed that their generated SEI had no XmlSeeAlso annotation on it thus explaining why they did not face this issue.  Checking again, we've confirmed they were using 2.0 and not 2.1 which aligns w/ your suggestion.  I have found the external binding file approach to be quite frustrating especially when we tried to control the package where the Exception class got generated.  As reported in the thread link above - no matter what we did - it still landed in the same package where the request/response wrapper objects, SEI, etc get generated.

Again, thanks for your input.
[Message sent by forum member 'mcs130' (mcs130@...)]

http://forums.java.net/jive/thread.jspa?messageID=369705

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...