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

[Tm4j-developers] [ tm4j-Bugs-850441 ] Tolog query page should have link to topic map

[SourceForge.net <no...@so...>]

Bugs item #850441, was opened at 2003-11-27 21:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=850441&group_id=27895

Category: None
Group: TM4Web/Velocity 0.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Tolog query page should have link to topic map

Initial Comment:
In the TMBrowse application, the menu on the Tolog
query page should include a link back to the topic map
index page.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=850441&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-850107 ] Settings link causes Struts error

[SourceForge.net <no...@so...>]

Bugs item #850107, was opened at 2003-11-27 08:50
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=850107&group_id=27895

Category: None
Group: TM4Web/Velocity 0.1
Status: Open
Resolution: None
Priority: 7
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Settings link causes Struts error

Initial Comment:
From Harald:

I had a Problem with the settings link of the main
navigation. I included a copy of the error page as a
zip file. I use Tomcat 4.1.27 with windows xp running
on java 1.4.1_02. 

Looks like a Problem with the Struts configuration ....


This is a copy of the beginning of the StackTrace:

0    [Thread-6] ERROR
org.apache.struts.action.RequestProcessor  - No action ins
tance for path /render_template could be created
java.lang.ClassNotFoundException:
org.tm4j.vtl.struts.RenderTemplateAction
        at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1444)
        at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1289)
        at
org.apache.struts.util.RequestUtils.applicationClass(RequestUtils.jav
a:207)
        at
org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.
java:231)
        at
org.apache.struts.action.RequestProcessor.processActionCreate(Request
Processor.java:326)
        at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.ja
va:268)
        at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:148
2)
        at
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)


----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2003-11-27 08:51

Message:
Logged In: YES 
user_id=176992

The settings link should be removed from the default
templates as there is currently no user settings support.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=850107&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-850107 ] Settings link causes Struts error

[SourceForge.net <no...@so...>]

Bugs item #850107, was opened at 2003-11-27 08:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=850107&group_id=27895

Category: None
Group: TM4Web/Velocity 0.1
Status: Open
Resolution: None
Priority: 7
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Settings link causes Struts error

Initial Comment:
From Harald:

I had a Problem with the settings link of the main
navigation. I included a copy of the error page as a
zip file. I use Tomcat 4.1.27 with windows xp running
on java 1.4.1_02. 

Looks like a Problem with the Struts configuration ....


This is a copy of the beginning of the StackTrace:

0    [Thread-6] ERROR
org.apache.struts.action.RequestProcessor  - No action ins
tance for path /render_template could be created
java.lang.ClassNotFoundException:
org.tm4j.vtl.struts.RenderTemplateAction
        at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1444)
        at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa
der.java:1289)
        at
org.apache.struts.util.RequestUtils.applicationClass(RequestUtils.jav
a:207)
        at
org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.
java:231)
        at
org.apache.struts.action.RequestProcessor.processActionCreate(Request
Processor.java:326)
        at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.ja
va:268)
        at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:148
2)
        at
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=850107&group_id=27895

Re: [Tm4j-developers] Proposal for solving the Ozone XTMBuilder "Problem"

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

Hi Harald,

Both of those suggestions make sense to me. I'm just in the process of
creating the 0.9.0a1 release. I think it would be worth doing these
changes for 0.9.0a2.

Cheers,

Kal

On Sun, 2003-11-23 at 09:10, Harald Kuhn wrote:
> Hi Kal,
> 
> I thought more about the "Probelm" we had with the Ozone backend having its own XTMBuilder. I you solved that for the time beeing but i think we need a more general solution. An XML Database for example would probably also have its own XTMBuilder. 
> 
> So i suggest delegating the decision for the "right" TopicMapBuilder to the TopicMapProvider so every backend can habe its own TopicMapBuilder implementations if the need arises.
> 
> I think adding a Method 
> 
> public TopicMapBuilder getBuilder(String notation);
> 
> would probably be enough. We can than add a general implementation to TopicMapSourceSupport and just override this in the Ozone Provider. The impact should be minimal as we wont change anything in the Builder.
> 
> A second thought arises to me while writing this. We could also add a new build 
> 
> public void build(InputStream src, Locator srcLoc, TopicMap tm)
> 
> method to the  TopicMapBuilders and depcrecate the old one. The Provider can be retrieved from the TopicMap object and so would not be needed anymore as a parameter in the build method. It also would prevent the accidental use of incompatibel TopicMapProvider and TopicMap implementations together.
> 
> 
> Cheers
> 
> Harald
> ______________________________________________________________________________
> Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2
> Kostenlos downloaden: http://screensaver.web.de/?mc=021110
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] [ tm4j-Bugs-813946 ] No XTM examples in http://www.tm4j.org/examples/

[SourceForge.net <no...@so...>]

Bugs item #813946, was opened at 2003-09-28 11:18
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=813946&group_id=27895

Category: Examples
Group: None
>Status: Closed
>Resolution: Rejected
>Priority: 7
Submitted By: Anthony B. Coates (abcoates)
>Assigned to: Kal Ahmed (kal_ahmed)
Summary: No XTM examples in http://www.tm4j.org/examples/

Initial Comment:
The XTM examples that come with TM4J refer to XTM 
files in "http://www.tm4j.org/examples/".  However, 
none of those URLs resolve to an XTM file as expected.  
Could you put the examples back in place?  Also, could 
you supply them with the TM4J distribution, for people 
doing off-line development (i.e. on a laptop while 
travelling).  Thanks!  Cheers, Tony.

----------------------------------------------------------------------

Comment By: Anthony B. Coates (abcoates)
Date: 2003-09-28 12:03

Message:
Logged In: YES 
user_id=29175

!!! Ignore this!  I don't know why, I was having some trouble 
before, but now the examples all run, in spite of the physical 
URLs not being resolvable.  I guess I need to understand the 
examples more, and how they locate the example topic 
maps.  Sorry about that!  Cheers, Tony.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=813946&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-838468 ] Integrity check on Association.destroy() fails

[SourceForge.net <no...@so...>]

Bugs item #838468, was opened at 2003-11-08 16:46
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=838468&group_id=27895

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christoph Fröhlich (c_froehlich)
Assigned to: Nobody/Anonymous (nobody)
Summary: Integrity check on Association.destroy() fails 

Initial Comment:
org.tm4j.topicmap.memory.AssociationImpl.destroy()

the following if-clause never evaluates to true, since
the Collection returned by getSubjectIndicators() does
not contain Strings but Locators.

Therefore the IntegrityViolationException is never thrown



