On Feb 15, 2005, at 8:33 AM, Steve Viens wrote:

Geir,

I think there still needs an update to
o.a.j.h.BusinessServiceHander

Test the BusinessServiceHandler out and let me know. I almost put this in but after reviewing the Schema realized that businessKey in BusinessService was not marked as 'required' as serviceKey was so I decided not to add the 'else'.


If my hunch is correct, both the IBM registry and the Sun registry are
validating the incoming messages against the schema and throwing
exceptions because jUDDI wasn't creating validatable XML.

Ok - I thought I was seeing exceptions from IBM. I'll recheck.


I refactored BusinessKey, ServiceKey, .... to
extend a new KeyBase that never let the value
be null

I'm not a real big fan of this (but perhaps that's just me). I'm of the
mind that if I set a value to 'null' with a setter then I expect the
getter to return 'null'.

Fair enough.


Steve

-----Original Message-----
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 15, 2005 5:05 AM
To: [email protected]
Subject: Re: Sun's WSDP Registry...



On Feb 15, 2005, at 2:45 AM, Steve Viens wrote:

Geir,

After looking at the v2 UDDI Schema and running a few tests I've
noticed
that the handlers for BusinessEntity, BusinessService, BindingTemplate
and TModel all have this problem.

Valueless ("") XML attributes for the keys in all of these elements
are not being created when the key's value is NULL.  I've made the
changes will commit to CVS once I've tested them.

Steve,

Thanks - saw the commits.  I'll test a little later after I get to
Boston.  I think there still needs an update to
o.a.j.h.BusinessServiceHander such that

     String businessKey = service.getBusinessKey();
     if (businessKey != null)
       element.setAttribute("businessKey",businessKey);

becomes

  if (businessKey != null) {
       element.setAttribute("businessKey",businessKey);
  }
  else {
       element.setAttribute("businessKey","");
  }

as BuinessService has a businessKey.  There may be other places where
the same thing occurs.

However....  the strategy I was trying to use was to separate the
concern so that everyone that is marshalling (or unmarhalling)
businessKey, serviceKey, <foo>Key doesn't have to worry about this.

To that end, I refactored BusinessKey, ServiceKey, .... to extend a new
KeyBase that never let the value be null :

  public class BusinessKey extends KeyBase {

    public void BusinessKey() {}

    public void BusinessKey(String v) {
       super(v)
    }
}

protected class KeyBase  implements RegistryObject {

   private String value = "";

   public void KeyBase() {}
   public void KeyBase(String v) {
    setValue(v);
   }

   public void getValue() {
      return this.value;
   }

   public void setValue(String v) {
      if (v == null) {
         v = ""
      }

      this.value = v;
   }

   public String toString() {
     return getValue();
   }
}

And for this to work, we'd have to use BusinessKey rather than String
as the class for businessKey  (in BusinessEntity, for example),
ServiceKey rather than String for serviceKey in BusinessService....,
and then with the overload toString() in KeyBase so then what was

     String businessKey = service.getBusinessKey();
     if (businessKey != null)
       element.setAttribute("businessKey",businessKey);

becomes

    element.setAttribute("businessKey", service.getBusinessKey());

and you never have to think about it.

I can send a patch if you'd prefer to go that route.

geir



Steve

-----Original Message-----
From: Steve Viens [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 15, 2005 2:22 AM
To: '[email protected]'
Subject: RE: Sun's WSDP Registry...


Geir,

Is this a Java-2-XML marshalling issue?  Would changing the Handler
(i.e. o.a.j.handlers.BusinessEntityHandler) to ensure that the
businessKey attribute is created even when it's value is null correct
this?

For instance, would changing the marshal() method in
BusinessEntityHandler as follows do the trick?

Replace:

    String businessKey = business.getBusinessKey();
    if (businessKey != null)
      element.setAttribute("businessKey",businessKey);

With:

    String businessKey = business.getBusinessKey();
    if (businessKey != null)
      element.setAttribute("businessKey",businessKey);
    else
      element.setAttribute("businessKey","");

If this works for you then I can track down wherever this occurs and
apply the fix.

Steve

-----Original Message-----
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Monday, February 14, 2005 10:32 PM
To: [email protected]
Subject: Re: Sun's WSDP Registry...



On Feb 14, 2005, at 8:35 PM, Steve Viens wrote:

Thanks Geir, I'll apply the patch as soon as it's posted.

The simple solution is to set businessKey and serviceKey = "" and not let them get set to null in BusinessEntity and BusinessService. That fixed it.

However, I figured that this could be prevented from happening again
by unsuspecting higher level objects by fixing at a lower level, and I

was looking at BusinessKey, ServiceKey, *Key, and refactored to have
KeyBase that they all extended, and have KeyBase never let the value
get set to null.  However this didn't fix it.  Where is this object
model used?  (Yes, i know - I ahve the source and will read it, but
hoping for some history...)

geir


Steve

-----Original Message-----
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Monday, February 14, 2005 7:46 PM
To: [email protected]
Subject: Re: Sun's WSDP Registry...


Yep that was it.

Makes Sun's Registry happy. Fixed the businessKey problem w/ IBM but

now IBM has other issues... I'll chase down and submit a patch...

geir

On Feb 14, 2005, at 6:55 PM, Geir Magnusson Jr. wrote:

blew it's cookies when I ran the SaveBusinessSample.  It gave me an
auth token, but then to my amazement threw an NPE w/ the save
business

request :

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";><SOAP-ENV
:
Header/><SOAP-ENV:Body><SOAP-ENV:Fault><detail><dispositionReport
generic="2.0" operator="Sun Microsystems Inc." truncated="false"
xmlns="urn:uddi-org:api_v2"><result errno="10500"><errInfo
errCode="E_FATALERROR">java.lang.NullPointerException
        at

com.sun.registry_server.base.UDDIString.&lt;init&gt;(UDDIString.java:
89)
        at
com.sun.registry_server.base.UDDIKey.&lt;init&gt;(UDDIKey.java:92)
        at
com.sun.registry_server.base.BusinessKey.&lt;init&gt;
(BusinessKey.java:72)
        at com.sun.registry_server.base.BusinessEntity.&lt;init&gt;
(BusinessEntity.java:106)
        at

com.sun.registry_server.base.BusinessEntities.newObject(BusinessEntit
i
e
s.java:55)
        at

com.sun.registry_server.base.UDDICollection.populate(UDDICollection.j
a
v
a:77)
        at com.sun.registry_server.base.BusinessEntities.&lt;init&gt;
(BusinessEntities.java:40)
        at com.sun.registry_server.request.SaveBusiness.&lt;init&gt;
(SaveBusiness.java:60)


It did have the courtesy to return the entire stack trace in the result message....

Now, putting aside the fact that this is v1.5 of this gawdawful
software, and it should do some thing much more intelligent that
barf

an NPE back at me, it is hinting that maybe there's something wrong
w/

the BusinessKey :), similar to what IBM said... I'm going to set it

as "" and see if businessKey gets included as an attribute...


-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]

--
Geir Magnusson Jr                                  +1-203-665-6437
[EMAIL PROTECTED]




--
Geir Magnusson Jr                                  +1-203-665-6437
[EMAIL PROTECTED]




--
Geir Magnusson Jr                                  +1-203-665-6437
[EMAIL PROTECTED]




--
Geir Magnusson Jr                                  +1-203-665-6437
[EMAIL PROTECTED]



Reply via email to