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

[Tm4j-developers] [ tm4j-Feature Requests-998615 ] Index of Variants

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

Feature Requests item #998615, was opened at 2004-07-27 11:22
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=998615&group_id=27895

Category: Programmer Utils
Group: Next Release (example)
>Status: Pending
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Index of Variants

Initial Comment:
Need to add indexes to retrieve variants by data / data
locator.

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

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-08-26 21:44

Message:
Logged In: YES 
user_id=176992

Added a proposal for this to CVS

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

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

[Tm4j-developers] [ tm4j-Bugs-1015061 ] Wrong example for ozone provider config

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

Bugs item #1015061, was opened at 2004-08-24 01:04
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=1015061&group_id=27895

Category: Documentation
Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong example for ozone provider config

Initial Comment:
kal,

in docs/devguide/ch03s05.html#config.ozone you write in
example 3.4 that the config property should be

dburl=ozone:remote://localhost:3333

according to what you write above and my experiences
here, this should be changed to 

ozonedb:remote://localhost:3333

note the "ozone_db_", or things go havoc. could be that
further down, the same applies to
dburl=ozone:local:/data/ozone/topicmaps ?

this prob showed up with the current tmnav, no other
experiences available (yet).

greets, tobi... :)

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

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

Re: [Tm4j-developers] Better handling of occurrence data

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

Hi Kal,

i did some more thinking and changed the prototype a bit. I now (hope to) have some more answers (suggestions) to your questions.
I think that we should do the conversion only on request as this means that we do not have to check the type of data inside the Occurrence. If a Format is requested, we try to convert it. Errors and everything else will then be reported by means of Exceptions. 
This solution does not increase the amount of processing done on reading a TopicMap and it also gives credit to the fact that most Occurrences will still hold data that is not of any of the supported formats. 
The parameter for getAdapter should be the desired class, however creation should be done by means of Factories. I implemented this by using a properties file where the DataFormats (Classnames) are Mapped to Factories (Classnames). It would be good if you (and everybody else who is intersted) could have a look at the prototype and give me some feedback.
I will check in the classes packed into a zip archive into the root folder of tm4j (so we can remove it later and it is still available to everybody interested). The file is called OccurrenceHandling.zip

Cheers,

Harald

____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200

[Tm4j-developers] [ tm4j-Bugs-1012130 ] ValuePredicate ignores Variants

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

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

Category: Tolog engine
Group: TM4J 0.9.6
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: ValuePredicate ignores Variants

Initial Comment:
Acc. to the tolog specification the value predicate
queries topicnames, occurrences and variants for the
given value. 
In tologx only topicnames and occurrences are queries
for the value. 

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

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-08-22 17:19

Message:
Logged In: YES 
user_id=176992

Requires implementation of VariantDataIndex (and
VariantLocatorIndex).

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

Comment By: Lars Heuer (lheuer)
Date: 2004-08-19 12:50

Message:
Logged In: YES 
user_id=399396

Additional comment: Problem is the "matchObject" method, all
other methods work, IMO. 


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

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

FWD: Re: [Tm4j-developers] Better handling of occurrence data

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

Hi Kal,

I send this mail again because the smtp server of my free webmail service seems to be blocked by some spam blocker on sf.
Hope it works this time.


> Hi Harald,
>
> Thanks for the proposal. I have a few questions:
>
> 1) Do you think that we should continue to store the occurrence values
> as strings and only do the conversion on a get ? What about doing a
> conversion on a set ?

Yes, i think we should store the  occurrence values as strings because i think that tm4j should not check which format an occurence has (that is something for a schema or data type definition) but rather try to deliver a Format, the user request, return null if the data is not supported and an raise an Exception if the data does not comply to the Requested Format (this behavier is, in my opinion the way the Gang Of Four Pattern Adapter is meant to work - please correct me if i am wrong).