if ((getType() != null)
	    &&
(getType().getSubjectIndicators().contains(PSI.ASSOC_CLASS_INSTANCE))
	    && ((getScope() == null) ||
(getScope().getThemes().isEmpty())))
	{

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2003-11-23 20:06

Message:
Logged In: YES 
user_id=176992

Fixed - test is now against a Locator object created from
XTMPSI.CLASS_INSTANCE

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=838468&group_id=27895

[Tm4j-developers] Proposal for solving the Ozone XTMBuilder "Problem"

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

Hi Kal,

I thought more about the "Probelm" we had with the Ozone backend having its own XTMBuilder. I you solved that for the time beeing but i think we need a more general solution. An XML Database for example would probably also have its own XTMBuilder. 

So i suggest delegating the decision for the "right" TopicMapBuilder to the TopicMapProvider so every backend can habe its own TopicMapBuilder implementations if the need arises.

I think adding a Method 

public TopicMapBuilder getBuilder(String notation);

would probably be enough. We can than add a general implementation to TopicMapSourceSupport and just override this in the Ozone Provider. The impact should be minimal as we wont change anything in the Builder.

A second thought arises to me while writing this. We could also add a new build 

public void build(InputStream src, Locator srcLoc, TopicMap tm)

method to the  TopicMapBuilders and depcrecate the old one. The Provider can be retrieved from the TopicMap object and so would not be needed anymore as a parameter in the build method. It also would prevent the accidental use of incompatibel TopicMapProvider and TopicMap implementations together.


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] what backend to choose

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

Hi Stefan,

On Wed, 2003-11-19 at 15:18, Stefan Lischke wrote:
> Hi there,
> 
> I'm wondering which Backend i should use with tm4j. I'm building a XTM 
> ContentManagement System ontop of TMAPI. I want to support a wide range 
> of TMAPI implementations, also TM4j.
> 
> But which backend should i use, the ozone or the hibernate?
> 
> Performance is a big issue. I'm building a lot of XTM Fragments and 
> there is a frequently updating from different Clients (maybe at the same 
> time). My System is running as a Webapplication in tomcat or jetty.
> Which backend supports indexing?
> 

Both backends support the TM4J indexing interfaces. However, on the
Ozone backend, this is implemented using serialized Java HashMaps which
means that a lookup can become inefficient as the topic map gets larger.
At some point in the future I plan to move the Ozone indexing over to
use Ozone's native collection implementations (which should be more
efficient for large collections). On the Hibernate backend, the indexing
interfaces are implemented using Hibernate Query Language (which gets
translated into SQL) - this makes them quite efficient, even as the size
of the database grows.

In my experience so far I have found Ozone to be faster for small/medium
sized topic maps (say up to 50000 topics+associations) but performance
drops off really rapidly as those index HashMaps get bigger (because
they have to be completely read into JVM memory).

Right now my advice would be to go for the Hibernate backend - assuming
that you have an RDBMS you can use.

> Another question is about TMAPI in tm4j, there was a discussion about 
> ID's on tmapi-discuss ML the last weeks and the result was the new Methods:
> 
> TopicMapObject.getID()
> TopicMap.getObjectByID()
> 
> how difficult will be an implementation of these methods? Can i help
> 

That should be really easy to add. The TM4J interfaces already have both
of these methods, so it is just a question of putting a wrapper around
it.

I still need to get those suggested TMAPI changes written up and
circulated to the TMAPI list. I also still need to write up the TMAPI
indexing interface proposal. I'll try and do that today or tomorrow...I
promise! ;-)

Cheers,

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

[Tm4j-developers] what backend to choose

[Stefan L. <li...@no...>]

Hi there,

I'm wondering which Backend i should use with tm4j. I'm building a XTM 
ContentManagement System ontop of TMAPI. I want to support a wide range 
of TMAPI implementations, also TM4j.

But which backend should i use, the ozone or the hibernate?

Performance is a big issue. I'm building a lot of XTM Fragments and 
there is a frequently updating from different Clients (maybe at the same 
time). My System is running as a Webapplication in tomcat or jetty.
Which backend supports indexing?

Another question is about TMAPI in tm4j, there was a discussion about 
ID's on tmapi-discuss ML the last weeks and the result was the new Methods:

TopicMapObject.getID()
TopicMap.getObjectByID()

how difficult will be an implementation of these methods? Can i help

thanx in advance stefan

Re: TopicMapProviderFactory configuration properties (was Re: [Tm4j-developers] [DONE] Make TopicMapProviderFactory a "real" factory)

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

On Thu, 2003-11-13 at 22:26, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello again.
> 
> On Thursday 13 November 2003 22:00, Kal Ahmed wrote:
> | I think that the best way of making this clear in the API is to leave it
> | as it currently is with an initialise() method that receives the
> | configuration properties. I don't really like the idea of the
> | TopicMapProvider pulling properties from the TopicMapProviderFactory. If
> | I under stand you correctly, I think you feel the same way. 
> 
> Correct.
> 
> | My proposal
> | was just that you have TopicMapProviderFactory.newInstance() read a
> | default set of provider configuration properties. 
> 
> OK -- what would those be? My ideas were quite similar, but I got stuck trying 
> to determine an appropriate "default set of provider configuration 
> properties", to be honest...
> 
> | Then when you call the
> | newTopicMapProvider() method, those properties get passed through by the
> | factory to the initialise() method of the Provider. If you call the
> | newTopicMapProvider(Properties) method, then the properties passed
> | through to the Provider are the default properties overwritten with the
> | properteis passed into the newTopicMapProvider(Properties) method.
> 
> Hmmm. I was actually thinking about catering for configuration properties that 
> affect the entire factory and subsequently created providers. Like a 
> SAXParserFactory which you can configure to create namespace-aware and 
> non-namespace-aware, or validating and non-validating parsers. I must admit, 
> however, that I can't currently think of any such factory-wide config 
> settings that would make sense for the TopicMapProviderFactory. So this would 
> qualify as a nice-but-not-necessary feature. :-) 
> 
I agree - I don't think that there are any meaningful factory
configuration properties, but I was just thinking that it would be
convenient for developers of providers and to users to have the abstract
TopicMapProviderFactory class implement a scheme for reading provider
configuration information from the system environment. I was thinking
that the TopicMapProviderFactory class could implement a scheme similar
to the one used to determine the concrete implementation to load - i.e.
read from system properties and/or from META-INF resources. There would
not be any properties that configure the factory, but they would instead
be used as default values for configuration of the providers created by
the factory.

> BTW, how is your testing on TopicMapSourceSupport and the modified 
> TopicMapProvider interface coming along? I'd like to add support for 
> TopicMapSource to the TopicMapMerger class (and consequently for the 
> TopicMapMergingTask as well). Could you give me a status update on that?
> 

I still need to update some of the unit tests to test the
SerializedTopicMapSource class. I'll let you know when that is done.

Cheers,

Kal

