tm4j-developers — Forum for issues related to development of TM4J.

[Tm4j-developers] Re: TopicMapSource implementation

[Harald K. <har...@we...>]

Hi Kal Ahmed,
>
> Hi Harald,
> 
> On Mon, 2003-11-10 at 12:58, Harald Kuhn wrote:
> > Hi all, Hi Kal,
> > 
> > i have some problems with implementing the TopicMapSource. The ozone backend has its own XTMBuilder which does not implement the TopicMapBuilder interface. As i do not know Ozone well enough, i am not quite sure wether i can just use the XTMBuilder there ?!
> > 
> 
> I don't think that you can just use the XTMBuilder directly in the Ozone
> implementation as it currently is implemented. The Ozone implementation
> passes chunks of XML data from the client to the Ozone server with the
> actual parsing and object creation all happening on the server side.
> This makes it a lot more efficient when in client/server mode. If you
> like, I can take a look at that implementation.

Thats what i feared ...the question then is wether the TopicMapSource or the User should determine the Builder or wether we implement a OzoneTopicMapSource ... . On the other hand, if this is only an performance problem, then we should mybe just use the XTMBuilder and tell people to use the OzoneXTMBuilder if they want to implement something Ozone specific. We could also try to let OzoneXTMBuilder implement the TopicMapBuilder interface and just use it transparently ( e.g. SerializedTopicMapSource checks wether it gets an OzoneTM and then just uses the OzoneXTMBuilder if an XTM file was passed ) .

In the end it is definitly better, if you have a look at it, as it would probably take me far too long to figure this out (sorry i did not realise that the Ozone backend is so different there, when i made the proposal).

> > Apart from that, i added most of the changes (i just spared the interface) and it would be nice if somebody could check wether they work. I am also planning on creating JUnit tests after the ozone "problem" is solved.
> > 
> Great! Feel free to put the tests into CVS anyway - even if they break
> the Ozone implementation temporarily, they will give me a target to work
> towards.
>
> Cheers,
> 
> Kal

Cheers 
Harald

> Kal Ahmed, Techquila
> Standards-based Information Management
> e: ka...@te...
> w: www.techquila.com
> p: +44 7968 529531
> 


______________________________________________________________________________
Es geht nicht  mehr ohne Handy, aber geht es auch guenstiger?
Ja, mit Call by Call vom Handy. http://handybycall.web.de/?mc=021103

[Tm4j-developers] Re: TopicMapSource implementation

[Kal A. <ka...@te...>]

Hi Harald,

On Mon, 2003-11-10 at 12:58, Harald Kuhn wrote:
> Hi all, Hi Kal,
> 
> i have some problems with implementing the TopicMapSource. The ozone backend has its own XTMBuilder which does not implement the TopicMapBuilder interface. As i do not know Ozone well enough, i am not quite sure wether i can just use the XTMBuilder there ?!
> 

I don't think that you can just use the XTMBuilder directly in the Ozone
implementation as it currently is implemented. The Ozone implementation
passes chunks of XML data from the client to the Ozone server with the
actual parsing and object creation all happening on the server side.
This makes it a lot more efficient when in client/server mode. If you
like, I can take a look at that implementation.

> Apart from that, i added most of the changes (i just spared the interface) and it would be nice if somebody could check wether they work. I am also planning on creating JUnit tests after the ozone "problem" is solved.
> 
Great! Feel free to put the tests into CVS anyway - even if they break
the Ozone implementation temporarily, they will give me a target to work
towards.

Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: ka...@te...
w: www.techquila.com
p: +44 7968 529531

[Tm4j-developers] Re: [DONE] Make TopicMapProviderFactory a "real" factory

[Kal A. <ka...@te...>]

That looks great, thanks Florian!

Cheers,

Kal

On Sun, 2003-11-09 at 22:49, Florian G. Haas wrote:
> Hello once again.
> 
> | Its got complicated because there are actually two issues here:
> |
> | 1) Florian's proposal that TopicMapProviderFactory be turned into a
> | class implementing a defaulting mechanism for getting a new
> | TopicMapProvider instance based on system properties and other external
> | configuration options
> |
> | 2) My proposal for updating TopicMapManager to be more useful for
> | applications handling multiple topic maps.
> |
> | AFAICS, Florian's proposal does not prevent application developers from
> | creating apps that use multiple providers. It just makes it much easier
> | for developers creating apps that use a single provider by reading the
> | default provider settings from external configuration sources (like
> | system properties).
> |
> | So I think both proposals have their merit and that both should be
> | implemented.
> 
> The refactored TopicMapProviderFactory is now in the repository. I'm not sure 
> if you've received any commit messages; I just received a strange error 
> report from the SF.net mailserver which appears to indicate otherwise. I'm 
> going to wait until tomorrow night to see whether the commit messages do come 
> through, if not, I'll just forward the bounce mail to this list. It should 
> include all the relevant information regarding the checkin.
> 
> In the checkin, apart from the refactored TopicMapProviderFactory and 
> subclasses, I have also included the JUnit test I had done all along, but 
> apparently forgot to include in the patch I prepared for the SF.net upload. 
> Can't check just what exactly I submitted as the site is currently down for 
> maintenance, but I'm pretty sure that the test case wasn't in there. Sorry 
> about that, if anyone would have complained, I'd have noticed that sooner. 
> :-)
> 
> Harald, could you please double-check if the refactoring works with the 
> JNDIProviderFactory. All I've done is change "implements" to "extends" and 
> renamed "createTopicMapProvider" to "newTopicMapProvider" (the 
> createTopicMapProvider() method is still available, it's provided by the 
> abstract TopicMapProviderFactory for backwards compatibility). It compiles 
> well in Eclipse, but I must confess I didn't find the Ant target that must be 
> invoked to build your JNDI-related classes (just noticed that an hour or so 
> ago). Please update me on that.
> 
> Later,
> Florian
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] TopicMapSource implementation

[Harald K. <har...@we...>]

Hi all, Hi Kal,

i have some problems with implementing the TopicMapSource. The ozone backend has its own XTMBuilder which does not implement the TopicMapBuilder interface. As i do not know Ozone well enough, i am not quite sure wether i can just use the XTMBuilder there ?!

Apart from that, i added most of the changes (i just spared the interface) and it would be nice if somebody could check wether they work. I am also planning on creating JUnit tests after the ozone "problem" is solved.

Florian, if you still have some time, i would be very grateful for a helping hand there . 

Cheers 
Harald

______________________________________________________________________________
Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2
Kostenlos downloaden: http://screensaver.web.de/?mc=021110

Re: [Tm4j-developers] [DONE] Make TopicMapProviderFactory a "real" factory

[Harald K. <har...@we...>]

"Florian G. Haas" <f.g...@gm...> schrieb am 10.11.03 13:04:49:

Hello,

