>
> On Wed, Sep 24, 2008 at 7:06 PM, Coe, Colin C. (Unix Engineer)
> <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> >
> > Hi again
> >
> > Ok, so far I have
> >
> java/code/src/com/redhat/rhn/frontend/xmlrpc/serializer/Kickst
> artDataSer
> > ializer.java and
> >
> java/code/src/com/redhat/rhn/frontend/xmlrpc/system/profile/Se
> rverProfil
> > eHandler.java, both attached.
> >
> > I've updated
> > java/code/src/com/redhat/rhn/frontend/xmlrpc/handler-manifest.xml to
> > register the API namespace and
> >
> java/code/src/com/redhat/rhn/frontend/xmlrpc/serializer/Serial
> izerRegist
> > ry.java to register the serialiser.
>
> Yep that's sounds good.
>
> > When I test the getCustomOptions API with a perl script I see the
> > debugging line "Custom, in API call" which I put in
> > ServerProfileHandler.java but I don't ever see "Called
> > KickstartCustomOption serializer" which I put in
> > KickstartDataSerializer.java.
> >
> > So I guess the question now is, what am I doing wrong the
> the serialiser
> > is being ignored?
> >
>
> So in ServerProfileHandler.java you have the following:
>
> ----------
> public Object[] getCustomOptions(String sessionKey,
> String ksLabel) {
> User user = getLoggedInUser(sessionKey);
> KickstartData k =
> KickstartFactory.lookupKickstartDataByLabelAndOrgId(
> ksLabel, user.getOrg().getId());
> SortedSet options = k.getCustomOptions();
> System.out.println("Custom, in API call");
>
> return options.toArray();
> }
> ----------
>
> You have a KickstartData object, k, which has some custom options.
> You ask for them and get back a SortedSet of custom options. What
> is in the SortedSet? i.e. what class is in it? That is the
> most important part of this api call. Because in the following
> line you are converting the SortedSet of class ??? into an array
> of ???.
>
> What the XML-RPC framework will do is as follows:
>
> 1) it will see you are returning an array and call the ArraySerializer
> which is internal to the framework.
>
> 2) Then that serializer will see that the classes inside of the
> array are of type ??? and proceed to look for a serializer that
> matches class ???
>
> In order to find out what is inside the SortedSet, do this:
>
> SortedSet options = k.getCustomOptions();
> Object o = options.first();
> if (o != null) {
> System.out.println(o.getClass().getName());
> }
> else {
> System.out.println("first option is null");
> }
>
> The value returned by getClass().getName() is what needs a Serializer.
>
> Based on your getCustomOptions() api call, KickstartDataSerializer is
> incorrect because it will only get called if you are returning a
> KickstartData object.
>
> pause :)
>
> I did a bit more digging, KickstartData.hbm.xml shows that
> customOptions is a set of KickstartCommand objects. So what
> you need to create is a KickstartCommandSerializer NOT
> a KickstartDataSerializer.
>
> getSupportedClass() should return KickstartCommand.class;
>
> KickstartCommand has the following attributes:
>
> Long id;
> String arguments;
> Date created;
> Date modified;
> KickstartCommandName commandName;
> KickstartData kickstartData;
> Integer customPosition;
>
> Notice the datatypes of the above. All but 2 are basic types, i.e.
> Long, Integer, String, Date. The XML-RPC framework has the ability
> to serialize these already, so no work is needed for those aside
> from something like helper.add("id", option.getId());
>
> But as you can see it has 2 more types KickstartCommandName and
> KickstartData. So you will need 2 more serializers one for
> each of the above classes. You will have to inspect those classes
> to see what attributes they have and if you'll need even more
> serializers.
>
> You can serialize the object graph as deep as you want or as
> shallow as you want. For example, we have objects that have
> an Org attribute. The caller only cares about the object and
> the fact that it is associated with the org id. They don't
> care about the ENTIRE Org object being serialized. In those
> cases we cut the object graph short by not traversing into the
> Org object. We simply return
>
> helper.add("org_id", myobject.getOrg().getId());
>
> So if in the case of KickstartCommand you only want the
> name attribute of KickstartCommandName, then you can avoid
> creating a KickstartCommandName serializer, and do this:
>
> helper.add("cmd_name", mykscmd.getCommandName().getName());
>
> Since .getName() returns a String, the framework will know how
> to serialize it.
>
> I know it's a lot of information, but that is what it takes to
> create Serializers for the objects returned in the API.
>
> Sincerely,
> jesus
>
Many thanks for this! You've answered a couple of questions I hadn't
asked yet. I now have a work API call and I'm finishing up some
dependant serialisers.
Thanks again!
CC
NOTICE: This email and any attachments are confidential.
They may contain legally privileged information or
copyright material. You must not read, copy, use or
disclose them without authorisation. If you are not an
intended recipient, please contact us at once by return
email and then delete both messages and all attachments.
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