> 2) Is the Class parameter of the getAdapter method the class of the
> format you want (e.g. getAdapter(java.util.Date.class)) or is it the
> class of an adapter that does the conversion (e.g.
> getAdapter(org.tm4j.utils.DateAdapter)) - I guess from the way that you
> talk about using the occurrence type's base name for the formatting
> string, that you have an adapter class that you pass in as a parameter,
> right ?


It should be the the class of the format you want (yes, like getAdapter(java.util.Date.class)). We could think about using adapter classes but i just tried it with a getAdapter implementation witch is responsible for the generation of the adopted Format. Using the Basename of the type is just a way to make these time data interoperable (and the implementation is reduced to 3 or 4 lines of code).

> Finally there is discussion in the ISO working group about how to
> support data types in occurrences which will also have an influence on
> how TM4J behaves in the future - there are those who would like some
> base set of data types to be allowed for occurrences and those who would
> prefer just to allow any XML as occurrence data and then if you want
> data typing you use XML elements that have an associated schema that
> defines the data type. However, there is not a clear decision on that
> yet (AFAIK - I missed the last ISO WG meeting), so perhaps we can go
> with a solution like you propose for now and worry about what ISO come
> up with later.

I think that this is a good idea. As far as I know, ISO is not the fastest organisation concerning the decising about new standards.

Cheers,

Harald


________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: [Tm4j-developers] Better handling of occurrence data

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

Am Do, den 19.08.2004 schrieb Harald Kuhn um 19:17:

> further DataFormats that might be interesting are:
> some class that understands Wiki Formatting instructions
> some class that understands spatial data 
> (Christoph, is there a STandart API or something like that ?)
> 
I'm not aware of any. But that does not have to mean anything, since I
just started to explore that field.

Sorry
c

> I experimented with the java.util.Date class and together with an Occurence type which specifies the time format by a Basename following the formatting syntax (e.g. dd.mm.yyyy) we get a way to create time aware TopicMaps.
> 
> I also think that the impact on the API would be relatively small.
> 
> Cheers,
> 
> Harald
> 
> ____________________________________________________
> Aufnehmen, abschicken, nah sein - So einfach ist 
> WEB.DE Video-Mail: http://freemail.web.de/?mc=021200
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Christoph Froehlich <cf...@fo...>

Re: [Tm4j-developers] Better handling of occurrence data

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

Hi Harald,

Thanks for the proposal. I have a few questions:

1) Do you think that we should continue to store the occurrence values
as strings and only do the conversion on a get ? What about doing a
conversion on a set ?

2) Is the Class parameter of the getAdapter method the class of the
format you want (e.g. getAdapter(java.util.Date.class)) or is it the
class of an adapter that does the conversion (e.g.
getAdapter(org.tm4j.utils.DateAdapter)) - I guess from the way that you
talk about using the occurrence type's base name for the formatting
string, that you have an adapter class that you pass in as a parameter,
right ?

Finally there is discussion in the ISO working group about how to
support data types in occurrences which will also have an influence on
how TM4J behaves in the future - there are those who would like some
base set of data types to be allowed for occurrences and those who would
prefer just to allow any XML as occurrence data and then if you want
data typing you use XML elements that have an associated schema that
defines the data type. However, there is not a clear decision on that
yet (AFAIK - I missed the last ISO WG meeting), so perhaps we can go
with a solution like you propose for now and worry about what ISO come
up with later.

Cheers,

Kal