> Hello once again.
> 
> | Its got complicated because there are actually two issues here:
> |
> | 1) Florian's proposal that TopicMapProviderFactory be turned into a
> | class implementing a defaulting mechanism for getting a new
> | TopicMapProvider instance based on system properties and other external
> | configuration options
> |
> | 2) My proposal for updating TopicMapManager to be more useful for
> | applications handling multiple topic maps.
> |
> | AFAICS, Florian's proposal does not prevent application developers from
> | creating apps that use multiple providers. It just makes it much easier
> | for developers creating apps that use a single provider by reading the
> | default provider settings from external configuration sources (like
> | system properties).
> |
> | So I think both proposals have their merit and that both should be
> | implemented.
> 
> The refactored TopicMapProviderFactory is now in the repository. I'm not sure 
> if you've received any commit messages; I just received a strange error 
> report from the SF.net mailserver which appears to indicate otherwise. I'm 
> going to wait until tomorrow night to see whether the commit messages do come 
> through, if not, I'll just forward the bounce mail to this list. It should 
> include all the relevant information regarding the checkin.
> 
> In the checkin, apart from the refactored TopicMapProviderFactory and 
> subclasses, I have also included the JUnit test I had done all along, but 
> apparently forgot to include in the patch I prepared for the SF.net upload. 
> Can't check just what exactly I submitted as the site is currently down for 
> maintenance, but I'm pretty sure that the test case wasn't in there. Sorry 
> about that, if anyone would have complained, I'd have noticed that sooner. 
> :-)
> 
> Harald, could you please double-check if the refactoring works with the 
> JNDIProviderFactory. All I've done is change "implements" to "extends" and 
> renamed "createTopicMapProvider" to "newTopicMapProvider" (the 
> createTopicMapProvider() method is still available, it's provided by the 
> abstract TopicMapProviderFactory for backwards compatibility). It compiles 
> well in Eclipse, but I must confess I didn't find the Ant target that must be 
> invoked to build your JNDI-related classes (just noticed that an hour or so 
> ago). Please update me on that.

Matter of fact, there is no ant target (and there will probably never be one). I dont think that we need a special ant target for compiling three additional classes and the installation should only be done by hand, as this is quite critical. The J2EE spec does not provide rules for configuration of the container, so the config procedure is different for every web container. In order to not risk damage on this configuration (by using the wrong procedure) I think, that one should do this manually. I thought about adding the compilation to one of the other targets instead but could not find the time to discuss this with Kal and you all (so please make suggestions).

By the way, it wont work with the JNDI implementation as the spi ProviderFactory depends on a public NoArgumentConstructor (Class.newInstance()). This dependence is also true for TMNav (provider management dialog), panckoucke (the context which is used by TMNav, the TopicMapViewer and probably kamal) and  tmharvest as these use Digester for parsing their xml config files. So these also wont work with the changed tm4j for the time beeing. 
I have to check with christoph (and maybe niko, if he can find the time) who will do the porting and how to do it.

Cheers

Harald

> Later,
> Florian

______________________________________________________________________________
Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2
Kostenlos downloaden: http://screensaver.web.de/?mc=021110

[Tm4j-developers] [DONE] Make TopicMapProviderFactory a "real" factory

[Florian G. H. <f.g...@gm...>]

Hello once again.

| Its got complicated because there are actually two issues here:
|
| 1) Florian's proposal that TopicMapProviderFactory be turned into a
| class implementing a defaulting mechanism for getting a new
| TopicMapProvider instance based on system properties and other external
| configuration options
|
| 2) My proposal for updating TopicMapManager to be more useful for
| applications handling multiple topic maps.
|
| AFAICS, Florian's proposal does not prevent application developers from
| creating apps that use multiple providers. It just makes it much easier
| for developers creating apps that use a single provider by reading the
| default provider settings from external configuration sources (like
| system properties).
|
| So I think both proposals have their merit and that both should be
| implemented.

The refactored TopicMapProviderFactory is now in the repository. I'm not sure 
if you've received any commit messages; I just received a strange error 
report from the SF.net mailserver which appears to indicate otherwise. I'm 
going to wait until tomorrow night to see whether the commit messages do come 
through, if not, I'll just forward the bounce mail to this list. It should 
include all the relevant information regarding the checkin.

In the checkin, apart from the refactored TopicMapProviderFactory and 
subclasses, I have also included the JUnit test I had done all along, but 
apparently forgot to include in the patch I prepared for the SF.net upload. 
Can't check just what exactly I submitted as the site is currently down for 
maintenance, but I'm pretty sure that the test case wasn't in there. Sorry 
about that, if anyone would have complained, I'd have noticed that sooner. 
:-)

Harald, could you please double-check if the refactoring works with the 
JNDIProviderFactory. All I've done is change "implements" to "extends" and 
renamed "createTopicMapProvider" to "newTopicMapProvider" (the 
createTopicMapProvider() method is still available, it's provided by the 
abstract TopicMapProviderFactory for backwards compatibility). It compiles 
well in Eclipse, but I must confess I didn't find the Ant target that must be 
invoked to build your JNDI-related classes (just noticed that an hour or so 
ago). Please update me on that.

Later,
Florian

-- 
Florian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Florian H. <f.g...@gm...>]

Hi everyone,

> No need to be sorry, I think it was my own confusion that has made this
> harder to understand than it should be. But now I am a lot clearer. In
> bullet points:
> 
> 1) TopicMapProviderFactory provide a method to get a system default
> TopicMapProvider, making it easy to separate out the configuration from
> the code for single-provider applications.
> 
> 2) Apps using multiple providers will still be able to use
> TopicMapProviderFactory to do retrieve multiple provider implementations
> with different configuration settings (basically overriding all
> defaulting mechanisms).
>  
> 3) The TopicMapManager class will be updated to provide more useful
> management services for multiple-provider applications.
> 
> Does that sound right to everyone or am I still confused ? ;-)

Sounds perfect to me. Thanks for straightening this out! :-)

Florian


-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Kal A. <ka...@te...>]

On Wed, 2003-11-05 at 08:11, Christoph Froehlich wrote:
> Am Son, den 02.11.2003 schrieb Kal Ahmed um 13:16:
> [...]
> 
> > 
> > What do the rest of you think ?
> > 
> 
> I'm trying to catch your goals:
> 
> 1. A single point of entry for retrieving an existing topicmap,
>    regardless of the provider it is stored into. 
>    (something like [1] )
> 
Yes, this is definitely a responsibility for TopicMapManager

> 
> 2. A single point of entry to create a topicmap. Either using a 
>    default provider or being able to point one out. 
>    (something like:  [2] and [3])
> 

This is the issue that I am not certain about. I think it might be quite
useful functionality for applications which want to handle multiple
providers simultaneously. It should be possible to register providers
with simple string "handles" which you can then use to retrieve them.
 
> This would lead to two further questions:
> a. how do I specify the default provider?
 There should be a defaulting mechanism which makes the first topic map
provider registered with the manager the "default" provider and also a
method call to set the current default provider. 
> b. how do I create a new provider with TMManager and
>    how can I identify the new provider in further calls to
>    TMManager? 
>  
This I think should *not* be the functionality of TopicMapManager.
Instead, we should continue to use the TopicMapProviderFactory to do
this.