Re: TopicMapProviderFactory configuration properties (was Re: [Tm4j-developers] [DONE] Make TopicMapProviderFactory a "real" factory)

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

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

Hello again.

On Thursday 13 November 2003 22:00, Kal Ahmed wrote:
| I think that the best way of making this clear in the API is to leave it
| as it currently is with an initialise() method that receives the
| configuration properties. I don't really like the idea of the
| TopicMapProvider pulling properties from the TopicMapProviderFactory. If
| I under stand you correctly, I think you feel the same way.=20

Correct.

| My proposal
| was just that you have TopicMapProviderFactory.newInstance() read a
| default set of provider configuration properties.=20

OK -- what would those be? My ideas were quite similar, but I got stuck try=
ing=20
to determine an appropriate "default set of provider configuration=20
properties", to be honest...

| Then when you call the
| newTopicMapProvider() method, those properties get passed through by the
| factory to the initialise() method of the Provider. If you call the
| newTopicMapProvider(Properties) method, then the properties passed
| through to the Provider are the default properties overwritten with the
| properteis passed into the newTopicMapProvider(Properties) method.

Hmmm. I was actually thinking about catering for configuration properties t=
hat=20
affect the entire factory and subsequently created providers. Like a=20
SAXParserFactory which you can configure to create namespace-aware and=20
non-namespace-aware, or validating and non-validating parsers. I must admit=
,=20
however, that I can't currently think of any such factory-wide config=20
settings that would make sense for the TopicMapProviderFactory. So this wou=
ld=20
qualify as a nice-but-not-necessary feature. :-)=20

BTW, how is your testing on TopicMapSourceSupport and the modified=20
TopicMapProvider interface coming along? I'd like to add support for=20
TopicMapSource to the TopicMapMerger class (and consequently for the=20
TopicMapMergingTask as well). Could you give me a status update on that?

Thanks in advance,
=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/tAUMgW2VC0bQC+MRAtepAJ9gKPIkgUvXEFMaqTt8cKOcq/a9iACdFbrm
R6heFFXHNX6mNCPKK0vqFww=3D
=3DNZ/0
=2D----END PGP SIGNATURE-----

Re: TopicMapProviderFactory configuration properties (was Re: [Tm4j-developers] [DONE] Make TopicMapProviderFactory a "real" factory)

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

On Thu, 2003-11-13 at 17:13, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi.
> 
> On Thursday 13 November 2003 09:59, Kal Ahmed wrote:
> 
> | > That's all. Instantiating the subclass directly is not discouraged per
> | > se; you only give up backend independence when doing so. If you don't
> | > need backend independence, no-one forces you to make use of it. :-)
> |
> | That is more or less how I have documented this in the updated
> | Developer's Guide.
> 
> I saw that, thanks a lot for updating that section!
> 
> | > You got me thinking about factory properties, however. I'm beginning to
> | > think that being able to set configuration properties on the factory
> | > object is not a bad idea at all. So we could add property-modifying
> | > methods to the factory base class. That way all concrete subclasses would
> | > inherit a means of setting and accessing configuration properties for the
> | > factory, which would then presumably affect all TopicMapProviders
> | > subsequently created by that factory. How's that sound?
> |
> | Do you mean default properties that get passed to the
> | newTopicMapProvider() method ? If so then I agree - just like selecting
> | which backend to use, specifying the properties for the provider is a
> | common operation for most applications, so having a standard way of
> | reading that configuration information from the environment makes sense
> | to me.
> 
> I believe that the TopicMapProvider "inheriting" configuration properties from 
> the factory is an option, but not always necessary or appropriate. I do not 
> believe that the set of *factory* configuration properties should be passed 
> directly to the newTopicMapProvider() method by the default implementation as 
> provided by the abstract base class.
> 
> I would think that it should be up to the concrete implementing subclass to 
> decide just what to do with these properties, and that the abstract base 
> class should only define the means for storing and retrieving them. The only 
> thing that needs to be guaranteed by all concrete subclasses of 
> TopicMapProviderFactory, IMHO, is that any change to any of the configuration 
> properties only affects *subsequently* constructed TopicMapProviders, rather 
> than retroactively modifying properties of TopicMapProviders created prior to 
> the configuration property change.
> 

I think that the best way of making this clear in the API is to leave it
as it currently is with an initialise() method that receives the
configuration properties. I don't really like the idea of the
TopicMapProvider pulling properties from the TopicMapProviderFactory. If
I under stand you correctly, I think you feel the same way. My proposal
was just that you have TopicMapProviderFactory.newInstance() read a
default set of provider configuration properties. Then when you call the
newTopicMapProvider() method, those properties get passed through by the
factory to the initialise() method of the Provider. If you call the
newTopicMapProvider(Properties) method, then the properties passed
through to the Provider are the default properties overwritten with the
properteis passed into the newTopicMapProvider(Properties) method. 

Cheers,

Kal

TopicMapProviderFactory configuration properties (was Re: [Tm4j-developers] [DONE] Make TopicMapProviderFactory a "real" factory)

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

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

Hi.

On Thursday 13 November 2003 09:59, Kal Ahmed wrote:

| > That's all. Instantiating the subclass directly is not discouraged per
| > se; you only give up backend independence when doing so. If you don't
| > need backend independence, no-one forces you to make use of it. :-)
|
| That is more or less how I have documented this in the updated
| Developer's Guide.

I saw that, thanks a lot for updating that section!

| > You got me thinking about factory properties, however. I'm beginning to
| > think that being able to set configuration properties on the factory
| > object is not a bad idea at all. So we could add property-modifying
| > methods to the factory base class. That way all concrete subclasses wou=
ld
| > inherit a means of setting and accessing configuration properties for t=
he
| > factory, which would then presumably affect all TopicMapProviders
| > subsequently created by that factory. How's that sound?
|
| Do you mean default properties that get passed to the
| newTopicMapProvider() method ? If so then I agree - just like selecting
| which backend to use, specifying the properties for the provider is a
| common operation for most applications, so having a standard way of
| reading that configuration information from the environment makes sense
| to me.

I believe that the TopicMapProvider "inheriting" configuration properties f=
rom=20
the factory is an option, but not always necessary or appropriate. I do not=
=20
believe that the set of *factory* configuration properties should be passed=
=20
directly to the newTopicMapProvider() method by the default implementation =
as=20
provided by the abstract base class.

I would think that it should be up to the concrete implementing subclass to=
=20
decide just what to do with these properties, and that the abstract base=20
class should only define the means for storing and retrieving them. The onl=
y=20
thing that needs to be guaranteed by all concrete subclasses of=20
TopicMapProviderFactory, IMHO, is that any change to any of the configurati=
on=20
properties only affects *subsequently* constructed TopicMapProviders, rathe=
r=20
than retroactively modifying properties of TopicMapProviders created prior =
to=20
the configuration property change.

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/s7vSgW2VC0bQC+MRAtPfAKDVSxQmF/GDRhAPEXLSkXchzzIrUgCfTFib
38DibksRXYLpsXujmZ6wsNU=3D
=3DyGtn
=2D----END PGP SIGNATURE-----

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

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

