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. >> 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'. 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.<init>(UDDIString.java: >>> 89) >>> at >> com.sun.registry_server.base.UDDIKey.<init>(UDDIKey.java:92) >>> at >>> 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(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.<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 > 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]