> Is this what you are discussing about, or do I miss something?

Its got complicated because there are actually two issues here:

1) Florian's proposal that TopicMapProviderFactory be turned into a
class implementing a defaulting mechanism for getting a new
TopicMapProvider instance based on system properties and other external
configuration options

2) My proposal for updating TopicMapManager to be more useful for
applications handling multiple topic maps.

AFAICS, Florian's proposal does not prevent application developers from
creating apps that use multiple providers. It just makes it much easier
for developers creating apps that use a single provider by reading the
default provider settings from external configuration sources (like
system properties). 

So I think both proposals have their merit and that both should be
implemented. There was some confusion as I was trying to work out if/how
these two things are related. I need to take a look through the code in
the patch that Florian submitted - which I plan to do today, but I think
that actually the two things are completely separate.


> Sorry for the question, but it becomes difficult to follow. 

No need to be sorry, I think it was my own confusion that has made this
harder to understand than it should be. But now I am a lot clearer. In
bullet points:

1) TopicMapProviderFactory provide a method to get a system default
TopicMapProvider, making it easy to separate out the configuration from
the code for single-provider applications.

2) Apps using multiple providers will still be able to use
TopicMapProviderFactory to do retrieve multiple provider implementations
with different configuration settings (basically overriding all
defaulting mechanisms).
 
3) The TopicMapManager class will be updated to provide more useful
management services for multiple-provider applications.

Does that sound right to everyone or am I still confused ? ;-)

Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: ka...@te...
w: www.techquila.com
p: +44 7968 529531

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Christoph F. <cf...@fo...>]

Am Son, den 02.11.2003 schrieb Kal Ahmed um 13:16:
[...]

> 
> What do the rest of you think ?
> 

I'm trying to catch your goals:

1. A single point of entry for retrieving an existing topicmap,
   regardless of the provider it is stored into. 
   (something like [1] )


2. A single point of entry to create a topicmap. Either using a 
   default provider or being able to point one out. 
   (something like:  [2] and [3])

This would lead to two further questions:
a. how do I specify the default provider?
b. how do I create a new provider with TMManager and
   how can I identify the new provider in further calls to
   TMManager? 
 
Is this what you are discussing about, or do I miss something?
Sorry for the question, but it becomes difficult to follow. 
cf


[1]  tmmanager.getTopicMap(baselocator)    
[2]  tmmanager.createTopicMap(topicmapsource)    
[3]  tmmanager.createTopicMap(topicmapsource, provider)    

> Cheers,
> 
> Kal
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Christoph Froehlich <cf...@fo...>

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Kal A. <ka...@te...>]

On Sat, 2003-11-01 at 22:57, Florian G. Haas wrote:
> Hi Kal (and Harald, and everyone else).
> 
> On Saturday 01 November 2003 21:47, you wrote:
> | > Hmm. Kal, do you have a comment on that? Is that what the TopicMapManager
> | > is really designed for?
> |
> | The role of TopicMapManager was never too clear in my mind and it has
> | just sat there in the API for a while with no clear purpose. However, I
> | think that what Harald suggests is a good idea, because it would make a
> | single point of access to all topic maps your program cares about even
> | if there are some on a file system and some in a database. AFAICS, your
> | proposed changes for TopicMapProviderFactory would be equally well
> | implemented on the TopicMapManager class instead - and then
> | TopicMapProviderFactory becomes redundant and can probably be removed
> | from the API.
> |
> | So you would now do something like
> | TopicMapManager mgr = new TopicMapManager();
> | TopicMapProvider provider = mgr.newTopicMapProvider(providerProps);
> | TopicMap tm = mgr.getTopicMap(tmBaseLoc);
> 
> This IMHO contradicts what you stated above. If I retrieve a new provider 
> using just mgr.newTopicMapProvider(providerProps), and then add a topic map 
> to that provider from an InputStream, how does the engine know into which 
> persistent store it puts the topic map? To do that the engine would still 
> require some knowledge as to what backend implementation to use. The 
> TopicMapManager would only be capable of automagically selecting the correct 
> backend implementation for purposes of retrieval, not storage. And for 
> storage, you would still have to specify the desired back-end implementation 
> manually. So indeed, an automatic back-end selection using an externally 
> defined system property or a service provider configuration file would be 
> useless and indeed counterproductive here.

Hmmm - I see what you mean, but I think that the TopicMapManager could
still be made the "entry point" for both single-backend and
multiple-backend applications.
What is needed is a level of indirection for providers - using a
symbolic name to register/retrieve providers from the manager. So you
would have something like
TopicMapManager mgr = new TopicMapManager();
TopicMapProvider provider = mgr.newTopicMapProvider(providerName,
providerProps);
// Retrieval of a topic map
TopicMap tm = mgr.getTopicMap(tmBaseLoc);
// Retrieval of a provider
TopicMapProvider myProvider = mgr.getProvider(providerName);

If you then extend your proposal, so that the TopicMapManager *fisrt*
looks in the properties passed to newTopicMapProvider() for the
org.tm4j.topicmap.TopicMapProviderFactory property, then does the other
fallbacks, then you have a generic solution that suits both
single-backend applications and multiple-backend applications. Single
backend applications can also make use of the TopicMapProvider instance
returned by TopicMapManager.newTopicMapProvider() - so once that is
retrieved and stored, the application need never use TopicMapManager
again...

Having just written that, I can see the counter argument that these are
two different pieces of functionality - providing factory services for
TopicMapProviders and providing management services for multiple
TopicMapProviders...and maybe those should not be combined into a single
class.

What do the rest of you think ?

Cheers,

Kal

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Florian G. H. <f.g...@gm...>]

Hi Kal (and Harald, and everyone else).

On Saturday 01 November 2003 21:47, you wrote:
| > Hmm. Kal, do you have a comment on that? Is that what the TopicMapManager
| > is really designed for?
|
| The role of TopicMapManager was never too clear in my mind and it has
| just sat there in the API for a while with no clear purpose. However, I
| think that what Harald suggests is a good idea, because it would make a
| single point of access to all topic maps your program cares about even
| if there are some on a file system and some in a database. AFAICS, your
| proposed changes for TopicMapProviderFactory would be equally well
| implemented on the TopicMapManager class instead - and then
| TopicMapProviderFactory becomes redundant and can probably be removed
| from the API.
|
| So you would now do something like
| TopicMapManager mgr = new TopicMapManager();
| TopicMapProvider provider = mgr.newTopicMapProvider(providerProps);
| TopicMap tm = mgr.getTopicMap(tmBaseLoc);

This IMHO contradicts what you stated above. If I retrieve a new provider 
using just mgr.newTopicMapProvider(providerProps), and then add a topic map 
to that provider from an InputStream, how does the engine know into which 
persistent store it puts the topic map? To do that the engine would still 
require some knowledge as to what backend implementation to use. The 
TopicMapManager would only be capable of automagically selecting the correct 
backend implementation for purposes of retrieval, not storage. And for 
storage, you would still have to specify the desired back-end implementation 
manually. So indeed, an automatic back-end selection using an externally 
defined system property or a service provider configuration file would be 
useless and indeed counterproductive here.

