Um, IMO, this is really ugly... that DOM does something doesn't seem to be a reason for Axiom to do it. What is the driving use case that means you need this complication of the model? Cheers, David
On Dec 8, 2007 5:44 AM, Saliya Ekanayake <[EMAIL PROTECTED]> wrote: > Hi all, > > Axiom implementation doesn't provide a method to retrieve the owner element > of an OMAttributeImpl instance. I've already created a JIRA on this issue > (see https://issues.apache.org/jira/browse/WSCOMMONS-230). I've resolved the > issue by adding an OMElement reference in OMAttributeImpl to keep track of > its owner. Thus I've provided a getOwner() method in OMAttribute interface. > > Now, I came across the issue of enforcing single owner restriction for > OMAttributes instances. Previously there was no constraint like that. The > patches I've send for the particular JIRA enforces this by means of not > adding the attribute to the element if its already used in another element. > This approach, however, tends to break Axis2 build because in Axis2 there > are incidents where attributes are being added to more than one element. > Thus I came up with two solutions to overcome this issue. > > 1. Throw a runtime exception (this is how it's done in DOM). Thus we are > sure that no two OMElements will contain the same OMAttribute instance (yes, > still we need to fix Axis2 code to not use attributes in more than one > element) > > 2. Create a new attribute with the same namespace, localname, and value. > Thus whenever a user tries to add an OMAttribute instance, which is already > used in an OMElement instance, to another OMElement instance that attribute > instance is cloned and its parent is set to the new element. > > I'm in favour of the second decision as it's more user friendly. The library > itself does the cloning process so that a user has to know only that it's > not the same attribute used but the cloned one. > > Your idea on this matter is highly appreciated. > > Thanks in advance, > > --Saliya > -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