On Thu, 2004-08-19 at 18:17, Harald Kuhn wrote:
> Hi All,
> 
> I thought about how to implement a better handling of data inside occurrences. This approach should also bring a better support for later adding support for xml inside occurrence data.
> 
> I suggest to add an Interface named OccurrenceData (or OccurrenceContent, i am not quite sure which is the better name)  which encasulates the Data of an Occurrence. The Occurrence Interface would have to be extended with the methods getOccurrenceData(...) and setOccurrenceData(..) (or getOccurrenceContent and setOccurrenceContent). The Methods getData() and setData() should be kept for compatibility reasons. The OccurrenceData (or OccurrenceContent) would have the following methods:
> 
> String getData / void setData(String)  have the same behavier like getData/setData of Occurrence
> StringReader getStringReader() returns a StringReader containing the data
> Object getAdapter(Class clazz)
> 
> Following the Adapter Pattern would make the support of other Data Formats easier to implement. It would also prevent the interface from getting to complex blown up.
> 
> The basic implementation should support the creation of the following Instances throug its getAdapter Method:
> 
> java.util.Date (for Temporal Data)
> org.xml.sax.InputSource (for XML Data)
> javax.xml.transform.Source (returning a javax.xml.transform.stream.StreamSource)  (for XML Data)
> 
> further DataFormats that might be interesting are:
> some class that understands Wiki Formatting instructions
> some class that understands spatial data 
> (Christoph, is there a STandart API or something like that ?)
> 
> I experimented with the java.util.Date class and together with an Occurence type which specifies the time format by a Basename following the formatting syntax (e.g. dd.mm.yyyy) we get a way to create time aware TopicMaps.
> 
> I also think that the impact on the API would be relatively small.
> 
> Cheers,
> 
> Harald
> 
> ____________________________________________________
> Aufnehmen, abschicken, nah sein - So einfach ist 
> WEB.DE Video-Mail: http://freemail.web.de/?mc=021200
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] Better handling of occurrence data

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

Hi All,

I thought about how to implement a better handling of data inside occurrences. This approach should also bring a better support for later adding support for xml inside occurrence data.

I suggest to add an Interface named OccurrenceData (or OccurrenceContent, i am not quite sure which is the better name)  which encasulates the Data of an Occurrence. The Occurrence Interface would have to be extended with the methods getOccurrenceData(...) and setOccurrenceData(..) (or getOccurrenceContent and setOccurrenceContent). The Methods getData() and setData() should be kept for compatibility reasons. The OccurrenceData (or OccurrenceContent) would have the following methods:

String getData / void setData(String)  have the same behavier like getData/setData of Occurrence
StringReader getStringReader() returns a StringReader containing the data
Object getAdapter(Class clazz)

Following the Adapter Pattern would make the support of other Data Formats easier to implement. It would also prevent the interface from getting to complex blown up.

The basic implementation should support the creation of the following Instances throug its getAdapter Method:

java.util.Date (for Temporal Data)
org.xml.sax.InputSource (for XML Data)
javax.xml.transform.Source (returning a javax.xml.transform.stream.StreamSource)  (for XML Data)

further DataFormats that might be interesting are:
some class that understands Wiki Formatting instructions
some class that understands spatial data 
(Christoph, is there a STandart API or something like that ?)

I experimented with the java.util.Date class and together with an Occurence type which specifies the time format by a Basename following the formatting syntax (e.g. dd.mm.yyyy) we get a way to create time aware TopicMaps.

I also think that the impact on the API would be relatively small.

Cheers,

Harald

____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200

[Tm4j-developers] [ tm4j-Bugs-1012130 ] ValuePredicate ignores Variants

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

Bugs item #1012130, was opened at 2004-08-19 13:47
Message generated for change (Comment added) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1012130&group_id=27895

Category: Tolog engine
Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: ValuePredicate ignores Variants

Initial Comment:
Acc. to the tolog specification the value predicate
queries topicnames, occurrences and variants for the
given value. 
In tologx only topicnames and occurrences are queries
for the value. 

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

>Comment By: Lars Heuer (lheuer)
Date: 2004-08-19 13:50

Message:
Logged In: YES 
user_id=399396

Additional comment: Problem is the "matchObject" method, all
other methods work, IMO. 


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

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

[Tm4j-developers] [ tm4j-Bugs-1012130 ] ValuePredicate ignores Variants

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

Bugs item #1012130, was opened at 2004-08-19 13:47
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=1012130&group_id=27895

Category: Tolog engine
Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: ValuePredicate ignores Variants

Initial Comment:
Acc. to the tolog specification the value predicate
queries topicnames, occurrences and variants for the
given value. 
In tologx only topicnames and occurrences are queries
for the value. 

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

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

[Tm4j-developers] Re: Inter Map Reification

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

Hi Harald,