I had a completely different goal in mind which prompted me to write up my 
original proposal: not to provide topic map aggregation services across 
backend implementations (which the TopicMapManager already does), but to 
enable application developers to write backend-independent TM4J applications 
which do *not* require such aggregation services. So if a user then decided 
that he/she is doing better with a relational DBMS (like, say, MySQL) than 
with an OODBMS (like Ozone), there would be no need to touch the application 
logic at all, merely to make a few external tweaks such as defining system 
properties or editing a config file, and you would be ready to go[1]. Just 
like jakarta-commons logging lets you switch between Log4J and JDK1.4 logging 
whenever you please.

What I'll do for now is bundle the bit of hacking I've down to implement my 
original proposal (plus Harald's don't-fall-back-to-default suggestion) for 
testing purposes and upload it to the SF.net patch tracking system, just so 
as to illustrate more concretely what I had in mind. We can always delete 
that patch afterwards and forget about it. :-)

Later,
Florian

[1] Granted, you would need to cater for migration of the existing data.


--
Florian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Kal A. <ka...@te...>]

On Sat, 2003-11-01 at 10:27, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi again.
> 
> On Friday 31 October 2003 12:53, Harald Kuhn wrote:
> | Hi Florian, Hi all,
> |
> | it took me some time to think about your proposal so sorry for the late
> | posting ...
> 
> No problem. 
> 
> |
> | > Hello,
> | >
> | > Since Harald beat me to implementing Reader support in TopicMapBuilder,
> | > here is something else I've been contemplating for a few days. :-)
> |
> | sorry for that, it was just a matter of "beeing part of the TopicMapSource
> | Plan" :)
> 
> No problem either. :-)
> 
> | I have an objection (but also a possible solution). There are a number of
> | situation where a fallback implementation is not interesting, especially if
> | i try to connect to an already existing TM (via jndi or because it is
> | stored in a persitent store) where I need to know exactly which kind of
> | provider i will get back and where I would have to test for it if there are
> | different options available or where an environmental variable would not
> | have any effect at all. 
> 
> For the sake of clarification: I was referring to system properties (passed to 
> the Java runtime via the -D flag), not to environment variables. But I 
> presume that that's what you're referring to.
> 
> But I see what you're saying. I could change the behavior to the following:
> 
> * If *neither* the system property nor an entry in META-INF/services are 
> found, use the default implementation.
> * If no system property is defined, but an entry in META-INF/services is 
> found, but that class can't be instantiated, throw an Error.
> * If the system property is defined, but the class can't be instantiated, 
> throw an Error.
> 
> I believe that would be even more along the principle of least surprise, as 
> this follows the behavior of the TrAX and JAXP factories more closely. In 
> essence, it would mean that if any specific implementation is requested but 
> can't be instantiated, this would be an error condition. Only if no specific 
> implementation were requested, there would even be the chance of using 
> falling back to the default.
> 
> Of course, you still always have the option of instantiating a 
> TopicMapProviderFactory subclass directly, rather than use the base class and 
> newInstance().
> 
> | So I suggest, not to change the TopicMapProvider
> | interface and implementations.
> 
> I never suggested to change either. Indeed, I'm not going to touch 
> TopicMapProvider, just TopicMapProviderFactory (and subclasses).
> 
> | However i think that Florians idea of a central factory is very good. I
> | just think that we should provide both ways (i apologize if i misunderstood
> | you there).
> |
> | So i suggest a different place for implementing Florians suggestions: the
> | TopicMapManager.
> |
> | 1. There is only one implementation (even less impact).
> |
> | 2. TopicMapManager is and was meant to be the central management point for
> | TopicMaps, so why not add some more Provider management functionality as
> | well ? There is already a method
> |
> |                registerProvider(String providerFactoryClassName, 
> | Properties props)
> | for instanciating Providers so we could easily add Florains
> | newTopicMapProvider(Properties props)  and make TopicMapManager the factory
> | class.
> 
> Hmm. Kal, do you have a comment on that? Is that what the TopicMapManager is 
> really designed for?  
> 

The role of TopicMapManager was never too clear in my mind and it has
just sat there in the API for a while with no clear purpose. However, I
think that what Harald suggests is a good idea, because it would make a
single point of access to all topic maps your program cares about even
if there are some on a file system and some in a database. AFAICS, your
proposed changes for TopicMapProviderFactory would be equally well
implemented on the TopicMapManager class instead - and then
TopicMapProviderFactory becomes redundant and can probably be removed
from the API.

So you would now do something like
TopicMapManager mgr = new TopicMapManager();
TopicMapProvider provider = mgr.newTopicMapProvider(providerProps);
TopicMap tm = mgr.getTopicMap(tmBaseLoc);

Now, this leaves a question - how would you get the base locator ? After
all you don't necessarily know which provider the topic map is from (and
I don't think you should have to in order to get it from the manager).
So I would propose that getTopicMap(Locator) becomes getTopicMap(String
notation, String address) and getTopicMap(String address) which will
hide the mechanics of looking up the topic map using a Locator object.

Also, I think that getProvider(TopicMap) can be removed as that is now
part of the TopicMap interface.

Cheers,

Kal

> Take care,
> Florian
> 
> - -- 
> Florian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/
> 
> GnuPG key ID: 0x46D00BE3
> Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3
> 
> My GnuPG key is available from the public PGP key server at
> pgp.mit.edu (and various other key servers).
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE/o4qlgW2VC0bQC+MRAnguAKDe8IrWsEL+WkRPfMn6vKRcXKQOnQCg+0W5
> j1S7hPqtzM/io6G2hVnknbw=
> =Ols1
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Florian G. H. <f.g...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again.

On Friday 31 October 2003 12:53, Harald Kuhn wrote:
| Hi Florian, Hi all,
|
| it took me some time to think about your proposal so sorry for the late
| posting ...

No problem.=20

|
| > Hello,
| >
| > Since Harald beat me to implementing Reader support in TopicMapBuilder,
| > here is something else I've been contemplating for a few days. :-)
|
| sorry for that, it was just a matter of "beeing part of the TopicMapSource
| Plan" :)

No problem either. :-)

| I have an objection (but also a possible solution). There are a number of
| situation where a fallback implementation is not interesting, especially =
if
| i try to connect to an already existing TM (via jndi or because it is
| stored in a persitent store) where I need to know exactly which kind of
| provider i will get back and where I would have to test for it if there a=
re
| different options available or where an environmental variable would not
| have any effect at all.=20

=46or the sake of clarification: I was referring to system properties (pass=
ed to=20
the Java runtime via the -D flag), not to environment variables. But I=20
presume that that's what you're referring to.

But I see what you're saying. I could change the behavior to the following:

* If *neither* the system property nor an entry in META-INF/services are=20
found, use the default implementation.
* If no system property is defined, but an entry in META-INF/services is=20
found, but that class can't be instantiated, throw an Error.
* If the system property is defined, but the class can't be instantiated,=20
throw an Error.

I believe that would be even more along the principle of least surprise, as=
=20
this follows the behavior of the TrAX and JAXP factories more closely. In=20
essence, it would mean that if any specific implementation is requested but=
=20
can't be instantiated, this would be an error condition. Only if no specifi=
c=20
implementation were requested, there would even be the chance of using=20
falling back to the default.

Of course, you still always have the option of instantiating a=20
TopicMapProviderFactory subclass directly, rather than use the base class a=
nd=20
newInstance().

| So I suggest, not to change the TopicMapProvider
| interface and implementations.

I never suggested to change either. Indeed, I'm not going to touch=20
TopicMapProvider, just TopicMapProviderFactory (and subclasses).

| However i think that Florians idea of a central factory is very good. I
| just think that we should provide both ways (i apologize if i misundersto=
od
| you there).
|
| So i suggest a different place for implementing Florians suggestions: the
| TopicMapManager.
|
| 1. There is only one implementation (even less impact).
|
| 2. TopicMapManager is and was meant to be the central management point for
| TopicMaps, so why not add some more Provider management functionality as
| well ? There is already a method
|
|                registerProvider(String providerFactoryClassName,=20
| Properties props)
| for instanciating Providers so we could easily add Florains
| newTopicMapProvider(Properties props)  and make TopicMapManager the facto=
ry
| class.

Hmm. Kal, do you have a comment on that? Is that what the TopicMapManager i=
s=20
really designed for? =20

Take care,
=46lorian

=2D --=20
=46lorian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/o4qlgW2VC0bQC+MRAnguAKDe8IrWsEL+WkRPfMn6vKRcXKQOnQCg+0W5
j1S7hPqtzM/io6G2hVnknbw=3D
=3DOls1
=2D----END PGP SIGNATURE-----

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Harald K. <har...@we...>]

Hi Florian, Hi all,

it took me some time to think about your proposal so sorry for the late posting ...

> 
> Hello,
> 
> Since Harald beat me to implementing Reader support in TopicMapBuilder, here 
> is something else I've been contemplating for a few days. :-)

sorry for that, it was just a matter of "beeing part of the TopicMapSource Plan" :)

> I have a proposal to put forward with regard to the TopicMapProviderFactory 
> interface. If accepted, I volunteer to implement this proposal. Please read 
> through this and let me know what your thoughts are.
> 
> SITUATION:
> The TopicMapProviderFactory is an interface that defines a single method, 
> createProvider(), which creates a new TopicMapProvider instance. The 
> interface is implemented by corresponding classes in the Hibernate, Ozone, 
> and in-memory backend implementations. An application must first select a 
> concrete implementing class before it can create an instance of 
> TopicMapProviderFactory. In doing so, the applications read the "provider" 
> system property (expected to contain the fully-qualified class name of the 
> implementing class). If not found, they fall back to the default 
> implementation, which is org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl 
> (but this is merely by convention).
> 
> ISSUE:
> This behavior is not in line with the typical aspects of service provider 
> factory classes, as exemplified by the factory classes in JAXP, TrAX, 
> jakarta-commons Logging, etc. Therefore, the behavior of this class may be 
> somewhat counter-intuitive for developers who wish to use TM4J. Also, there 
> is no provision for using the service provider configuration mechanism 
> (META-INF/services) defined in the JAR spec.
> 
> PROPOSED SOLUTION:
> 1. Make TopicMapProviderFactory an abstract class rather than an interface.
> 
> 2. Provide a protected no-arg default constructor for the 
> TopicMapProviderFactory class.
> 
> 3. Implement a static newInstance() method that selects a concrete 
> implementation class using the following selection algorithm, in descending 
> order of precedence:
> 
>   a. Look for a system property named 
> "org.tm4j.topicmap.TopicMapProviderFactory"; if found, expect its value to be 
> the fully-qualified class name of the concrete implementation class.
> 
>   b. Likewise, look for a system property named "provider", handle it 
> equivalently. (This would be purely for backward-compatibility reasons and 
> should go away before a 1.0 release)
> 
>   c. Find a resource on the Java classpath named 
> "META-INF/services/org.tm4j.topicmap.TopicMapProviderFactory"; expect it to 
> contain a single line of text denoting the fully-qualified class name of the 
> concrete implementation class.
> 
>   d. Fall back to the default implementation, 
> org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl.
> 
> 4. Define an abstract newTopicMapProvider() method that returns a new topic 
> map provider. This is the method that would have to be specified by the 
> implementing subclass. (The createTopicMapProvider() method could wrap this 
> method for backwards compatibility).
> 
> 5. Define a subclass of Error named TopicMapProviderFactoryConfigurationError 
> that is thrown by the newInstance() method in case the factory class could 
> not be found, accessed, or instantiated.
> 
> 6. Define a subclass of Exception named TopicMapProviderFactoryException that 
> is thrown by the newTopicMapProvider() method in case the provider instance 
> could not be instantiated. 
> 
> 7. Refactor the existing classes implementing the TopicMapProviderFactory 
> interface so they extend the new TopicMapProviderFactory class.
> 
> 
> IMPACT:
> Should be moderate - not counting the JUnit test cases, there are 9 classes 
> that currently instantiate an implementation the TopicMapProviderFactory 
> interface. (Famous last words?)
> 
> 
> How's that sound to you? Comments much a appreciated. And thanks for reading 
> down this far! :-)

I have an objection (but also a possible solution). There are a number of situation where a fallback implementation is not interesting, especially if i try to connect to an already existing TM (via jndi or because it is stored in a persitent store) where I need to know exactly which kind of provider i will get back and where I would have to test for it if there are different options available or where an environmental variable would not have any effect at all. So I suggest, not to change the TopicMapProvider interface and implementations. 

However i think that Florians idea of a central factory is very good. I just think that we should provide both ways (i apologize if i misunderstood you there).

So i suggest a different place for implementing Florians suggestions: the TopicMapManager.

1. There is only one implementation (even less impact). 

2. TopicMapManager is and was meant to be the central management point for TopicMaps, so why not add some more Provider management functionality as well ? There is already a method   
                  
               registerProvider(String providerFactoryClassName,  Properties props)

for instanciating Providers so we could easily add Florains newTopicMapProvider(Properties props)  and make TopicMapManager the factory class. 

Cheers 

Harald


> Cheers,
> Florian
> 
> - -- 
> Florian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/
> 
> GnuPG key ID: 0x46D00BE3
> Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3
> 
> My GnuPG key is available from the public PGP key server at
> pgp.mit.edu (and various other key servers).
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE/oBCIgW2VC0bQC+MRApIuAJ9A0wT66a0Mtth73ak2TwHwtszOjQCgkS/8
> MiDXSYY73QCzt0pv1bJqmpI=
> =gWFq
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
> 
> .
> 



