Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / April 2006

Tip: Looking for answers? Try searching our database.

Seeking class hierarchy advice

Thread view: 
Steve W. Jackson - 26 Apr 2006 15:58 GMT
We have a critical class in our app which extends the DocumentImpl class
from an older Xerces-J implementation.  I'm looking at what changes are
required to switch from 1.4.2 to 1.5, while at the same time hoping to
lose our dependence on the old versions of both Xerces and Xalan we're
currently using in favor of the built-in JAXP 1.3 in Java 1.5.

Making this class implement the Document interface isn't really
feasible, for obvious reasons.  I could set the compile classpath to
include rt.jar and then make the class extend the Xerces DocumentImpl
buried deep inside there, but I'd prefer to avoid such things if
reasonably possible.  So I'm looking for suggestions.

This class needs to be able to satisfy the "is a" test against the
org.w3c.dom.Document interface.  But so far I'm not seeing anything
become clear in my mind as to how best to accomplish this without
requiring a great deal of code change.  If that much effort is to be
required, it will mean waiting until after our pending new release to
get it done.  Getting it done now would be better, and allow us to
lighten the load by removing some jar files no longer required.

TIA for any suggestions or ideas.

= Steve =
Signature

Steve W. Jackson
Montgomery, Alabama

Chris Uppal - 27 Apr 2006 13:14 GMT
> This class needs to be able to satisfy the "is a" test against the
> org.w3c.dom.Document interface.  But so far I'm not seeing anything
> become clear in my mind as to how best to accomplish this without
> requiring a great deal of code change.

It might help if you could explain why you think there might be a middle
position available at all.

I know nothing about your code, and only a little about Xerces, but it seems to
me that either your stuff is only weakly coupled to the current superclass (in
which case you could fairly easily switch to implementing Document via
delegation to an enclosed instance of Document), or that it makes real use the
DocumentImp stuff (in which case you are strongly coupled to that
/implementation/, and I can't see any reason to expect to be able to remove
that dependency without a complete re-write, duplicating much of what you
currently inherit).   If there is a middle ground between these extremes, then
it must be because of something specific to how your current code works, which
you may know, but we don't (yet).

   -- chris


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.