I saw the extractors that you have written and I think that it is a good
start, but I think that there is a case for adding methods to the API to
get the reifing topic of an object (and to get the object reified by a
topic). I think that methods are better than indexes in this case,
because there can only ever be a one-to-one relationship. These methods
could be implemented by simply making use of the existing methods of the
TopicMap interface so it shouldn't be a big deal to do it. I'll look
into adding these for the next release.

Cheers,

Kal
On Wed, 2004-08-18 at 16:57, Harald Kuhn wrote:
> Hi Kal,
> 
> as the topic of how to handle reification of TopicMapObjects was mentioned on the mailinglist recently and i also had problems with this some time ago in one of my projects, i wrote two Extractors for Finding Reified Objects and Reifying Topics (RefiedObjectExtractor and ReifyingTopicExtractor). I also wrote an experimental index for the in Memory Backend which caches these information for a faster access. I am not quite sure which way would be the best. 
> 
> The question is wether extractors are the right point to add support for this. As i pointed out, it would also be possible to use and Index. I could also imagine adding methods to TopicMapObject and Topic (this would have by far the biggest impact on the API). What do you think ?
> 
> As the Extractors have far less impact on the API, I added them to cvs (...utils.extractors). If anybody is interested in the code of the Index Prototype, just send me an email. 
> 
> Cheers,
> Harald
> ________________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] Inter Map Reification

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

Hi Kal,

as the topic of how to handle reification of TopicMapObjects was mentioned on the mailinglist recently and i also had problems with this some time ago in one of my projects, i wrote two Extractors for Finding Reified Objects and Reifying Topics (RefiedObjectExtractor and ReifyingTopicExtractor). I also wrote an experimental index for the in Memory Backend which caches these information for a faster access. I am not quite sure which way would be the best. 

The question is wether extractors are the right point to add support for this. As i pointed out, it would also be possible to use and Index. I could also imagine adding methods to TopicMapObject and Topic (this would have by far the biggest impact on the API). What do you think ?

As the Extractors have far less impact on the API, I added them to cvs (...utils.extractors). If anybody is interested in the code of the Index Prototype, just send me an email. 

Cheers,
Harald
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: [Tm4j-developers] database deadlocks

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

Hi Pete,

Did you make these changes to the schema generated by Hibernate or did
you change the Hibernate mapping files ? If you did the latter, would it
be possible to get a copy of your changes ? If you had to hack the
schema generated by Hibernate then I'm a little less clear on the best
way to proceed - on the one hand this is an issue we should try to
address, but on the other hand I don't want to have to create and
maintain a set of schemas for different databases (that was one of the
reasons for using Hibernate in the first place!) - perhaps it could be
reported as an issue to the Hibernate folks though ?

Cheers,

Kal

On Fri, 2004-08-06 at 10:35, Pete Lewin-Harris wrote:
> I'm getting a problem with deadlocks being reported by the database when I
> load test tm4j using multiple threads adding, editing and deleting topics on
> multiple topic maps. I'm running with the hibernate backend and a postgres
> database.
> 
> I've googled this problem and it seems that it is a known postgres
> 'feature'. The point is that before updating a row the database locks for
> update all foreign keys for that row. This can cause problems if there are
> many foreign keys on a table (such as tmobjects in tm4j) due to different
> threads trying to lock the same table rows in different orders (i.e. an add
> locks rows in a different order to an edit) and so deadlocks can appear.
> 
> The soultion to this seems to be changing the schema to reduce the
> likelyhood of deadlocks. I have managed to reduce the frequency of this
> problem by reordering the foreign keys and removing the foriegn key from the
> topicMap column on tmobjects to topicmaps but this is a fairly temporary
> bodge.
> 
> cheers, Pete
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] [ tm4j-Bugs-990285 ] TMBrowse does not report error detail

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

Bugs item #990285, was opened at 2004-07-13 17:45
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=990285&group_id=27895

Category: TM4Web
Group: CVS
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: TMBrowse does not report error detail