______________________________________________________________________________
Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2
Kostenlos downloaden: http://screensaver.web.de/?mc=021110

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Kal A. <ka...@te...>]

On Thu, 2003-10-30 at 15:52, Florian Haas wrote:
> Hi again.
> 
> > OK then working on the principle of least suprise, I propose that
> > tm4j.x.x should be used for logging categories only. All properties
> > should be org.tm4j.x.x.x
> > 
> > How does that sound ?
> 
> D'OH! Now I've caused some confusion. :-) The usual conventions, IIUC, are
> as follows:
> 
> Names of logging categories: fully-qualified class names, e.g.
> org.tm4j.topicmap.memory.TopicImpl
> 
> Config properties to tweak a particular package: <simple
> prefix>.<property>[.<subproperty>[.<subsubproperty>]], e.g. log4j.rootLogger=DEBUG or
> tm4j.topicmap.1=...
> 
> System properties to define factory classes: <factory base class name>, e.g.
> javax.xml.transform.TransformerFactory=com.icl.saxon.transformer.TransformerFactoryImpl
> 
> 
> So my suggestion for TM4J was such:
> 
> * Logging category names: fully-qualified class names (as is now, and
> follows the common convention)
> * Configuration properties : tm4j.x.y.z (as is now, and follows the common
> convention)
> * System property to read impl class name from:
> org.tm4j.topicmap.TopicMapProviderFactory (as follows the common convention)
> 

That works for me.

> The way I worded my original proposal, I believe it sounded like it would
> have far more impact on property naming than it really does. In fact that
> impact is quite minimal. But as pointed out earlier, you're the boss, so if you
> opt for your own suggestion, I'd happily implement that too.
> 

I really have no strong opinions about the naming of properties as long
as it is consistent. So, given that I don't feel like being too
boss-like over this, lets follow the principle of least suprise and
making TM4J's log categories, properties and factory configuration work
like other packages. That makes complete sense to me. :-)

Cheers,

Kal

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Florian H. <f.g...@gm...>]

Hi again.

> OK then working on the principle of least suprise, I propose that
> tm4j.x.x should be used for logging categories only. All properties
> should be org.tm4j.x.x.x
> 
> How does that sound ?

D'OH! Now I've caused some confusion. :-) The usual conventions, IIUC, are
as follows:

Names of logging categories: fully-qualified class names, e.g.
org.tm4j.topicmap.memory.TopicImpl

Config properties to tweak a particular package: <simple
prefix>.<property>[.<subproperty>[.<subsubproperty>]], e.g. log4j.rootLogger=DEBUG or
tm4j.topicmap.1=...

System properties to define factory classes: <factory base class name>, e.g.
javax.xml.transform.TransformerFactory=com.icl.saxon.transformer.TransformerFactoryImpl


So my suggestion for TM4J was such:

* Logging category names: fully-qualified class names (as is now, and
follows the common convention)
* Configuration properties : tm4j.x.y.z (as is now, and follows the common
convention)
* System property to read impl class name from:
org.tm4j.topicmap.TopicMapProviderFactory (as follows the common convention)

The way I worded my original proposal, I believe it sounded like it would
have far more impact on property naming than it really does. In fact that
impact is quite minimal. But as pointed out earlier, you're the boss, so if you
opt for your own suggestion, I'd happily implement that too.

Cheers,
Florian

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Kal A. <ka...@te...>]

On Thu, 2003-10-30 at 10:44, Florian Haas wrote:
> Hi Kal.
> 
> > Hi Florian,
> > 
> > This sounds good to me. I can't think of any changes to what you propose
> > except for the property name.
> > 
> > Currently there is a mixture of property names in various places in TM4J
> > some starting org.tm4j. and many starting just tm4j.
> > 
> > So my question is do we think that all properties should be under
> > org.tm4j or just under tm4j ?
> > 
> > I guess that org.tm4j is "playing nice", but how many tm4j's are there
> > out there ? :)
> 
> I see where you're coming from. org.tm4j.x.x.x would be in line with what
> people are used to from TrAX and JAXP, tm4j.x.x.x should look familiar to users
> of Log4J, for example. So both should be OK, although for the factories I'd
> personally prefer the org.tm4j.x.x.x style. You're the TM4J BDFL, you decide.
> :-) 
> 

OK then working on the principle of least suprise, I propose that
tm4j.x.x should be used for logging categories only. All properties
should be org.tm4j.x.x.x

How does that sound ?

Cheers,

Kal
> -- 
> Kal Ahmed <ka...@te...>
> techquila

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Florian H. <f.g...@gm...>]

Hi Kal.

> Hi Florian,
> 
> This sounds good to me. I can't think of any changes to what you propose
> except for the property name.
> 
> Currently there is a mixture of property names in various places in TM4J
> some starting org.tm4j. and many starting just tm4j.
> 
> So my question is do we think that all properties should be under
> org.tm4j or just under tm4j ?
> 
> I guess that org.tm4j is "playing nice", but how many tm4j's are there
> out there ? :)

I see where you're coming from. org.tm4j.x.x.x would be in line with what
people are used to from TrAX and JAXP, tm4j.x.x.x should look familiar to users
of Log4J, for example. So both should be OK, although for the factories I'd
personally prefer the org.tm4j.x.x.x style. You're the TM4J BDFL, you decide.
:-) 

Take care,
Florian

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: [Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Kal A. <ka...@te...>]

Hi Florian,

This sounds good to me. I can't think of any changes to what you propose
except for the property name.

Currently there is a mixture of property names in various places in TM4J
some starting org.tm4j. and many starting just tm4j.

So my question is do we think that all properties should be under
org.tm4j or just under tm4j ?

I guess that org.tm4j is "playing nice", but how many tm4j's are there
out there ? :)

If the general feeling is that we should be using org.tm4j everywhere, I
can make the necessary changes to do that (and retain the existing tm4j.
properties just for backwards compatibility in 0.9.0)


Cheers,

Kal