On Wed, 2003-11-12 at 21:10, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello.
> 
> On Wednesday 12 November 2003 12:08, Harald Kuhn wrote:
> | > Well unless Kal objects, I guess the best option is to just add the
> | > org.tm4j.jndi package to the tm4j.sources patternset, so it will be
> | > picked up by the tm4j-build target when compiling.
> |
> | +1
> 
> I just took care of this. Kal, I didn't hear you objecting, but if you do,
> please roll back my latest commit of build.xml.
> 

It works for me :)

> | E.g. in TMNav you could instanciate a new Provider by giving its factoreis
> | classname (inside a swing textfield during runtime). Also i am still not
> | quite sure how to use different providers together (could you please
> | clarify this ?).
> 
> If you want to be sure to get an instance of a particular concrete factory
> class, you instantiate it by invoking its constructor. So, rather than:
> 
> import org.tm4j.topicmap.TopicMapProviderFactory;
> // ... lots of code here
> TopicMapProviderFactory factory = TopicMapProviderFactory.newInstance();
> 
> - -- which would leave it to the abstract TopicMapProviderFactory to select the
> concrete subclass, based on the selection algorithm discussed on this list
> - --, you would use:
> 
> import org.tm4j.topicmap.hibernate.TopicMapProviderFactoryImpl;
> // ... lots of code here
> TopicMapProviderFactoryImpl factory = new TopicMapProviderFactoryImpl;
> 
> or, alternatively:
> 
> String className = swingTextBox.getText(); // pure pseudocode here!
> TopicMapProviderFactory factory =
> 	(TopicMapProviderFactory) Class.forName(className).newInstance();
> 
> That's all. Instantiating the subclass directly is not discouraged per se; you
> only give up backend independence when doing so. If you don't need backend
> independence, no-one forces you to make use of it. :-)
> 

That is more or less how I have documented this in the updated
Developer's Guide.

> | To get around this, I see (if you have other suggestions /
> | ideas, please let me know) two different options: we just use the
> | deprecated methods (not very clean in my opinion) or we add another
> | newInstance method to TopicMapProviderFactory where you can specify the
> | classname in a direct way (e.g. newInstance(String className) or
> | newInstace(Properties props)). The second one may be not in line with the
> | "normal facory behavier" (you seem to know more about that than I) but i
> | think it is much cleaner then using deprecated methods.
> 
> For this very purpose, providing an overloaded newInstance() that takes a
> class name is not necessary, you can simply instantiate the subclass directly
> if you need to; see above.
> 

Right, I agree too - as long as it is clear that concrete subclasses of
TopicMapProvider have to have a no-arguments constructor, then using the
Java Class.newInstance() method is the way to go - I think that it is
common enough practice for it to be familiar to most Java programmers.

> You got me thinking about factory properties, however. I'm beginning to think
> that being able to set configuration properties on the factory object is not
> a bad idea at all. So we could add property-modifying methods to the factory
> base class. That way all concrete subclasses would inherit a means of setting
> and accessing configuration properties for the factory, which would then
> presumably affect all TopicMapProviders subsequently created by that factory.
> How's that sound?
> 

Do you mean default properties that get passed to the
newTopicMapProvider() method ? If so then I agree - just like selecting
which backend to use, specifying the properties for the provider is a
common operation for most applications, so having a standard way of
reading that configuration information from the environment makes sense
to me.

Cheers,

Kal

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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.

On Wednesday 12 November 2003 12:08, Harald Kuhn wrote:
| > Well unless Kal objects, I guess the best option is to just add the
| > org.tm4j.jndi package to the tm4j.sources patternset, so it will be
| > picked up by the tm4j-build target when compiling.
|
| +1

I just took care of this. Kal, I didn't hear you objecting, but if you do,
please roll back my latest commit of build.xml.

| E.g. in TMNav you could instanciate a new Provider by giving its factoreis
| classname (inside a swing textfield during runtime). Also i am still not
| quite sure how to use different providers together (could you please
| clarify this ?).

If you want to be sure to get an instance of a particular concrete factory
class, you instantiate it by invoking its constructor. So, rather than:

import org.tm4j.topicmap.TopicMapProviderFactory;
// ... lots of code here
TopicMapProviderFactory factory = TopicMapProviderFactory.newInstance();

- -- which would leave it to the abstract TopicMapProviderFactory to select the
concrete subclass, based on the selection algorithm discussed on this list
- --, you would use:

import org.tm4j.topicmap.hibernate.TopicMapProviderFactoryImpl;
// ... lots of code here
TopicMapProviderFactoryImpl factory = new TopicMapProviderFactoryImpl;

or, alternatively:

String className = swingTextBox.getText(); // pure pseudocode here!
TopicMapProviderFactory factory =
	(TopicMapProviderFactory) Class.forName(className).newInstance();

That's all. Instantiating the subclass directly is not discouraged per se; you
only give up backend independence when doing so. If you don't need backend
independence, no-one forces you to make use of it. :-)

| To get around this, I see (if you have other suggestions /
| ideas, please let me know) two different options: we just use the
| deprecated methods (not very clean in my opinion) or we add another
| newInstance method to TopicMapProviderFactory where you can specify the
| classname in a direct way (e.g. newInstance(String className) or
| newInstace(Properties props)). The second one may be not in line with the
| "normal facory behavier" (you seem to know more about that than I) but i
| think it is much cleaner then using deprecated methods.

For this very purpose, providing an overloaded newInstance() that takes a
class name is not necessary, you can simply instantiate the subclass directly
if you need to; see above.

You got me thinking about factory properties, however. I'm beginning to think
that being able to set configuration properties on the factory object is not
a bad idea at all. So we could add property-modifying methods to the factory
base class. That way all concrete subclasses would inherit a means of setting
and accessing configuration properties for the factory, which would then
presumably affect all TopicMapProviders subsequently created by that factory.
How's that sound?

Harald, one more thing: You asked for help on JUnit tests a few days ago,
IIRC. I seem to have deleted that message by accident, so I don't remember on
what kind of tests you specifically asked for support. :-( Please fill me in
and I'll jump in if I can.

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).

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

iD8DBQE/sqG3gW2VC0bQC+MRAhabAKD/GY/CjYsV0ABYHAe4WUfNTbetNwCgz1Il
yyNfPJXFo6V3clTXZvSJ4T0=
=q2Jq
-----END PGP SIGNATURE-----

