[jdom-interest] Thread safe question: OK for simultaneous read-only access?

[Mark Bennett]

-----Original Message-----
From: jdom-interest-admin at jdom.org [mailto:jdom-interest-admin at jdom.org]On
Behalf Of rpcee
Sent: Monday, October 29, 2001 5:57 AM
To: jdom-interest at jdom.org
Subject: RE: [jdom-interest] Thread safe question: OK for simultaneous
read-only access?

> I'm writing something that generates interfaces for the public methods in
jdom
> classes, a default implementation (which implements the i/f and extends
the
> corresponding JDOM class), and optionally a SAXBuilder subclass to build
using
> the default implementations.
> ...

Good point Rich.

I had been wondering about subclassing/interfaces of Elements as well.

One thing we'd like to do (for our own peculiar reasons) is have auditing
information attached to each Element.  So for any element, I could find out
the exact uri it came from (file/url), the byte offset, line number, and
offset in the line.

Part of this, I had thought, would be to create a new SAX parser.  But I was
also imagining the need for an enhanced Element class to store the
additional info and provide access methods to it.  Maybe even store an
XPointer with the element, so we could refer back to it.

In our application it would be nice to always be able to find the exact
place where an element was first found.

Just daydreaming for now,
Mark


The problem is you get quite a large interface where many of the
implementations will be the same (helper methods eg getChildText) so I
wonder
whether the i/f should contain only core methods and use helpers to do non
core things. This would mean I only have a subset of the documented API
available (but all of the functionality).

The application code will also contain more casting, eg:
   IElement parent = (IElement) e.getParent();
Might it be easier to cheat and just make a customised org.jdom.Element
which
implements IElement? This way I could use the org.jdom.output.* stuff too.

The reason I'm doing this is to use the JDOM API on things that aren't
subclasses of JDOM classes.

Thanks, rich.

>===== Original Message From "Attila Szegedi" <szegedia at freemail.hu> =====
>I don't know if anyone works on such thing, but one thing that comes to
mind
is that this kind of "wrappers" could be implemented very elegantly if JDOM
were designed in terms of interfaces + default implementation.
>
>Attila.
>

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com