On Wed, 2003-10-29 at 19:09, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> Since Harald beat me to implementing Reader support in TopicMapBuilder, here 
> is something else I've been contemplating for a few days. :-)
> 
> 
> I have a proposal to put forward with regard to the TopicMapProviderFactory 
> interface. If accepted, I volunteer to implement this proposal. Please read 
> through this and let me know what your thoughts are.
> 
> SITUATION:
> The TopicMapProviderFactory is an interface that defines a single method, 
> createProvider(), which creates a new TopicMapProvider instance. The 
> interface is implemented by corresponding classes in the Hibernate, Ozone, 
> and in-memory backend implementations. An application must first select a 
> concrete implementing class before it can create an instance of 
> TopicMapProviderFactory. In doing so, the applications read the "provider" 
> system property (expected to contain the fully-qualified class name of the 
> implementing class). If not found, they fall back to the default 
> implementation, which is org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl 
> (but this is merely by convention).
> 
> ISSUE:
> This behavior is not in line with the typical aspects of service provider 
> factory classes, as exemplified by the factory classes in JAXP, TrAX, 
> jakarta-commons Logging, etc. Therefore, the behavior of this class may be 
> somewhat counter-intuitive for developers who wish to use TM4J. Also, there 
> is no provision for using the service provider configuration mechanism 
> (META-INF/services) defined in the JAR spec.
> 
> PROPOSED SOLUTION:
> 1. Make TopicMapProviderFactory an abstract class rather than an interface.
> 
> 2. Provide a protected no-arg default constructor for the 
> TopicMapProviderFactory class.
> 
> 3. Implement a static newInstance() method that selects a concrete 
> implementation class using the following selection algorithm, in descending 
> order of precedence:
> 
>   a. Look for a system property named 
> "org.tm4j.topicmap.TopicMapProviderFactory"; if found, expect its value to be 
> the fully-qualified class name of the concrete implementation class.
> 
>   b. Likewise, look for a system property named "provider", handle it 
> equivalently. (This would be purely for backward-compatibility reasons and 
> should go away before a 1.0 release)
> 
>   c. Find a resource on the Java classpath named 
> "META-INF/services/org.tm4j.topicmap.TopicMapProviderFactory"; expect it to 
> contain a single line of text denoting the fully-qualified class name of the 
> concrete implementation class.
> 
>   d. Fall back to the default implementation, 
> org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl.
> 
> 4. Define an abstract newTopicMapProvider() method that returns a new topic 
> map provider. This is the method that would have to be specified by the 
> implementing subclass. (The createTopicMapProvider() method could wrap this 
> method for backwards compatibility).
> 
> 5. Define a subclass of Error named TopicMapProviderFactoryConfigurationError 
> that is thrown by the newInstance() method in case the factory class could 
> not be found, accessed, or instantiated.
> 
> 6. Define a subclass of Exception named TopicMapProviderFactoryException that 
> is thrown by the newTopicMapProvider() method in case the provider instance 
> could not be instantiated. 
> 
> 7. Refactor the existing classes implementing the TopicMapProviderFactory 
> interface so they extend the new TopicMapProviderFactory class.
> 
> 
> IMPACT:
> Should be moderate - not counting the JUnit test cases, there are 9 classes 
> that currently instantiate an implementation the TopicMapProviderFactory 
> interface. (Famous last words?)
> 
> 
> How's that sound to you? Comments much a appreciated. And thanks for reading 
> down this far! :-)
> 
> Cheers,
> Florian
> 
> - -- 
> Florian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/
> 
> GnuPG key ID: 0x46D00BE3
> Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3
> 
> My GnuPG key is available from the public PGP key server at
> pgp.mit.edu (and various other key servers).
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE/oBCIgW2VC0bQC+MRApIuAJ9A0wT66a0Mtth73ak2TwHwtszOjQCgkS/8
> MiDXSYY73QCzt0pv1bJqmpI=
> =gWFq
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] [PROPOSAL] Make TopicMapProviderFactory a "real" factory

[Florian G. H. <f.g...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Since Harald beat me to implementing Reader support in TopicMapBuilder, her=
e=20
is something else I've been contemplating for a few days. :-)


I have a proposal to put forward with regard to the TopicMapProviderFactory=
=20
interface. If accepted, I volunteer to implement this proposal. Please read=
=20
through this and let me know what your thoughts are.

SITUATION:
The TopicMapProviderFactory is an interface that defines a single method,=20
createProvider(), which creates a new TopicMapProvider instance. The=20
interface is implemented by corresponding classes in the Hibernate, Ozone,=
=20
and in-memory backend implementations. An application must first select a=20
concrete implementing class before it can create an instance of=20
TopicMapProviderFactory. In doing so, the applications read the "provider"=
=20
system property (expected to contain the fully-qualified class name of the=
=20
implementing class). If not found, they fall back to the default=20
implementation, which is org.tm4j.topicmap.memory.TopicMapProviderFactoryIm=
pl=20
(but this is merely by convention).

ISSUE:
This behavior is not in line with the typical aspects of service provider=20
factory classes, as exemplified by the factory classes in JAXP, TrAX,=20
jakarta-commons Logging, etc. Therefore, the behavior of this class may be=
=20
somewhat counter-intuitive for developers who wish to use TM4J. Also, there=
=20
is no provision for using the service provider configuration mechanism=20
(META-INF/services) defined in the JAR spec.

PROPOSED SOLUTION:
1. Make TopicMapProviderFactory an abstract class rather than an interface.

2. Provide a protected no-arg default constructor for the=20
TopicMapProviderFactory class.

3. Implement a static newInstance() method that selects a concrete=20
implementation class using the following selection algorithm, in descending=
=20
order of precedence:

  a. Look for a system property named=20
"org.tm4j.topicmap.TopicMapProviderFactory"; if found, expect its value to =
be=20
the fully-qualified class name of the concrete implementation class.

  b. Likewise, look for a system property named "provider", handle it=20
equivalently. (This would be purely for backward-compatibility reasons and=
=20
should go away before a 1.0 release)

  c. Find a resource on the Java classpath named=20
"META-INF/services/org.tm4j.topicmap.TopicMapProviderFactory"; expect it to=
=20
contain a single line of text denoting the fully-qualified class name of th=
e=20
concrete implementation class.

  d. Fall back to the default implementation,=20
org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl.

4. Define an abstract newTopicMapProvider() method that returns a new topic=
=20
map provider. This is the method that would have to be specified by the=20
implementing subclass. (The createTopicMapProvider() method could wrap this=
=20
method for backwards compatibility).

5. Define a subclass of Error named TopicMapProviderFactoryConfigurationErr=
or=20
that is thrown by the newInstance() method in case the factory class could=
=20
not be found, accessed, or instantiated.

6. Define a subclass of Exception named TopicMapProviderFactoryException th=
at=20
is thrown by the newTopicMapProvider() method in case the provider instance=
=20
could not be instantiated.=20

7. Refactor the existing classes implementing the TopicMapProviderFactory=20
interface so they extend the new TopicMapProviderFactory class.


IMPACT:
Should be moderate - not counting the JUnit test cases, there are 9 classes=
=20
that currently instantiate an implementation the TopicMapProviderFactory=20
interface. (Famous last words?)


How's that sound to you? Comments much a appreciated. And thanks for readin=
g=20
down this far! :-)

Cheers,
=46lorian

=2D --=20
=46lorian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/oBCIgW2VC0bQC+MRApIuAJ9A0wT66a0Mtth73ak2TwHwtszOjQCgkS/8
MiDXSYY73QCzt0pv1bJqmpI=3D
=3DgWFq
=2D----END PGP SIGNATURE-----

Re: [Tm4j-developers] TopicMapBuilder: support Reader in addition

[Florian H. <f.g...@gm...>]

Hello Harald,

> Hi Florian,
> 
> matter of fact, i already started with adding Reader support to the 
> TopicMapBuilders (some of the changes are already in CVS). 

