db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: repository xml and DTDs
Date Sun, 04 May 2003 09:08:42 GMT
Hi James,

James Holmes wrote:
> Any comments on this??

Sorry for the delay, I'm currently busy with assembling RC3...

> 
> -James
> 
> ----- Original Message -----
> From: "James Holmes" <james@jamesholmes.com>
> To: "OJB Developers List" <ojb-dev@db.apache.org>
> Sent: Saturday, April 26, 2003 10:16 AM
> Subject: Re: repository xml and DTDs
> 
> 
> 
>>Thomas,
>>
>>Thanks for your response.
>>
>>The idea for OJB Console is that it will be able to create and edit
>>repository.xml files.  Certainly when creating new files it could break
> 
> them
> 
>>into the smaller pieces the way the OJB website's example shows.  However,
>>the problem comes in when editing a file that is broken up.  An XML parser
>>can read in that file and see it as one, but it won't be intelligent
> 
> enough
> 
>>to write out the changes into separate files.  Does that make sense?

OK, now I understand! I did not think much about this problem.
In OJB we parse the repository with a SAX parser and build up a 
DescriptorRepository instance. (all classes I'm talking about here are 
in o.a.ojb.broker.metadata)
This DecsriptorRepository contains of several subcomponents (e.g. the 
ConnectionRepository and all the ClassDescriptors).
All these subcomponents implement an Interface XmlCapable which contains 
a method toXml(). So all components are able to generate their own XML 
representation.

It should be quite easy to have a derived version of RepositoryPersistor 
  that writes the XML data to different files.

>>
>>So basically this means that in order to use OJB console users would have
> 
> to
> 
>>have one big xml file with all config info in it.  Or we could update the
>>OJB code to be able to accept multiple smaller files.  I realize you're
>>close to a release and hope we can figure out some solution here.

At this point in time I don't want to change the DTD. But by using the 
existing parser and extending the existing RepositoryPersistor it should 
be possible to get something going.

>>
>>I'm a committer on the Struts project and could help with this.  I can
>>supply patches if it's something you will entertain.

All patches are welcome!

>>Also, another thing I'd like to request (ask very nicely) is to have you
> 
> (or
> 
>>another committer) publish the repository DTD at an official address on
> 
> the
> 
>>OJB website and to create an official repository file DOCTYPE declaration.
>>
>>For example Struts has its DTD at:
>>
>>http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd
>>
>>so the DOCTYPE in Struts config files looks like:
>>
>><!DOCTYPE struts-config PUBLIC
>>       "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
>>       "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">
>>
>>For OJB this could be something like:
>>
>>http://db.apache.org/ojb/dtds/repository.dtd
>>
>>and:
>>
>><!DOCTYPE struts-config PUBLIC
>>       "-//Apache Software Foundation//DTD OJB Repository//EN"
>>       "http://db.apache.org/ojb/dtds/repository.dtd">
>>
>>What do you think?  This would be a huge help for me and likely other

Sure, that's a good idea. I don't know if this will make it into RC3 
(only hours away), but have added this point to my todo list.
The location "http://db.apache.org/ojb/dtds/repository.dtd" is OK!

The only problem I see is that certain app server / parser 
configurations will not be able to handle this properly.
I've seen enourmous promblems with this during the deployment of a 
struts based app on WebSphere OS/390. We had to manually change all xml 
files not to reference external sites!

> tools
> 
>>developers. This would also be similar to the way other frameworks, etc.
>>post their DTDs (ie. web.xml for WAR files).
>>
>>Having an official DOCTYPE declaration at the top of the config files
> 
> allows
> 
>>tools like OJB console to distinguish the OJB xml file from others.  This
> 
> is
> 
>>especially helpful when plugging an OJB tool into an IDE.  Most IDEs have
> 
> a
> 
>>mechanism to recognize certain files and make special options available to
>>the file.  For instance, OJB console will recognize OJB xml files in
>>Netbeans and allow a user to right click on the file and open it inside of
>>OJB console.  The way that xml files are recognized is by their DOCTYPE.

Cool, I didn't know that.

>>For a good example of this you can check out Struts Console
>>(http://www.jamesholmes.com/struts/).  If you just want to see how this
>>works you can check out the screen shots section of my website and you'll
>>see how the IDE plugins work conceptually.
>>
>>Your attention and help on this very much appreciated.  I think you'll
> 
> find
> 
>>that OJB console will be a huge boon to the OJB project.  I know that
> 
> Struts
> 
>>Console has really added alot of value to the Struts project.

Yes, I agree. I really want support all efforts for such a console!
Thanks for your offer to help.
Ask me for all asssitance you need,

cheers,
thomas

>>Thanks,
>>
>>James
>>
>>
>>----- Original Message -----
>>From: "Thomas Mahler" <thma32@web.de>
>>To: "OJB Developers List" <ojb-dev@db.apache.org>
>>Sent: Saturday, April 26, 2003 4:44 AM
>>Subject: Re: repository xml and DTDs
>>
>>
>>
>>>Hi James,
>>>
>>>James Holmes wrote:
>>>
>>>>I'm working on OJB Console, a tool similar to Struts Console, that
>>
>>should be
>>
>>>>ready in the next week or so.  However, I'm running into problems with
>>
>>the
>>
>>>>way the repository xml file is broken up.  The problem I'm having is
>>
>>that
>>
>>>>the file is broken into pieces and then "loaded" into the mail file
> 
> with
> 
>>>>ENTITY declarations.
>>>>
>>>>OJB Console needs each XML file to have a DOCTYPE so that the file can
>>
>>be:
>>
>>>>1.) recognized (meaning distinguished from other XML files)
>>>>2.) validated
>>>
>>>Mhh, The OJB file separation is not mandatory. splitting the file in to
>>>more digestable pieces is just an idea to keep it maintainable for
> 
> humans.
> 
>>>So it won't be a problem if you keep things simple and generate it all
>>>into one file.
>>>
>>>Why is it necessary to handle the files separately? In OJB we are just
>>>validating repository.xml against repository.dtd and the loading of the
>>>subordinate files is done transparently by the xml include mechanism.
>>>
>>>
>>>>Any ideas for solving this problem.  I realize there has been a
>>
>>precedent
>>
>>>>set to break up the large monolithic file into smaller manageable
>>
>>chunks.
>>
>>>>Perhaps each file could specity a DOCTYPE and OJB could load mulitple
>>>>smaller files and instead of loading one file that sources in the
>>
>>others?
>>
>>>As we want to have a stable 1.0 release out soon, I'd prefer to not
>>>change the existing format.
>>>
>>>I propose to simply work with one monolithic file for the time being.
>>>
>>>cheerio,
>>>Thomas
>>>
>>>
>>>
>>>>-James
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


Mime
View raw message