Initial Comment:
The error page displayed by TMBrowse currently shows no
error details and contains references to undefined
localisation strings.

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

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-08-17 16:30

Message:
Logged In: YES 
user_id=176992

Fixed in CVS.

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

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

[Tm4j-developers] [ tm4j-Feature Requests-990284 ] Add a link/button to refresh topic map list

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

Feature Requests item #990284, was opened at 2004-07-13 17:43
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=990284&group_id=27895

Category: tm4web/velocity
Group: Next Release (example)
>Status: Closed
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Add a link/button to refresh topic map list

Initial Comment:
Refresh should update any directories listed for
in-memory backends as well as the list of topic maps
available from persistent stores.

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

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-07-14 17:33

Message:
Logged In: YES 
user_id=176992

Fixed for next release.

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

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

[Tm4j-developers] [ tm4j-Bugs-881422 ] TM4Web: display of special chars broken in main display

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

Bugs item #881422, was opened at 2004-01-21 14:56
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=881422&group_id=27895

Category: TM4Web
Group: TM4Web/Velocity 0.1
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: TM4Web: display of special chars broken in main display

Initial Comment:
hi, 
 
i am very impressed by the recent status of TMNav and 
TM4Web. thank you! 
 
here is a minor problem: 
TM4Web's display method for all topics on the main 
page seems broken (display works in topic.vm) 
 
in addition, TMNav displays topics only fine when (4) 
is used (äöü...). 
 
this behaviour does not seem to depend on using LTM 
char encoding headers 
(none = default, @"utf-8" or @"ISO-8859-1"). 
 
used versions: 
- tmnav-0.2.7a1-bin (alpha) 
- tm4web-velocity-bin-0.1-nodeps.zip 
 