So I've noticed. Speaking of which, I've noticed that the ViewCvs interface
on the SF.net CVS repository seems to be served from a snapshot which lags
about 24 hours behind the actual repository. I seem to recall that the ViewCvs
view of the repository used to be up to the minute, anyone know when and why
the SF.net people changed that?

> However i 
> just wrapped some of the original code because i did not want to 
> change to much. So if you want to refactor XTMBuilder (which i think is 
> a good idea), i would like to ask you to wait some more days in order for
> me to get everything I changed into the cvs.  I will send you an email as
> soon as i finished my basic 
> changes.

Great. Please do. WRT XTMBuilder, turns out that my original perception
about XTMBuilder using deprecated SAX1 stuff was wrong -- I got confused by the
javax.xml.parsers.SAXParser class, which does indeed wrap a SAX2 XMLReader.
But the build method in XTMBuilder can still use a little more abstraction by
using SAX InputSources, rather than InputStreams or Readers directly. And a
little more Javadoc. :-) I have an update just about done, so if Kal doesn't
stop me, I'll commit that tonight.

> One more thing, what is the status of the DOM implementation ? I had to 
> change the DOMTopicMapImpl (getProvider method) but could not find a 
> TopicMapProvider implemenation.

Don't. Seriously, don't consider the DOM backend something you'd want to
work with just now. Currently it doesn't look like I'm gonna take the DOM
backend any further. Brooks: "Plan to throw one away, you will, anyhow" -- I hadn't
read that when I started on that implementation. :-) But it just crossed my
mind last night that I might use some of the stuff I wrote back then for an
xmldb (Xindice, eXist) backend. 

Later,
Florian

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: [Tm4j-developers] TopicMapBuilder: support Reader in addition

[Harald K. <har...@we...>]

Hi Florian,

matter of fact, i already started with adding Reader support to the 
TopicMapBuilders (some of the changes are already in CVS). However i 
just wrapped some of the original code because i did not want to 
change to much. So if you want to refactor XTMBuilder (which i think is 
a good idea), i would like to ask you to wait some more days in order for me to get everything I changed into the cvs.  I will send you an email as soon as i finished my basic 
changes.
I would also like to suggest seperating the TopicMapBuilder and 
TopicMapHandler implementations (e.g. by moving the TopicMapHandler Code 
into a abstract Base Class XTMHandler) for better managability of this class.

One more thing, what is the status of the DOM implementation ? I had to 
change the DOMTopicMapImpl (getProvider method) but could not find a 
TopicMapProvider implemenation.

Cheers
 
Harald

> >Hi guys,
> >
> >Harald, are you currently working on implementing support for TopicMapBuilder 
> >reading a Reader, rather than an InputStream? If not, I'd happily do it... 
> >looks like something the SerializedTopicMapSource could use. :-)
> >
> >Just give me a quick go or no-go -- I'd like to make sure I won't tread on 
> >your toes.
> >
> >Kal, if Harald gives me a go, I'd like to modify XTMBuilder so it no longer 
> >uses the deprecated SAX1 classes for parsing, but the SAX2 XMLReader instead. 
> >Objections? 
> >
> >Later,
> >Florian
______________________________________________________________________________
38xTestsieger - WEB.DE FreeMail - Deutschlands beste E-Mail! Jetzt das
neue FreeMail-Handbuch  http://f.web.de/extern/handbuch.htm/?mc=021131

[Tm4j-developers] TopicMapBuilder: support Reader in addition to InputStream, XTMBuilder: move to SAX2

[Florian G. H. <f.g...@gm...>]

Hi guys,

Harald, are you currently working on implementing support for TopicMapBuilder 
reading a Reader, rather than an InputStream? If not, I'd happily do it... 
looks like something the SerializedTopicMapSource could use. :-)

Just give me a quick go or no-go -- I'd like to make sure I won't tread on 
your toes.

Kal, if Harald gives me a go, I'd like to modify XTMBuilder so it no longer 
uses the deprecated SAX1 classes for parsing, but the SAX2 XMLReader instead. 
Objections? 

Later,
Florian

-- 
Florian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

[Tm4j-developers] New classes in org.tm4j.topicmap.utils

[Florian G. H. <f.g...@gm...>]

Hello all,

I've committed  a couple of helper classes this afternoon that should greatly 
simplify two of the most common operations in working with topic maps: 
loading and merging (from files, URLs, or other input streams), and 
serializing (to files or other output streams). Both classes reside in the 
org.tm4j.topicmap.utils package, they're named TopicMapMerger and 
TopicMapSerializer, respectively. 

Both classes follow a design I call "beanish"[1] and extend another new class, 
HelperBase, which provides basic support for vetoable and non-vetoable 
properties, and jakarta-commons logging. All three classes are fairly 
extensively documented, please take a look at the Javadoc if you can find the 
time.

I have also refactored some of the classes in the org.tm4j.topicmap.cmd 
package -- specifically, AppBase and Merge -- so they use the new helper 
classes. I have preserved the signatures of the convenience methods in 
AppBase, even though that causes the code to get a bit awkward, calling to 
and fro the new helper class. But the code, IMHO, is now much cleaner than 
before, and the new helper classes do away with much duplicate code that was 
originally present in the command line apps.

The "beanish" design, I hope, lends itself well to being used in other 
applications, such as Ant tasks, servlets and the like.

There is one minor disruption the new classes cause: I've had to move 
SourceAddressPair out of TopicMapList, and it is now its own separate class 
in org.tm4j.topicmap.utils. I've updated the other classes to reflect this, 
but in case I did forget to commit a file or so, please give a holler. 
Everything compiles cleanly on my machine now, and all tests for the 
in-memory backend succeed as well, but you never know. :-) On the plus side, 
the overloaded addSource() methods in TopicMapMerger make the 
SourceAddressPair class somewhat obsolete anyway. I'd be happy to add support 
for Harald's TopicMapSource abstraction when it gets done; I haven't had a 
chance to look at it yet.

I have also taken the liberty to remove the invocations of Log4J 
BasicConfigurator.configure() from the command-line apps, so as to remove 
compile-time dependencies on Log4J and leave logging configuration to the 
jakarta-commons logging environment.

And by the way, the EclipseProjectTask is better tested now. I've committed an 
updated version of that as well. I realize that that class is a bit misplaced 
in TM4J, I guess I'll eventually submit it to the Ant people. :-)

Looking forward to hearing from you guys soon,
Take care,
Florian



[1] I'm not quite sure whether these classes actually conform to the JavaBeans 
spec. They should for the most part, though.

-- 
Florian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

[Tm4j-developers] TMHarvest and safe destroy

[Christoph F. <cf...@fo...>]

Hi

we would like to do a first official release of tmharvest in the next
two or three weeks.

Currently, one functionality is still missing, namely an implementation
of safely destroying any of the existing TopicMapObjects, as it was
mentioned on this list a while ago.

I just wanted to ask if maybe someone has done this already and is
willing to contribute it, since this would save us plenty of time.

With thanks in advance

Bye
c


-- 
Christoph Froehlich <cf...@fo...>