Re: [Tm4j-developers] Re: TopicMapSource implementation

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

On Wed, 2003-11-12 at 10:29, Harald Kuhn wrote:
> Hi Kal,
> > 
> > Hi Harald,
> > 
> > While I was doing this implementation, I noticed that the addTopicMap()
> > methods that take a TopicMapSource are specified on
> > TopicMapProviderBase, not on the TopicMapProvider interface, 
> 
> I did that on purpose because i wanted to wait with adding the new methods to the Interface until after the ozone "problem" was solved (in order not to break the code to much).
> 
I wondered if that was the reason why. Well, it compiles OK. I guess
that I need to add some unit tests (or change the existing tests to use
TopicMapSources) to make sure that it runs OK - but I can't see any
reason why it shouldn't...

> > so I've
> > added the declarations to the TopicMapProvider interface. I have also
> > created a new class called TopicMapSourceSupport (in the
> > org.tm4j.topicmap.source package) which provides the default
> > implementations of these methods. So by making TopicMapProviderBase and
> > the OzoneTopicMapProviderImpl classes extend TopicMapSourceSupport, I
> > can make use of the common base class to provide the handling of
> > TopicMapSources.
> 
> If we are already on this: I thougth wether it would not be better to move the XML Catalog support into a  Utility class ?! We should probably consult Murray on this ...
> 
That would be a good idea. Currently the resolver is "activated" by
specifying a system property. Could we use that system property to allow
a catalog path to be speciifed ? At the moment the catalog resolver uses
a default path (resource/tm4j.xcat), but in some environments it might
be useful to have a different catalog file path or even to have multiple
catalogs.

Murray, what do you think about extracting the catalog resolution
services from TopicMapProviderBase ? We could create an
org.tm4j.topicmap.utils.CatalogResolver class, put the resolveEntity()
method in that and then invoke it from TopicMapProviderBase and from
SerializedTopicMapSource as needed.

Cheers,

Kal

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

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

Hi Florian,


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello.
> 
> On Monday 10 November 2003 13:50, Harald Kuhn wrote:
> | > 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).
> 
> Well unless Kal objects, I guess the best option is to just add the 
> org.tm4j.jndi package to the tm4j.sources patternset, so it will be picked up 
> by the tm4j-build target when compiling.

+1

> | By the way, it wont work with the JNDI implementation as the spi
> | ProviderFactory depends on a public NoArgumentConstructor
> | (Class.newInstance()). 
> 
> I'm confused now: The abstract TopicMapProviderFactory *itself* depends on 
> there being a no-arg public constructor in the implementing subclass. So that 
> can't be the problem, and I'm almost sure I'm missing your point. Please 
> clarify. :-)

Sorry, part of this malfunction was my own fault (i got confused about this because i got some exceptions indicating instanciation problems), I got a mixture of "old" and new classes. There are some parts however which (at the moment) wont work without using depcretacted methods. 

E.g. in TMNav you could instanciate a new Provider by giving its factoreis classname (inside a swing textfield during runtime). Also i am still not quite sure how to use different providers together (could you please clarify this ?). To get around this, I see (if you have other suggestions / ideas, please let me know) two different options: we just use the deprecated methods (not very clean in my opinion) or we add another newInstance method to TopicMapProviderFactory where you can specify the classname in a direct way (e.g. newInstance(String className) or newInstace(Properties props)). The second one may be not in line with the "normal facory behavier" (you seem to know more about that than I) but i think it is much cleaner then using deprecated methods.

> | 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.
> 
> OK. I have one more request to you: Could you please run the sources in 
> org.tm4j.jndi through Jalopy, then check them back in? They are really 
> difficult to follow at times, with tabs instead of spaces and missing braces 
> in "else" clauses all over the place. I would be really helpful if that were 
> fixed. :-) 
>
> Later,
> Florian
> 

Cheers 
Harald
______________________________________________________________________________
WEB.DE FreeMail wird 5 Jahre jung! Feiern Sie mit uns und
nutzen Sie die neuen Funktionen http://f.web.de/features/?mc=021130

Re: [Tm4j-developers] Re: TopicMapSource implementation

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

Hi Kal,
> 
> Hi Harald,
> 
> While I was doing this implementation, I noticed that the addTopicMap()
> methods that take a TopicMapSource are specified on
> TopicMapProviderBase, not on the TopicMapProvider interface, 

I did that on purpose because i wanted to wait with adding the new methods to the Interface until after the ozone "problem" was solved (in order not to break the code to much).

> so I've
> added the declarations to the TopicMapProvider interface. I have also
> created a new class called TopicMapSourceSupport (in the
> org.tm4j.topicmap.source package) which provides the default
> implementations of these methods. So by making TopicMapProviderBase and
> the OzoneTopicMapProviderImpl classes extend TopicMapSourceSupport, I
> can make use of the common base class to provide the handling of
> TopicMapSources.

If we are already on this: I thougth wether it would not be better to move the XML Catalog support into a  Utility class ?! We should probably consult Murray on this ...

> Does that make sense ? 

Defenitly :)

> AFAICS it does, but I just wanted to check that
> there wasn't something subtle that I was missing before doing the
> check-in... :)
> 
> Cheers,

Cheers,
Harald
______________________________________________________________________________
Tippen Sie mit der cleveren Kombination von Zusammen und Alleine. Der neue Weg 
zum Lottoglueck: WEB.DE Spielgemeinschaften! https://spielgemeinschaften.web.de/

Re: [Tm4j-developers] Re: TopicMapSource implementation

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

Hi Harald,

While I was doing this implementation, I noticed that the addTopicMap()
methods that take a TopicMapSource are specified on
TopicMapProviderBase, not on the TopicMapProvider interface, so I've
added the declarations to the TopicMapProvider interface. I have also
created a new class called TopicMapSourceSupport (in the
org.tm4j.topicmap.source package) which provides the default
implementations of these methods. So by making TopicMapProviderBase and
the OzoneTopicMapProviderImpl classes extend TopicMapSourceSupport, I
can make use of the common base class to provide the handling of
TopicMapSources.

Does that make sense ? AFAICS it does, but I just wanted to check that
there wasn't something subtle that I was missing before doing the
check-in... :)

Cheers,

Kal
On Mon, 2003-11-10 at 20:40, Kal Ahmed wrote:
> On Mon, 2003-11-10 at 13:32, Harald Kuhn wrote:
> > 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 ) .
> > 
> 
> I think that it is probably best to handle the Ozone backend as a
> special case inside SerializedTopicMapSource. I wonder if the approach
> of the OzoneXTMBuilder can be generalised. Currently chunking is
> performed by a SAX parser on the client, but it might make more sense
> for the client to simply send chunks of bytes to the parser and have all
> parsing done on the server side. However, I think thats a bit more
> hardcore Ozone programming than I really want to get into right now, so
> its something to postpone for a post 0.9.0 alpha
> 
> > 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).
> > 
> No problem. I'll just implement the lazy solution for now :)
> 
> Cheers,
> 
> Kal
-- 
Kal Ahmed <ka...@te...>
techquila