my example topic: 
[Umlaute = "Umlaute_ä_œ_ 
Œ_Œ_&#339_äöüß_ÄÖÜ"] 
i.e.: 
(1) &auml 
(2) œ_ &#140 (oe/OE lig) 
(3) Œ_&#339 (same) 
(4) äöüß_ÄÖÜ 
 
results: 
-------- 
TMNav: 
(4) ok 
 
TM4Web: 
  Main page with all topics: none working 
    (4) looks like UTF-8 viewed in ISO-8859-1 
  topic.vm: (1), (2), (3) ok 
 
alex 
-- 
Alexander Sigel, M.A. 
U Cologne, Dept. for Information Systems & 
Information Management 
si...@wi... http://wim.uni-koeln.de/ phone 
+49 221 470-5322 
Pohligstr. 1, Room 406, 50969 Köln, GERMANY 
--- 
 

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

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-08-17 16:32

Message:
Logged In: YES 
user_id=176992

Works OK with pages now generated as UTF-8 and carrying
correct HTTP header (this may be dependent on the version of
Tomcat too).

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

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-01-26 16:15

Message:
Logged In: YES 
user_id=176992

All pages generated by TM4Web/Velocity should be UTF-8 encoded.

I think this might be a Tomcat problem that you are seeing.
You don't say which servlet container you are using, but
Tomcat 4.1.29 does not set the HTTP headers specifying
content encoding properly. I have found that everything is
fine with Tomcat 4.1.27. Can you check this out and let me
know if the problem is still there with the older version of
Tomcat ?

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

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

[Tm4j-developers] [ tm4j-Bugs-1008801 ] Binary distro should contain a build.xml file

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

Bugs item #1008801, was opened at 2004-08-13 17:30
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1008801&group_id=27895

Category: Distribution Files
Group: CVS
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Binary distro should contain a build.xml file

Initial Comment:
The binary distribution should contain a build.xml file
with the targets related to installing and running the
ozone backend (e.g. ozone-install, ozone-run). This
build file could also contain targets to run tests...

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

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

[Tm4j-developers] [ tm4j-Bugs-1010670 ] SubjectIdentPred should be renamed to SubjectLocPred

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

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

Category: Tolog engine
Group: TM4J 0.9.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: SubjectIdentPred should be renamed to SubjectLocPred

Initial Comment:
The "SubjectLocatorPredicate" object models the
"SubjectIdenfierPredicate" and vice versa. 

Just rename the "SubjectLocatorPredicate" into
"SubjectIdentifierPredicate" and the
"SubjectIdentifierPredicate" into "SubjectLocatorPredicate"

It's not critical at all, because both objects have the
correct PREDICATE_NAME property.

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

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-08-17 16:01

Message:
Logged In: YES 
user_id=176992

Fixed in CVS.

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

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

[Tm4j-developers] [ tm4j-Bugs-1010670 ] SubjectIdentPred should be renamed to SubjectLocPred

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

Bugs item #1010670, was opened at 2004-08-17 13:51
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=1010670&group_id=27895

Category: Tolog engine
Group: TM4J 0.9.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: SubjectIdentPred should be renamed to SubjectLocPred

Initial Comment:
The "SubjectLocatorPredicate" object models the
"SubjectIdenfierPredicate" and vice versa. 

Just rename the "SubjectLocatorPredicate" into
"SubjectIdentifierPredicate" and the
"SubjectIdentifierPredicate" into "SubjectLocatorPredicate"

It's not critical at all, because both objects have the
correct PREDICATE_NAME property.

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

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

[Tm4j-developers] [ tm4j-Bugs-1008801 ] Binary distro should contain a build.xml file

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

Bugs item #1008801, was opened at 2004-08-13 17:30
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=1008801&group_id=27895

Category: Distribution Files
Group: CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Binary distro should contain a build.xml file

Initial Comment:
The binary distribution should contain a build.xml file
with the targets related to installing and running the
ozone backend (e.g. ozone-install, ozone-run). This
build file could also contain targets to run tests...

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

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

[Tm4j-developers] database deadlocks

[Pete Lewin-H. <pe...@il...>]

I'm getting a problem with deadlocks being reported by the database when I
load test tm4j using multiple threads adding, editing and deleting topics on
multiple topic maps. I'm running with the hibernate backend and a postgres
database.

I've googled this problem and it seems that it is a known postgres
'feature'. The point is that before updating a row the database locks for
update all foreign keys for that row. This can cause problems if there are
many foreign keys on a table (such as tmobjects in tm4j) due to different
threads trying to lock the same table rows in different orders (i.e. an add
locks rows in a different order to an edit) and so deadlocks can appear.

The soultion to this seems to be changing the schema to reduce the
likelyhood of deadlocks. I have managed to reduce the frequency of this
problem by reordering the foreign keys and removing the foriegn key from the
topicMap column on tmobjects to topicmaps but this is a fairly temporary
bodge.

cheers, Pete

[Tm4j-developers] [ tm4j-Feature Requests-998615 ] Index of Variants

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

Feature Requests item #998615, was opened at 2004-07-27 11:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=998615&group_id=27895

Category: Programmer Utils
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Index of Variants

Initial Comment:
Need to add indexes to retrieve variants by data / data
locator.

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

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

[Tm4j-developers] [ tm4j-Feature Requests-998614 ] Index of DataObjects

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

Feature Requests item #998614, was opened at 2004-07-27 11:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=998614&group_id=27895

Category: None
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Index of DataObjects

Initial Comment:
Add an index of DataObjects that allows easy access to
all DataObject instances in a topic map.

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

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

[Tm4j-developers] [ tm4j-Feature Requests-998613 ] Allow user-provided connections for Hibernate backend

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

Feature Requests item #998613, was opened at 2004-07-27 11:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=998613&group_id=27895

Category: None
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Allow user-provided connections for Hibernate backend

Initial Comment:
From Andy:

What would be useful, as I've mentioned before, is a
mechanism to allow developers to provide an existing
transaction for TM4J to use, and by implication, a
mechanism to share a given Hibernate instance. This
would also make integration with enterprise software
less tricky.

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

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

[Tm4j-developers] Its going to be quiet...

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

Hi all,

Just to let you all know I'm going to be on holiday (with no computer!)
for a couple of weeks starting from tomorrow, so its going to be very
quiet from this end...

Cheers,

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