You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Thomas DeWeese <Th...@Kodak.com> on 2005/08/11 14:16:16 UTC
Re: RMI: getElementByID returns null
Hi Ted,
Ted.Clement@apcc.com wrote:
> We recently migrated from Batik 1.5 to v1.6 and noticed that the
> SVGDocument.getElementById() method
> was broken. We are using RMI to stream the SVGDocument from a server to
> one (or more) clients.
Did this actually work in 1.5? I was under the impression that
lots of things would break...
> A little research showed that the elementsByID list is marked "transient"
> in the AbstractDocument:
> [...]
> I was wondering what the reason was for marking this component "transient"
Mostly a copy/paste error from elementsByTagName etc. Do you want
to provide a patch and a test (not using RMI, just Serialization)
so this doesn't break again in the future?
> and if, perhaps there should
> be a "reset() or rebuild()" method to rebuild non-serialized components
> (by walking the tree and rebuilding it).
> (I assume that this list is for convenience / optimization, and therefore
> wouldn't need to be kept in sync
> with the "backend" version.)
No this _is_ the list of id's. It would in fact be impossible
to rebuild it correctly after the fact (it tracks all elements created
by the Document even if they are not currently part of the document
tree).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: RMI: getElementByID returns null
Posted by Thomas DeWeese <Th...@Kodak.com>.
>>>Thomas.DeWeese@Kodak.com wrote:
>>> Did this actually work in 1.5? I was under the impression that
>>>lots of things would break...
Ted.Clement@apcc.com wrote:
> All the parts of the API that we are using work just fine on the client(s)
> after serilization using Batik v1.5 ( create/search/modify SVGDocument &
> GVTTRee operations)
Hmm, I thought people has reported problems with this...
> When we get closer to release, I'll make sure you get an opportunity
> to see what we're done (-if, of course, you're interested!)
I'm always interested to see what people are doing with Batik.
>> Do you want to provide a patch and a test (not using RMI, just
>> Serialization) so this doesn't break again in the future?
>
> I can take a look into it next week.
> What exactly do you want for a "patch" ?
> Do you mean a binary patch? ...software patch ?
I mean a software patch (diff file). The best thing is
the output of 'svn diff > transient.patch' or something
similar (if you use TortoiseSVN you can use it to create a
'Unified Diff').
> What kind of "test"?
Ideally using:
http://xml.apache.org/batik/test.html#writingNewTests
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: RMI: getElementByID returns null
Posted by Te...@apcc.com.
Thomas,
>> Thomas.DeWeese@Kodak.com wrote:
>> Ted.Clement@apcc.com wrote:
>> > We recently migrated from Batik 1.5 to v1.6 and noticed that the
>> > SVGDocument.getElementById() method
>> > was broken. We are using RMI to stream the SVGDocument from a server
to
>> > one (or more) clients.
>> Did this actually work in 1.5? I was under the impression that
>> lots of things would break...
All the parts of the API that we are using work just fine on the client(s)
after
serilization using Batik v1.5 ( create/search/modify SVGDocument & GVTTRee
operations)
When we get closer to release, I'll make sure you get an opportunity to see
what
we're done (-if, of course, you're interested!)
>> > A little research showed that the elementsByID list is marked
"transient"
>> > in the AbstractDocument:
>> > [...]
>> > I was wondering what the reason was for marking this component
"transient"
>> Mostly a copy/paste error from elementsByTagName etc. Do you want
>> to provide a patch and a test (not using RMI, just Serialization)
>> so this doesn't break again in the future?
I can take a look into it next week.
What exactly do you want for a "patch" ?
Do you mean a binary patch? ...software patch ?
What kind of "test"?
Thanks,
Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org