Re: [Tm4j-developers] SourceForge bug tracking system

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

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

Hi!

On Monday 10 November 2003 21:47, Kal Ahmed wrote:
| Hmmm....lets see
|
| [rummage around on site for a bit]
|
| Done it! For now all traffic will go to tm4j-developers, I don't think
| that its currently worth creating a separate list for trackers. If the
| volume of bugs gets too great we can always consider creating a separate
| list for them.

Perfect! Thanks a lot!

:-)
=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/r/vYgW2VC0bQC+MRAkqcAKD67z9CnYv2yJ9MHQ76hhVbwzSOLACfZ11o
+Ff7Pel2VBiG9feevhQqqdQ=3D
=3D0hM4
=2D----END PGP SIGNATURE-----

Re: [Tm4j-developers] SourceForge bug tracking system

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

Hmmm....lets see

[rummage around on site for a bit]

Done it! For now all traffic will go to tm4j-developers, I don't think
that its currently worth creating a separate list for trackers. If the
volume of bugs gets too great we can always consider creating a separate
list for them.

Cheers,

Kal

PS - I've done this for Bugs, Support Requests and Feature Requests.

On Mon, 2003-11-10 at 17:50, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Kal,
> 
> Not being a SourceForge project admin, I don't know whether there exists a 
> possibility to configure the SF bug tracking system in such a way that 
> whenever a new bug is filed, the developers list is automatically notified. 
> Is such an option available, like in Bugzilla? If it is, I humbly propose to 
> enable it, as it tends to add additional publicity to newly reported issues.
> 
> We currently have 6 open bugs in the bug tracking system, of which I believe 
> only the respective reporters are aware. :-)
> 
> Just my 2 cents.
> 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/r8/wgW2VC0bQC+MRAg58AJ4rgIHtjnfhuiowkqpkaQlSXluaGwCePNiZ
> li3BFpg9FLNvlHLNvOX7XXU=
> =5JIZ
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] Re: TopicMapSource implementation

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

On Mon, 2003-11-10 at 13:32, Harald Kuhn wrote:
> 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 ) .
> 

I think that it is probably best to handle the Ozone backend as a
special case inside SerializedTopicMapSource. I wonder if the approach
of the OzoneXTMBuilder can be generalised. Currently chunking is
performed by a SAX parser on the client, but it might make more sense
for the client to simply send chunks of bytes to the parser and have all
parsing done on the server side. However, I think thats a bit more
hardcore Ozone programming than I really want to get into right now, so
its something to postpone for a post 0.9.0 alpha

> 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).
> 
No problem. I'll just implement the lazy solution for now :)

Cheers,

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

[Tm4j-developers] SourceForge bug tracking system

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

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

Hi Kal,

Not being a SourceForge project admin, I don't know whether there exists a=
=20
possibility to configure the SF bug tracking system in such a way that=20
whenever a new bug is filed, the developers list is automatically notified.=
=20
Is such an option available, like in Bugzilla? If it is, I humbly propose t=
o=20
enable it, as it tends to add additional publicity to newly reported issues.

We currently have 6 open bugs in the bug tracking system, of which I believ=
e=20
only the respective reporters are aware. :-)

Just my 2 cents.
=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/r8/wgW2VC0bQC+MRAg58AJ4rgIHtjnfhuiowkqpkaQlSXluaGwCePNiZ
li3BFpg9FLNvlHLNvOX7XXU=3D
=3D5JIZ
=2D----END PGP SIGNATURE-----

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

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

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

Hello.

On Monday 10 November 2003 13:50, Harald Kuhn wrote:
| > 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 targ=
et
| > 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 plea=
se
| make suggestions).

Well unless Kal objects, I guess the best option is to just add the=20
org.tm4j.jndi package to the tm4j.sources patternset, so it will be picked =
up=20
by the tm4j-build target when compiling.

| By the way, it wont work with the JNDI implementation as the spi
| ProviderFactory depends on a public NoArgumentConstructor
| (Class.newInstance()).=20

I'm confused now: The abstract TopicMapProviderFactory *itself* depends on=
=20
there being a no-arg public constructor in the implementing subclass. So th=
at=20
can't be the problem, and I'm almost sure I'm missing your point. Please=20
clarify. :-)

| 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 f=
or
| 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.

OK. I have one more request to you: Could you please run the sources in=20
org.tm4j.jndi through Jalopy, then check them back in? They are really=20
difficult to follow at times, with tabs instead of spaces and missing brace=
s=20
in "else" clauses all over the place. I would be really helpful if that wer=
e=20
fixed. :-)=20

Later,
=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/r8wagW2VC0bQC+MRAm9KAKC6L65yce4ie0MaDO4PA8fN/RBJgwCgsEVx
OwUcLCzYk6eMO15nvq3Ei84=3D
=3DXOE0
=2D----END PGP SIGNATURE-----

[Tm4j-developers] Last night's syncmail message (was Fwd: Mail delivery failed: returning message to sender)

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

Hi,

as indicated in last night's message of mine, apparently the syncmail message 
for my most recent commit never made it through to the tm4j-commits list. So 
I'm posting it here for reference just in case it's useful to anyone.

Quite apparently something was very wrong on SF.net last night; apart from not 
being able to dispatch this commit message, the mail server also forgot to 
send me a copy of my own tm4j-developers post. Let's hope everything's OK 
now. :-)

Later
Florian

----------  Forwarded Message  ----------

Subject: Mail delivery failed: returning message to sender
Date: Sunday 09 November 2003 23:28
From: Mail Delivery System <Mai...@so...>
To: ha...@us...

This message was created automatically by mail delivery software (Exim).

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  tm4...@li...
    SMTP error from remote mailer after RCPT
 TO:<tm4...@li...>: host mail.sourceforge.net
 [66.35.250.206]: 550-Verification failed for <ha...@us...>
 550-Unrouteable address
    550 Sender verify failed

------ This is a copy of the message, including all the headers. ------

Return-path: <ha...@us...>
Received: from sc8-pr-cvs1-b.sourceforge.net ([10.5.1.7]
 helo=sc8-pr-cvs1.sourceforge.net) by sc8-sf-netmisc.sourceforge.net with
 esmtp (Exim 3.36 #1 (Debian)) id 1AIy3G-0002xN-00
	for <tm4...@li...>; Sun, 09 Nov 2003 14:28:58 -0800
Received: from localhost ([127.0.0.1] helo=sc8-pr-cvs1.sourceforge.net)
	by sc8-pr-cvs1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian))
	id 1AIy3G-0002tV-00
	for <tm4...@li...>; Sun, 09 Nov 2003 14:28:58 -0800
