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
w/
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
com.sun.registry_server.base.UDDIKey.<init>(UDDIKey.java:92)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.<init>(UDDIString.java: 89) atat com.sun.registry_server.base.BusinessKey.<init> (BusinessKey.java:72) at com.sun.registry_server.base.BusinessEntity.<init> (BusinessEntity.java:106) at
com.sun.registry_server.base.BusinessEntities.newObject(BusinessEntiti es.java:55) at
com.sun.registry_server.base.UDDICollection.populate(UDDICollection.ja va:77) at com.sun.registry_server.base.BusinessEntities.<init> (BusinessEntities.java:40) at com.sun.registry_server.request.SaveBusiness.<init> (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
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]
