Costom Serializers in Weblogic 7.0.1

Question

I am having a problem preventing the servicegen ant task from attempting to create
java code for an unsupported type. The class is java.sql.Timestamp. Several
of my ejbs use the Timestamp class in their interfaces and servicegen complains
that Timestamp does not have a default ctor. That was expected. I then created
a custom codec class to serialize and deserialize the Timestamp class. The servicegen
portion of my build.xml file looks like this:
<servicegen
destEar="web-services"
warName="web-services.war"
contextURI="ws">
<service
typeMappingFile="typeMaps/wl7.xml"
ejbJar="myejb.jar"
targetNamespace="http://www.eoriginal.com/web-services"
includeEJBs="IndustrySession"
serviceName="IndustrySession"
serviceURI="/IndustrySession"
generateTypes="True"
expandMethods="True">
</service>
</servicegen>
The contents of the type mapping file (wl7.xml) is as follows:
<type-mapping>
<type-mapping-entry xmlns:p2="java:java.sql.Timestamp"
class-name="java.sql.Timestamp"
type="p2:Timestamp"
serializer="webservices.TimestampCodec"
deserializer="webservices.TimestampCodec">
</type-mapping-entry>
</type-mapping>
The Codec class (ser/deser) is in the classpath. The typeMappingFile element
of <service> appears to have no effect on the operation of the servicegen task.
If the typeMappingFile element is provided with a path to a type mapping file
servicegen should not complain about that type (class) since the custom ser/deser
will handle it.
Any ideas?
Thanks,
Tim Rea

Answer 1

Michael,
That makes sense. I will give it a try. I suspect the problem will be that I
have MANY "unsupported" types exposed through the ebj interfaces. If what you
are saying is strictly true then I will have to create MANY serializers when I
don't really need to.
Thanks for the response,
Tim
"Michael Wooten" <[email protected]> wrote:
>
Hi Tim,
I think the generateTypes attribute, on the <service> element, is an
"all-or-nothing"
type deal. Meaning that if you specify "false", no serializers/deserializers/codecs
will be generated for any "custom data types". If you specify "true",
it's going
to try to do it for every "custom data type", even the one that you already
created
the serializer for.
I agree that this is a little "brain-dead", but when you look at the
primary purpose
for these Ant tasks - generating "all the artifacts" for a Web Service,
I think
you can see where the BEA engineers were placing the emphasis :-)
The only way I can see around your problem, is to set the generateTypes
attribute
to "false". <servicegen> should insert the contents of your typeMaps/wl7.xml
file,
into the web-services.xml file, in the .war file for the web service.
If this doesn't work, attach a zip containing your webservices.TimestampCodec
class, and I'll see what kind of "workaround" I can come up with :-)
Regards,
Mike Wooten
"Tim Rea" <[email protected]> wrote:
I am having a problem preventing the servicegen ant task from attempting
to create
java code for an unsupported type. The class is java.sql.Timestamp.
Several
of my ejbs use the Timestamp class in their interfaces and servicegen
complains
that Timestamp does not have a default ctor. That was expected. Ithen
created
a custom codec class to serialize and deserialize the Timestamp class.
The servicegen
portion of my build.xml file looks like this:
<servicegen
destEar="web-services"
warName="web-services.war"
contextURI="ws">
<service
typeMappingFile="typeMaps/wl7.xml"
ejbJar="myejb.jar"
targetNamespace="http://www.eoriginal.com/web-services"
includeEJBs="IndustrySession"
serviceName="IndustrySession"
serviceURI="/IndustrySession"
generateTypes="True"
expandMethods="True">
</service>
</servicegen>
The contents of the type mapping file (wl7.xml) is as follows:
<type-mapping>
<type-mapping-entry xmlns:p2="java:java.sql.Timestamp"
class-name="java.sql.Timestamp"
type="p2:Timestamp"
serializer="webservices.TimestampCodec"
deserializer="webservices.TimestampCodec">
</type-mapping-entry>
</type-mapping>
The Codec class (ser/deser) is in the classpath. The typeMappingFile
element
of <service> appears to have no effect on the operation of the servicegen
task.
If the typeMappingFile element is provided with a path to a type mapping
file
servicegen should not complain about that type (class) since the custom
ser/deser
will handle it.
Any ideas?
Thanks,
Tim Rea