From: ha...@us...
To: tm4...@li...
Subject: tm4j/src/org/tm4j/topicmap
 TopicMapProviderFactoryConfigurationError.java,NONE,1.1
 TopicMapProviderFactory.java,1.7,1.8 Message-Id:
 <E1A...@sc...>
Date: Sun, 09 Nov 2003 14:28:58 -0800

Update of /cvsroot/tm4j/tm4j/src/org/tm4j/topicmap
In directory sc8-pr-cvs1:/tmp/cvs-serv10910/src/org/tm4j/topicmap

Modified Files:
	TopicMapProviderFactory.java
Added Files:
	TopicMapProviderFactoryConfigurationError.java
Log Message:
Refactored TopicMapProviderFactory.


--- NEW FILE: TopicMapProviderFactoryConfigurationError.java ---
package org.tm4j.topicmap;


/**
 * TODO: Insert class description
 *
 * @author fgh
 * @version $Revision: 1.1 $
 */
public class TopicMapProviderFactoryConfigurationError extends Error {
    /**
     *
     */
    public TopicMapProviderFactoryConfigurationError() {
        super();

        // TODO Auto-generated constructor stub
    }

    /**
     * @param message
     */
    public TopicMapProviderFactoryConfigurationError(String message) {
        super(message);

        // TODO Auto-generated constructor stub
    }

    /**
     * @param cause
     */
    public TopicMapProviderFactoryConfigurationError(Throwable cause) {
        super(cause);

        // TODO Auto-generated constructor stub
    }

    /**
     * @param message
     * @param cause
     */
    public TopicMapProviderFactoryConfigurationError(String message,
        Throwable cause) {
        super(message, cause);

        // TODO Auto-generated constructor stub
    }
}

Index: TopicMapProviderFactory.java
===================================================================
RCS file:
 /cvsroot/tm4j/tm4j/src/org/tm4j/topicmap/TopicMapProviderFactory.java,v
 retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** TopicMapProviderFactory.java	31 Aug 2003 15:08:39 -0000	1.7
--- TopicMapProviderFactory.java	9 Nov 2003 22:28:56 -0000	1.8
***************
*** 53,65 ****
  package org.tm4j.topicmap;

  import java.util.Properties;


  /**
!  * Interface to be supported by implementations which allow access
!  * to TopicMap objects using the TopicMapProvider interface.
!  * This interface enables an application to retrieve a TopicMapProvider
   */
! public interface TopicMapProviderFactory {
      /**
       * Creates and returns a TopicMapProvider object which may be used
--- 53,142 ----
  package org.tm4j.topicmap;

+ import java.io.BufferedReader;
+ import java.io.IOException;
+ import java.io.InputStream;
+ import java.io.InputStreamReader;
+
  import java.util.Properties;


  /**
!  * Abstract class to be extended by implementations which allow access
!  * to {@link TopicMap}s using the {@link TopicMapProvider} interface.
!  * This class enables an application to retrieve a
!  * {@link TopicMapProvider}.
!  * <p>TM4J applications retrieve
!  * instances of this class using the {@link #newInstance()} method, which
!  * selects, instantiates and returns the appropriate concrete
 implementation !  * as determined by the following algorithm (listed here in
 descending !  * order of precedence):</p>
!  * <ol>
!  * <li>Look for a system property named
!  * <code>org.tm4j.topicmap.TopicMapProviderFactory</code>; if found,
!  * it is expected to contain the fully-qualified class name of the
 concrete, !  * back end-dependent implementing class. If that system
 property is !  * found, but the corresponding class cannot be loaded or
!  * instantiated, this is considered an error condition and {@link
!  * #newInstance()} will throw a
!  * {@link TopicMapProviderFactoryConfigurationError}.</li>
!  * <li>Likewise, look for a system property named <code>provider</code>,
!  * handle it equivalently. This is purely for reasons of backwards
!  * compatibility and will go away in future releases.</li>
!  * <li>Find a resource on the Java classpath named
!  *
 <code>META-INF/services/org.tm4j.topicmap.TopicMapProviderFactory</code>; ! 
 * if found, it is expected to contain a single line of text denoting the ! 
 * fully-qualified class name of the concrete implementation class. !  * This
 in line with the "Service Provider" section
!  * of the
!  * <a
 href="http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#Service%20Provide
r">JAR !  * File Specification</a>. If that resource is
!  * found, but cannot be read, or the corresponding class cannot be loaded
 or !  * instantiated, this is considered an error condition and {@link
!  * #newInstance()} will throw a
!  * {@link TopicMapProviderFactoryConfigurationError}.</li>
!  * <li>If neither an appropriate system property nor the service
!  * provider configuration file could be found, instantiate and return
!  * the default implementation,
!  * {@link org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl
!  * org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl}.</li>
!  * </ol>
!  * <p>After the class has been properly instantiated,
!  * {@link TopicMapProvider}s may be created using
!  * {@link #newTopicMapProvider()} or {@link
 #newTopicMapProvider(Properties)}. !  * The implementing subclass will
 ensure that the returned
!  * {@link TopicMapProvider}s are appropriate for the underlying back-end
!  * implementation.</p>
!  * <p>This approach enables TM4J application developers to write
!  * their applications in a back end-independent manner, leaving it up
!  * to the users to select the appropriate back-end implementation
!  * that best fits their requirements.</p>
!  *
!  * @author <a href="mailto:kal...@us...">Kal Ahmed</a>
!  * @author <a href="mailto:ha...@us...">Florian G.
 Haas</a> */
! public abstract class TopicMapProviderFactory {
!     /** The default concrete implementation. */
!     private static final Class DEFAULT_IMPL =
 org.tm4j.topicmap.memory.TopicMapProviderFactoryImpl.class; !
!     /** The name of the system property expected to contain the
!      * fully-qualified implementing subclass name. */
!     private static final String SYSTEM_PROPERTY =
 TopicMapProviderFactory.class.getName(); !
!     /** The alternate name of the system property expected to contain the
!      * fully-qualified implementing subclass name.
!      * @deprecated retained for backwards compatibility only; for setting
!      * the factory class name, use the
!      * value specified by {@link #SYSTEM_PROPERTY} instead.  */
!     private static final String DEPRECATED_SYSTEM_PROPERTY = "provider";
!
!     /** The name of the service provider configuration file, relative to
!      * <code>/META-INF/services</code>. Same as {@link #SYSTEM_PROPERTY}.
 */ !     private static final String RESOURCE_NAME = SYSTEM_PROPERTY;
!
!     /** The default constructor is protected on purpose. New instances
!      * should be created using the {@link #newInstance()} method. */
!     protected TopicMapProviderFactory() {
!     }
!
      /**
       * Creates and returns a TopicMapProvider object which may be used
***************
*** 68,74 ****
--- 145,339 ----
       * @param props The configuration properties for the provider.
       * @return The new TopicMapProvider object
+      * @deprecated as of 0.8.4, this method only invokes
+      * {@link #newTopicMapProvider(Properties)}, by which it will be
 replaced +      * in the future.
       */
      public TopicMapProvider createTopicMapProvider(Properties props)
+         throws TopicMapProviderException {
+         return newTopicMapProvider(props);
+     }
+
+     /**
+      * Creates and returns a {@link TopicMapProvider} which may be used
+      * to retrieve one or more topic maps from the implementation's
+      * underlying store. The default implementation
+      * initializes the newly created {@link
+      * TopicMapProvider} with an empty set of configuration properties.
+      * @return The new TopicMapProvider object
+      * @since 0.8.4
+      */
+     public TopicMapProvider newTopicMapProvider()
+         throws TopicMapProviderException {
+         Properties props = new Properties();
+
+         return newTopicMapProvider(props);
+     }
+
+     /**
+      * Creates and returns a {@link TopicMapProvider} which may be used
+      * to retrieve one or more topic maps from the implementation's
+      * underlying store.
+      * @param props The configuration properties for the provider.
+      * @return The new TopicMapProvider object
+      * @since 0.8.4
+      */
+     public abstract TopicMapProvider newTopicMapProvider(Properties props)
          throws TopicMapProviderException;
+
+     /**
+      * Creates and returns a new instance of this class. The concrete
+      * implementation returned depends on the class selection algorithm
+      * as described above.
+      *
+      * @return a new instance of the appropriate concrete implementation
+      * of this base class.
+      * @throws TopicMapProviderFactoryConfigurationError if the new
 instance +      * could not be created. This may be due to the implementing
 subclass +      * not being found by the class loader, a failure in class
 instantiation, +      * or failure to read a service provider configuration
 file. The +      * original exception is passed to the
+      * {@link TopicMapProviderFactoryConfigurationError} as its root cause.
+      * @since 0.8.4
+      */
+     public static TopicMapProviderFactory newInstance() {
+         TopicMapProviderFactory instance = null;
+
+         try {
+             Class impl = getImplementingClass();
+             instance = (TopicMapProviderFactory) impl.newInstance();
+         } catch (Exception e) {
+             throw new
 TopicMapProviderFactoryConfigurationError("TopicMapProviderFactory
 instantiation failed.", +                 e);
+         }
+
+         return instance;
+     }
+
+     /**
+      * Returns the implementing concrete subclass.
+      *
+      * @return the {@link Class} describing the concrete implementing
+      * subclass.
+      * @throws ClassNotFoundException If the concrete subclass
+      * could be found by the class loader.
+      * @throws IOException if the class name was to be read from a
+      * service provider configuration file, but an I/O problem occurred
+      * while reading that file.
+      * @since 0.8.4
+      */
+     private static Class getImplementingClass()
+         throws ClassNotFoundException, IOException {
+         Class impl;
+         String className = getImplementationClassName();
+
+         if (className == null) {
+             impl = DEFAULT_IMPL;
+         } else {
+             impl = Class.forName(className);
+         }
+
+         return impl;
+     }
+
+     /**
+      * Returns the name of the implementing concrete subclass.
+      *
+      * @return the name of the concrete implementing subclass.
+      * @throws IOException if the class name was to be read from a
+      * service provider configuration file, but an I/O problem occurred
+      * while reading that file.
+      * @since 0.8.4
+      */
+     private static String getImplementationClassName()
+         throws IOException {
+         String className = readClassNameFromSystemProperty();
+
+         if (className == null) {
+             className = readClassNameFromResource();
+         }
+
+         return className;
+     }
+
+     /**
+      * Returns the name of the implementing concrete subclass, specified
+      * by a system property.
+      *
+      * @return the name of the concrete implementing subclass as read from
+      * a configuration property passed to the Java runtime, or
 <code>null</code> +      * if such a property was not found.
+      * @throws IOException if the class name was to be read from a
+      * service provider configuration file, but an I/O problem occurred
+      * while reading that file.
+      * @since 0.8.4
+      */
+     private static String readClassNameFromSystemProperty() {
+         // check the "correct" system property
+         String className = System.getProperty(SYSTEM_PROPERTY);
+
+         // for backward compatiblity only, check the
+         // deprecated system property as well
+         if (className == null) {
+             className = System.getProperty(DEPRECATED_SYSTEM_PROPERTY);
+         }
+
+         return className;
+     }
+
+     /**
+      * Returns the name of the implementing concrete subclass, specified
+      * by a service provider configuration file.
+      *
+      * @return the name of the concrete implementing subclass as read from
+      * a service provider configuration file, or <code>null</code>
+      * if such a file was not found.
+      * @throws IOException if an I/O problem occurred while reading
+      * the service provider configuration file.
+      * @since 0.8.4
+      */
+     private static String readClassNameFromResource() throws IOException {
+         // create the resource path
+         String resourcePath = "/META-INF/services/" + RESOURCE_NAME;
+
+         // get the class loader which this class was loaded from
+         ClassLoader cl = TopicMapProviderFactory.class.getClassLoader();
+
+         // access the resource (if not found, then in == null)
+         InputStream in = cl.getResourceAsStream(resourcePath);
+
+         String className = null;
+
+         // process the resource if it's available
+         if (in != null) {
+             BufferedReader reader = new BufferedReader(new
 InputStreamReader(in)); +
+             String line;
+
+             while (reader.ready()) {
+                 line = reader.readLine();
+
+                 if (line.trim().length() == 0) {
+                     // line is empty, ignore
+                 } else if (line.startsWith("#")) {
+                     // line is a comment, ignore
+                 } else {
+                     // we've found the correct line
+                     int startComment = line.indexOf('#');
+
+                     if (startComment == -1) {
+                         // line is not followed by a comment
+                         className = line.trim();
+                     } else {
+                         // line is followed by a comment, strip the comment
+                         className = line.substring(0, startComment).trim();
+                     }
+
+                     break;
+                 }
+             }
+         }
+
+         return className;
+     }
  }

***************
*** 76,79 ****
--- 341,347 ----
  /*
   * $Log$
+  * Revision 1.8  2003/11/09 22:28:56  haasfg
+  * Refactored TopicMapProviderFactory.
+  *
   * Revision 1.7  2003/08/31 15:08:39  kal_ahmed
   * Reformatted source code to Sun code style.

-------------------------------------------------------

-- 
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).