Menu
▾
▴
tm4j-developers — Forum for issues related to development of TM4J.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(26) |
Jul
(22) |
Aug
(31) |
Sep
(25) |
Oct
(9) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(50) |
Feb
(51) |
Mar
(6) |
Apr
(10) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(11) |
| 2003 |
Jan
(8) |
Feb
(21) |
Mar
(2) |
Apr
(29) |
May
(9) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(3) |
Oct
(21) |
Nov
(40) |
Dec
(14) |
| 2004 |
Jan
(32) |
Feb
(30) |
Mar
(24) |
Apr
(13) |
May
(25) |
Jun
(14) |
Jul
(9) |
Aug
(21) |
Sep
(52) |
Oct
(9) |
Nov
(12) |
Dec
(6) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(14) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
(16) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(9) |
Dec
(2) |
| 2007 |
Jan
(2) |
Feb
(9) |
Mar
(1) |
Apr
(38) |
May
(7) |
Jun
(7) |
Jul
(12) |
Aug
(10) |
Sep
(10) |
Oct
(3) |
Nov
(7) |
Dec
(7) |
| 2008 |
Jan
(13) |
Feb
(12) |
Mar
(53) |
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Conal T. <con...@vu...> - 2008-03-10 05:55:28
|
I have an old topicmap provider implementation which no longer links
against recent builds of TM4j because of the addition of the equalsByID
method to the TopicMapObject interface.
It is certainly an easy method to implement, but I'm concerned because I
don't even understand why the method has been added to TopicMapObject.
It appears it may have been a "rough idea" that never really developed?
In any case, it seems like a needless complication to me, and I am
inclined to remove it. First I thought I would ask about it here.
The point of the method appears to be to hide the data type of the
object's id, presumably so that it could potentially be something other
than a String. But this seems pointless to me, since actually these id
properties are constrained to be strings (actually, XML names) by the
XML Topic Maps specification. There's no way they could be anything
other than strings!
When I looked at each provider's implementation of the TopicMapObject
interface in the TM4j source tree, they were all exactly the same:
public boolean equalsByID(TopicMapObject o) {
return getID().equals(o.getID());
}
That fact in itself is a good indicator that the method doesn't properly
belong in the TopicMapProvider interface. If there is no need for
different providers to implement the method differently (and indeed the
JavaDoc for the interface actually specifies the implementation!), then
it belongs in a helper class, or as a protected helper method, but not
as a public API.
Each of the tm4j topic map providers had an implementation of
TopicMapObject which included this method. These methods were used in at
most a few places within that provider's package (e.g.
org.tm4j.topicmap.hibernate.TopicImpl calls the method as a helper
within isOfType(Topic)). In all of those cases the method could just as
well have been protected - it didn't need to be part of the public API.
Even if it were just a protected method of TopicMapObjectImpl (and not
required by the TopicMapObject interface) it would seem hardly
justifiable because it is just a single line of code, and used only a
few times (not used at all in the unified provider!).
Incidentally, I'm not sure if the implementation in the "unified"
provider is correct - it's subtly inconsistent with equals().
The only use I could see of the method outside of provider classes was
in org.tm4j.topicmap.utils.TopicMapWalker, where it was used just once,
and could I think have just as well used equals() or at least
getID().equals(o.getID())
So I propose to remove the equalsByID method from the interface, and
replace its use in TopicMapWalker with equivalent code comparing id
values.
Any objections?
Con
--
Conal Tuohy
New Zealand Electronic Text Centre
www.nzetc.org
--
Conal Tuohy
New Zealand Electronic Text Centre
www.nzetc.org
|
|
From: Conal T. <con...@vu...> - 2008-03-10 05:51:20
|
Sorry to respond to this late, Xuân. On Sun, 2008-01-27 at 04:33 +1300, Xuân Baldauf wrote: > Hi Kal, > > I have submitted a larger chunk of changes to TM4J in anticipation of > a TM4J2 (with a compatibility layer to TM4J 0.9.x), but there is still > a lot to do (and the changes are incomplete so far). Remember to consult with the developer and user lists, though, before you make any changes to the public API (e.g. to org.tm4j.topicmap interfaces). These interfaces are the most abstract parts of the system and stability (and minimality) is important. > However, the development environment itself has become somewhat > anachronistic and I'd like to introduce some changes to the > environment: > * Change from CVS to Mercurial: Mercurial allows for a much > smoother and more network-independent (read: faster) > development of changes than CVS. The repository is still to be > hosted on sourceforge, in a manner like > http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge . Is it possible to use Mercurial via HTTPS? The page you cited seems to imply not. I know CVS is old and doggy, but we are all familiar with it which is itself a big help. If we were to change, I would prefer Subversion, because I have used it every day for years and I know it pretty well. I also very much like Subversion's reliance on HTTP and WebDAV, which makes it easy to use behind web proxies, and with web tools in general. Are you familiar with Subversion? By contrast I'ave never used Mercurial (or even heard of it until now) and I would really prefer not to have to learn a new revision control system. What do the other developers think? > * Change from Ant to Maven2: In the Java world, Maven2 is > gaining quite momentum. There are more than 600 projects > listed on http://repo1.maven.org/maven2/ which are known be > some form of a maven2 project. Maven has the advantage that > all dependencies (and its transitive dependencies) for a > project to compile and run are not needed to be copied into > the project. Rather than that, dependencies are are just > specified and, at the first build time, downloaded on demand. > One major advantage is the relief of the burden to maintain a > coherent set of dependencies (and its transitive > dependencies), and a very simple way to change dependencies. > (Example: I upgraded the CVS copy of ant recently by a version > which is 4 years newer, which created a lot of noise in the > logs.) Another advantage is that TM4J being a Maven2 project > makes itself very easily usable by other Java projects > (especially those which use Maven2), without a hassle to > configure classpaths and such. A further advantage is that > TM4J may optionally depend on GPL code (like DB4O for a > persistent backend), which is not possible when including GPL > software in the repository directly. I think this is an interesting suggestion ... there are quite a few build files which would need rewriting, but it could certainly be done. What sort of changes would be required to the overall organisation of the source, do you think? -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
|
From: Conal T. <con...@vu...> - 2008-03-10 05:23:43
|
I have an old topicmap provider implementation which no longer links
against recent builds of TM4j because of the addition of the equalsByID
method to the TopicMapObject interface.
It is certainly an easy method to implement, but I'm concerned because I
don't even understand why the method has been added to TopicMapObject.
It appears it may have been a "rough idea" that never really developed?
In any case, it seems like a needless complication to me, and I am
inclined to remove it. First I thought I would ask about it here.
The point of the method appears to be to hide the data type of the
object's id, presumably so that it could potentially be something other
than a String. But this seems pointless to me, since actually these id
properties are constrained to be strings (actually, XML names) by the
XML Topic Maps specification. There's no way they could be anything
other than strings!
When I looked at each provider's implementation of the TopicMapObject
interface in the TM4j source tree, they were all exactly the same:
public boolean equalsByID(TopicMapObject o) {
return getID().equals(o.getID());
}
That fact in itself is a good indicator that the method doesn't properly
belong in the TopicMapProvider interface. If there is no need for
different providers to implement the method differently (and indeed the
JavaDoc for the interface actually specifies the implementation!), then
it belongs in a helper class, or as a protected helper method, but not
as a public API.
Each of the tm4j topic map providers had an implementation of
TopicMapObject which included this method. These methods were used in at
most a few places within that provider's package (e.g.
org.tm4j.topicmap.hibernate.TopicImpl calls the method as a helper
within isOfType(Topic)). In all of those cases the method could just as
well have been protected - it didn't need to be part of the public API.
Even if it were just a protected method of TopicMapObjectImpl (and not
required by the TopicMapObject interface) it would seem hardly
justifiable because it is just a single line of code, and used only a
few times (not used at all in the unified provider!).
Incidentally, I'm not sure if the implementation in the "unified"
provider is correct - it's subtly inconsistent with equals().
The only use I could see of the method outside of provider classes was
in org.tm4j.topicmap.utils.TopicMapWalker, where it was used just once,
and could I think have just as well used equals() or at least
getID().equals(o.getID())
So I propose to remove the equalsByID method from the interface, and
replace its use in TopicMapWalker with equivalent code comparing id
values.
Any objections?
Con
--
Conal Tuohy
New Zealand Electronic Text Centre
www.nzetc.org
|
|
From: Conal T. <con...@vu...> - 2008-01-28 22:41:23
|
On Mon, 2008-01-28 at 15:21 +0100, Lars Marius Garshol wrote: > * Kal Ahmed > > > > Finally on Locators, the logic behind the Locator structure in the =20 > > original TM4J was that it should be possible to support a wider =20 > > range of locator syntaxes than URI/URL syntax. In practice, URIs (or =20 > > maybe IRIs) have won and the Locator class is probably something of =20 > > an anachronism =E2=80=93 a simple Unicode character sequence (backed up= with =20 > > the library functions for parsing and handling those strings as =20 > > URIs) should work for a =E2=80=9Cnew=E2=80=9D topic map engine. >=20 > A word of caution here: URI processing is quite complex, and in Topic =20 > Maps import it's also performance-critical. Small changes to how URIs =20 > are processed can mean a huge difference in the time needed to load an =20 > XTM file. This may sound strange until you stop to consider just how =20 > many URIs there are in an XTM file. >=20 > The built-in Java classes for URIs have quite a few issues in this =20 > regard, and so you may want to consider keeping some sort of interface =20 > in front here in order to give yourself latitude to make this efficient. Personally I've never used Locators of any other type than URI, since I've been using XTM for input, but I agree with Lars that the API needs a "Locator" abstraction. I don't think there's anything in the Locator interface which imposes a heavy memory footprint is there? --=20 Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
|
From: Lars M. G. <la...@ga...> - 2008-01-28 14:21:04
|
* Kal Ahmed > > Finally on Locators, the logic behind the Locator structure in the =20 > original TM4J was that it should be possible to support a wider =20 > range of locator syntaxes than URI/URL syntax. In practice, URIs (or =20= > maybe IRIs) have won and the Locator class is probably something of =20= > an anachronism =96 a simple Unicode character sequence (backed up with = =20 > the library functions for parsing and handling those strings as =20 > URIs) should work for a =93new=94 topic map engine. A word of caution here: URI processing is quite complex, and in Topic =20= Maps import it's also performance-critical. Small changes to how URIs =20= are processed can mean a huge difference in the time needed to load an =20= XTM file. This may sound strange until you stop to consider just how =20 many URIs there are in an XTM file. The built-in Java classes for URIs have quite a few issues in this =20 regard, and so you may want to consider keeping some sort of interface =20= in front here in order to give yourself latitude to make this efficient. --Lars M.= |
|
From: Kal A. <ka...@ne...> - 2008-01-28 08:49:47
|
Hi Xu=E2n, =20 Right now, Conal Tuohy and Ichiro Furusato are the main development = leads for TM4J since I took a back seat to concentrate on Networked = Planet work. So I will defer to them in questions of the development = environment. My concern with Mercurial would be about the level at which = it is supported by the SourceForge team. While it is nice to have the = latest shiny toys to play with, it is also nice to have a system that = someone else looks after ;-) =20 With regards to generating topic map engines and the such like - domain = specific languages certainly hold out a lot of hope for generating the = basic structure, but I would imagine that the logic (e.g. the logic of = merging) would still have to be hand coded, so I don't know how much of = a real saving they would provide. We (NetworkedPlanet) used MS's DSL = tools to generate a topic map ontology editor and that worked quite = nicely but even that relatively simple domain-specific language required = a fair amount of hand-written code to work properly. =20 Finally on Locators, the logic behind the Locator structure in the = original TM4J was that it should be possible to support a wider range of = locator syntaxes than URI/URL syntax. In practice, URIs (or maybe IRIs) = have won and the Locator class is probably something of an anachronism - = a simple Unicode character sequence (backed up with the library = functions for parsing and handling those strings as URIs) should work = for a "new" topic map engine. =20 Cheers =20 Kal =20 From: Xu=E2n Baldauf = [mailto:xuan--2008.01.27--tm4j-developers--lists.sourceforge.net@baldauf.= org]=20 Sent: 26 January 2008 15:33 To: Kal Ahmed Cc: tm4...@li... Subject: Improving development environment for TM4J =20 Hi Kal, I have submitted a larger chunk of changes to TM4J in anticipation of a = TM4J2 (with a compatibility layer to TM4J 0.9.x), but there is still a = lot to do (and the changes are incomplete so far). However, the = development environment itself has become somewhat anachronistic and I'd = like to introduce some changes to the environment: * Change from CVS to Mercurial: Mercurial allows for a much smoother and = more network-independent (read: faster) development of changes than CVS. = The repository is still to be hosted on sourceforge, in a manner like = http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge . * Change from Ant to Maven2: In the Java world, Maven2 is gaining quite = momentum. There are more than 600 projects listed on = http://repo1.maven.org/maven2/ which are known be some form of a maven2 = project. Maven has the advantage that all dependencies (and its = transitive dependencies) for a project to compile and run are not needed = to be copied into the project. Rather than that, dependencies are are = just specified and, at the first build time, downloaded on demand. One = major advantage is the relief of the burden to maintain a coherent set = of dependencies (and its transitive dependencies), and a very simple way = to change dependencies. (Example: I upgraded the CVS copy of ant = recently by a version which is 4 years newer, which created a lot of = noise in the logs.) Another advantage is that TM4J being a Maven2 = project makes itself very easily usable by other Java projects = (especially those which use Maven2), without a hassle to configure = classpaths and such. A further advantage is that TM4J may optionally = depend on GPL code (like DB4O for a persistent backend), which is not = possible when including GPL software in the repository directly. It would be nice if you could give your comments or you "amen" (or = "ramen" if you believe in FSM) to these changes within the next days or = weeks and if anybody else could comment on it. ciao, Xu=E2n. P.S.: Who is the "operational" project admin of TM4J (is there any?). It = looks like the developer of the Ruby Topic Maps engine ( = http://rtm.rubyforge.org/ ) is going to need commit rights at some = future point in time, and it would be nice to know who to ask. We are = currently planning a bridge between Ruby and Java such that RTM may be = able to use TM4J as a backend. Furthermore, we are currently playing = around with automatic generation of Java topicmap engines using Ruby = domain specific languages (thus vastly improving development speed, as = many codings once done for one TopicMapConstruct have to be repeated = very similarily for all the other TopicMapConstructs). It also possible = to generate topic map engines with different properties (e.g. engines = where locators are represented internally not as Locator objects, but as = plain UTF-16 sequences or as plain UTF-8 sequences, improving memory = usage, or engines where different ways of indexing are used). At some = point of time, it may be good for TM4J engines to be generatable in this = way. |
|
From:
<xua...@ba...> - 2008-01-26 15:35:21
|
Hi Kal,
I have submitted a larger chunk of changes to TM4J in anticipation of a
TM4J2 (with a compatibility layer to TM4J 0.9.x), but there is still a
lot to do (and the changes are incomplete so far). However, the
development environment itself has become somewhat anachronistic and I'd
like to introduce some changes to the environment:
* Change from CVS to Mercurial: Mercurial allows for a much smoother
and more network-independent (read: faster) development of changes
than CVS. The repository is still to be hosted on sourceforge, in
a manner like
http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourcefo=
rge
.
* Change from Ant to Maven2: In the Java world, Maven2 is gaining
quite momentum. There are more than 600 projects listed on
http://repo1.maven.org/maven2/ which are known be some form of a
maven2 project. Maven has the advantage that all dependencies (and
its transitive dependencies) for a project to compile and run are
not needed to be copied into the project. Rather than that,
dependencies are are just specified and, at the first build time,
downloaded on demand. One major advantage is the relief of the
burden to maintain a coherent set of dependencies (and its
transitive dependencies), and a very simple way to change
dependencies. (Example: I upgraded the CVS copy of ant recently by
a version which is 4 years newer, which created a lot of noise in
the logs.) Another advantage is that TM4J being a Maven2 project
makes itself very easily usable by other Java projects (especially
those which use Maven2), without a hassle to configure classpaths
and such. A further advantage is that TM4J may optionally depend
on GPL code (like DB4O for a persistent backend), which is not
possible when including GPL software in the repository directly.
It would be nice if you could give your comments or you "amen" (or
"ramen" if you believe in FSM) to these changes within the next days or
weeks and if anybody else could comment on it.
ciao,
Xu=E2n.
P.S.: Who is the "operational" project admin of TM4J (is there any?). It
looks like the developer of the Ruby Topic Maps engine (
http://rtm.rubyforge.org/ ) is going to need commit rights at some
future point in time, and it would be nice to know who to ask. We are
currently planning a bridge between Ruby and Java such that RTM may be
able to use TM4J as a backend. Furthermore, we are currently playing
around with automatic generation of Java topicmap engines using Ruby
domain specific languages (thus vastly improving development speed, as
many codings once done for one TopicMapConstruct have to be repeated
very similarily for all the other TopicMapConstructs). It also possible
to generate topic map engines with different properties (e.g. engines
where locators are represented internally not as Locator objects, but as
plain UTF-16 sequences or as plain UTF-8 sequences, improving memory
usage, or engines where different ways of indexing are used). At some
point of time, it may be good for TM4J engines to be generatable in this
way.
|
|
From: SourceForge.net <no...@so...> - 2007-07-22 11:29:56
|
Bugs item #1749949, was opened at 2007-07-08 18:40 Message generated for change (Comment added) made by kordzik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1749949&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kordzik (kordzik) Assigned to: Nobody/Anonymous (nobody) Summary: Topic.createTopicName(...) throws NullPointerException Initial Comment: This refers to release 0.9.8, in-memory implementation (although I doubt it has influence on the bug). I use TMAPI interface. If it is attempted to create a TopicName with exactly the same value as previously removed TopicName (using Topic.createTopicName(String, Collection)), a RuntimeException is thrown, which is initiated by a NullPointerException. As far as I could infer, it has something to do with internal events that notify listeners (indexes probably?) that new name was created. The relevant part of the exception stack: Exception in thread "main" java.lang.RuntimeException: java.lang.NullPointerException at org.tm4j.tmapi.core.TMAPITopicImpl.createTopicName(TMAPITopicImpl.java:78) Example code to replicate the bug: //assumed TopicMap tm is instantianated beforehand //creating new user topic Topic type = tm.createTopic(); Topic t = tm.createTopic(); // creating scope collection Vector<Topic> scope = new Vector<Topic>(); scope.add(type); // creating name t.createTopicName("name", scope); //removing topic t.remove(); //creating new one t = tm.createTopic(); //RuntimeException occurs at the following line t.createTopicName("name", scope); ---------------------------------------------------------------------- >Comment By: Kordzik (kordzik) Date: 2007-07-22 13:26 Message: Logged In: YES user_id=1830063 Originator: YES Hello Mediumnet, Thank you for your response. I agree with the submitted code. Not sure about one thing only - if: "catch (TMAPIException ex) { fail("Unexpected exception: " + ex.toString()); }" will acutally catch the "bug" exception, since as far as I remember, a RuntimeException is thrown in this case. Or was it intented not to catch it? In the end, the test will fail anyway:) (as error, not failure) ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-07-22 00:54 Message: Logged In: YES user_id=506885 Originator: NO Hello Kordzik, I can confirm you problem. I have added a test case accordingly to the sourcecode, as you can see here: https://sourceforge.net/mailarchive/message.php?msg_name=E1ICNgK-0003V3-7g%40mail.sourceforge.net . I assume that you agree with that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1749949&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-07-21 22:54:27
|
Bugs item #1749949, was opened at 2007-07-08 18:40 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1749949&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kordzik (kordzik) Assigned to: Nobody/Anonymous (nobody) Summary: Topic.createTopicName(...) throws NullPointerException Initial Comment: This refers to release 0.9.8, in-memory implementation (although I doubt it has influence on the bug). I use TMAPI interface. If it is attempted to create a TopicName with exactly the same value as previously removed TopicName (using Topic.createTopicName(String, Collection)), a RuntimeException is thrown, which is initiated by a NullPointerException. As far as I could infer, it has something to do with internal events that notify listeners (indexes probably?) that new name was created. The relevant part of the exception stack: Exception in thread "main" java.lang.RuntimeException: java.lang.NullPointerException at org.tm4j.tmapi.core.TMAPITopicImpl.createTopicName(TMAPITopicImpl.java:78) Example code to replicate the bug: //assumed TopicMap tm is instantianated beforehand //creating new user topic Topic type = tm.createTopic(); Topic t = tm.createTopic(); // creating scope collection Vector<Topic> scope = new Vector<Topic>(); scope.add(type); // creating name t.createTopicName("name", scope); //removing topic t.remove(); //creating new one t = tm.createTopic(); //RuntimeException occurs at the following line t.createTopicName("name", scope); ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-07-22 00:54 Message: Logged In: YES user_id=506885 Originator: NO Hello Kordzik, I can confirm you problem. I have added a test case accordingly to the sourcecode, as you can see here: https://sourceforge.net/mailarchive/message.php?msg_name=E1ICNgK-0003V3-7g%40mail.sourceforge.net . I assume that you agree with that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1749949&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-07-08 16:40:20
|
Bugs item #1749949, was opened at 2007-07-08 18:40 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=1749949&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kordzik (kordzik) Assigned to: Nobody/Anonymous (nobody) Summary: Topic.createTopicName(...) throws NullPointerException Initial Comment: This refers to release 0.9.8, in-memory implementation (although I doubt it has influence on the bug). I use TMAPI interface. If it is attempted to create a TopicName with exactly the same value as previously removed TopicName (using Topic.createTopicName(String, Collection)), a RuntimeException is thrown, which is initiated by a NullPointerException. As far as I could infer, it has something to do with internal events that notify listeners (indexes probably?) that new name was created. The relevant part of the exception stack: Exception in thread "main" java.lang.RuntimeException: java.lang.NullPointerException at org.tm4j.tmapi.core.TMAPITopicImpl.createTopicName(TMAPITopicImpl.java:78) Example code to replicate the bug: //assumed TopicMap tm is instantianated beforehand //creating new user topic Topic type = tm.createTopic(); Topic t = tm.createTopic(); // creating scope collection Vector<Topic> scope = new Vector<Topic>(); scope.add(type); // creating name t.createTopicName("name", scope); //removing topic t.remove(); //creating new one t = tm.createTopic(); //RuntimeException occurs at the following line t.createTopicName("name", scope); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1749949&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-23 13:18:31
|
Bugs item #1704268, was opened at 2007-04-20 13:58 Message generated for change (Comment added) made by lheuer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Occurence may be member of zero to many different Topics Initial Comment: By analyzing the current code, I found out following: (1) Occurences may be removed from their parent topic by calling setOccurences(new Occurence[0]) on the parent topic. Then, these occurences are orphaned. (2) Occurences may be added to a different topic by calling setOccurences(new Occurence[foreignOccurence]) or by calling addOccurrence(foreignOccurence); (3) Occurences may be added to a different topic by calling newTopic.setOccurences(new Occurence[foreignOccurence]) while still not being removed from the old parent. Orphaned occurences are not supported by TMDM or by TMAPI. Moving occurences between different topics is also not supported by TMAPI. Support for orphaning occurences (for other reasons than to finally destroying them) and adding orphaned occurences should thus be removed. Thus, as a first step, the corresponding methods should be deprecated. I'm not sure wether any TM4J application exists which moves occurences between topics. I'm also not sure wether any TM4J applications exists which implicitly removes occurences from their parentTopic by calling parentTopic.setOccurences(smallerOccurenceArray) as opposed to just explicitly removing occurences by calling occurence.destroy(). If no such application exists, the methods Topic.addOccurrence() and Topic.setOccurrences() could be simply removed (the remaining functionality of Topic.setOccurences() would be just removing occurences, but this functionality is also available by calling occurence.destroy().) ---------------------------------------------------------------------- >Comment By: Lars Heuer (lheuer) Date: 2007-04-23 15:18 Message: Logged In: YES user_id=399396 Originator: NO My point is, that you need to be able to move roles, occurrences, names, variants from one parent to another for merging purposes. So, you need to keep track about them anyway (indexing etc.). The question is, if we want to enable the user to move them or not. And, if you delegate all add<child> / remove<child> to the concrete implementations, you have to write a merging procedure for each backend (or you introduce internal interfaces). IMO the problem is not add<child>/remove<child> methods, but some bugs in the TM4J code that do not set the correct parent and / or forget to dereference the parent. ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-22 10:31 Message: Logged In: YES user_id=506885 Originator: YES One more comment regarding the conflict between the possiblity of orphaned occurences with TMDM: TMDM not just requires the parent of an occurence to be always set, but it tells also that the relationship between an occurence and its parent is not simply a UML association, but a UML composition, as you can judge from the black filled diamond at http://www.isotopicmaps.org/sam/sam-model/#d0e1029 between Occurence and Topic. That strongly means that an occurence may not exist without a containing topic. ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-20 15:43 Message: Logged In: YES user_id=506885 Originator: YES Lars Heuer voiced concerns regarding the depreciation (and later removal) of Topic.addOccurence() (using private e-mail, because the SF bug tracker did not work temporarily). He also pointed out that this issue does not only apply to Occurences. It would be nice if you, Lars, could elaborate your point again here, if you like. I want to clarify that I do not intend to remove the implementation of addOccurence() in TopicImpl, but I want to remove addOccurence() from the interface Topic. Reasons are that else Occurences could be (at least temporarily) without a parenting Topic, which would complicate indexing of TopicMaps, be in contradiction to TMDM, be in contradiction to TMAPI. Additionally, it would create more memory requirements, as then (new) backends would be forced to support Occurences which belong to a particular TopicMap, while not belonging to a particular topic, thus requiring the Occurence to know its TopicMap explicitly (and not implictly by knowing its Topic) which would require an extra pointer per Occurence (at least if implemented straightforwardly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-22 08:31:32
|
Bugs item #1704268, was opened at 2007-04-20 13:58 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Occurence may be member of zero to many different Topics Initial Comment: By analyzing the current code, I found out following: (1) Occurences may be removed from their parent topic by calling setOccurences(new Occurence[0]) on the parent topic. Then, these occurences are orphaned. (2) Occurences may be added to a different topic by calling setOccurences(new Occurence[foreignOccurence]) or by calling addOccurrence(foreignOccurence); (3) Occurences may be added to a different topic by calling newTopic.setOccurences(new Occurence[foreignOccurence]) while still not being removed from the old parent. Orphaned occurences are not supported by TMDM or by TMAPI. Moving occurences between different topics is also not supported by TMAPI. Support for orphaning occurences (for other reasons than to finally destroying them) and adding orphaned occurences should thus be removed. Thus, as a first step, the corresponding methods should be deprecated. I'm not sure wether any TM4J application exists which moves occurences between topics. I'm also not sure wether any TM4J applications exists which implicitly removes occurences from their parentTopic by calling parentTopic.setOccurences(smallerOccurenceArray) as opposed to just explicitly removing occurences by calling occurence.destroy(). If no such application exists, the methods Topic.addOccurrence() and Topic.setOccurrences() could be simply removed (the remaining functionality of Topic.setOccurences() would be just removing occurences, but this functionality is also available by calling occurence.destroy().) ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-22 10:31 Message: Logged In: YES user_id=506885 Originator: YES One more comment regarding the conflict between the possiblity of orphaned occurences with TMDM: TMDM not just requires the parent of an occurence to be always set, but it tells also that the relationship between an occurence and its parent is not simply a UML association, but a UML composition, as you can judge from the black filled diamond at http://www.isotopicmaps.org/sam/sam-model/#d0e1029 between Occurence and Topic. That strongly means that an occurence may not exist without a containing topic. ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-20 15:43 Message: Logged In: YES user_id=506885 Originator: YES Lars Heuer voiced concerns regarding the depreciation (and later removal) of Topic.addOccurence() (using private e-mail, because the SF bug tracker did not work temporarily). He also pointed out that this issue does not only apply to Occurences. It would be nice if you, Lars, could elaborate your point again here, if you like. I want to clarify that I do not intend to remove the implementation of addOccurence() in TopicImpl, but I want to remove addOccurence() from the interface Topic. Reasons are that else Occurences could be (at least temporarily) without a parenting Topic, which would complicate indexing of TopicMaps, be in contradiction to TMDM, be in contradiction to TMAPI. Additionally, it would create more memory requirements, as then (new) backends would be forced to support Occurences which belong to a particular TopicMap, while not belonging to a particular topic, thus requiring the Occurence to know its TopicMap explicitly (and not implictly by knowing its Topic) which would require an extra pointer per Occurence (at least if implemented straightforwardly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-20 13:43:31
|
Bugs item #1704268, was opened at 2007-04-20 13:58 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Occurence may be member of zero to many different Topics Initial Comment: By analyzing the current code, I found out following: (1) Occurences may be removed from their parent topic by calling setOccurences(new Occurence[0]) on the parent topic. Then, these occurences are orphaned. (2) Occurences may be added to a different topic by calling setOccurences(new Occurence[foreignOccurence]) or by calling addOccurrence(foreignOccurence); (3) Occurences may be added to a different topic by calling newTopic.setOccurences(new Occurence[foreignOccurence]) while still not being removed from the old parent. Orphaned occurences are not supported by TMDM or by TMAPI. Moving occurences between different topics is also not supported by TMAPI. Support for orphaning occurences (for other reasons than to finally destroying them) and adding orphaned occurences should thus be removed. Thus, as a first step, the corresponding methods should be deprecated. I'm not sure wether any TM4J application exists which moves occurences between topics. I'm also not sure wether any TM4J applications exists which implicitly removes occurences from their parentTopic by calling parentTopic.setOccurences(smallerOccurenceArray) as opposed to just explicitly removing occurences by calling occurence.destroy(). If no such application exists, the methods Topic.addOccurrence() and Topic.setOccurrences() could be simply removed (the remaining functionality of Topic.setOccurences() would be just removing occurences, but this functionality is also available by calling occurence.destroy().) ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-20 15:43 Message: Logged In: YES user_id=506885 Originator: YES Lars Heuer voiced concerns regarding the depreciation (and later removal) of Topic.addOccurence() (using private e-mail, because the SF bug tracker did not work temporarily). He also pointed out that this issue does not only apply to Occurences. It would be nice if you, Lars, could elaborate your point again here, if you like. I want to clarify that I do not intend to remove the implementation of addOccurence() in TopicImpl, but I want to remove addOccurence() from the interface Topic. Reasons are that else Occurences could be (at least temporarily) without a parenting Topic, which would complicate indexing of TopicMaps, be in contradiction to TMDM, be in contradiction to TMAPI. Additionally, it would create more memory requirements, as then (new) backends would be forced to support Occurences which belong to a particular TopicMap, while not belonging to a particular topic, thus requiring the Occurence to know its TopicMap explicitly (and not implictly by knowing its Topic) which would require an extra pointer per Occurence (at least if implemented straightforwardly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895 |
|
From:
<xua...@ba...> - 2007-04-20 13:07:02
|
Peri wrote: > hi, Hi Peri, > > Topic: > Copy of contents xtm files to my-sql DBMS. > The process goes smooth till it finds scope object in either > <basename(s)> or <occurrence(s)> > > > If observed, in the method copyScopedObject of > TopicMapFactoryBase.TopicMapFactoryBase, the Topic object is sent as > is to the implementation classes, which works fine if the copy is > performed at the same level (file-system to file-system). > > Have tried fixing this problem and did a bit of testing too, to copy > the topics from various XTM, provided in the example section. thank you for your patch. I applied your patch to both the "MAIN" and the "TM4J_1_x" branch of TM4J. > > If there is a process I would have to follow in order to test the > validity of my logic, please let me know. I wish TM4J had a comprehensive test suite that could be applied before checking in a patch, but (apart from "ant ozone-test", which is not really a test suite), I'm not aware of any test suite for TM4J. Using the mailing-list is okay (for me), but maybe raising a bug at https://sourceforge.net/tracker/?group_id=27895&atid=391879 would make the discussion more standardized. :-) > > Thank you. Thank you, too, for digging into the problem and contributing a patch. :-) > > > > > On 4/12/07, *Peri* <per...@gm... <mailto:per...@gm...>> > wrote: > > Hi, > I am trying to perform a copy from a TopicMap generated from in > memory provider and populate my topicmap stored in the database. > While copying the scope bounded basenames, the copy operations > errors out with a class cast exception... > > > TopicMap: > topicmaps/kings_and_queens.xtm # Sample provided in the examples > > Code Snippet: > TopicMapProvider provider_m = > tmpf_m.newTopicMapProvider(providerProps); > Locator baseLocator_m = > provider_m.getLocatorFactory().createLocator("URI", getInputURI()); > > TopicMapSource src_m = new > SerializedTopicMapSource(getInputStream(), baseLocator_m); > > // Parse the topic map > TopicMap tm_m = provider_m.addTopicMap(src_m); > > TopicMapProvider provider_h = > tmpf_h.newTopicMapProvider(providerProps); > Locator baseLocator_h = > provider_h.getLocatorFactory().createLocator("URI", getInputURI()); > > TopicMap tm_h = provider_h.getTopicMap(baseLocator_h); > provider_h.removeTopicMap(tm_h); > tm_h = provider_h.createTopicMap(baseLocator_h); > > // Perform a copy > tm_h.getFactory().copy(tm_m); > > > Stack trace: > Exception in thread "main" > org.tm4j.topicmap.TopicMapRuntimeException: > Cause: java.lang.ClassCastException: > org.tm4j.topicmap.memory.TopicImpl cannot be cast to > org.tm4j.topicmap.hibernate.TopicImpl > Cause:org.tm4j.topicmap.memory.TopicImpl cannot be cast to > org.tm4j.topicmap.hibernate.TopicImpl > at > org.tm4j.topicmap.hibernate.ScopedObjectImpl.setScope(Unknown Source) > at > org.tm4j.topicmap.TopicMapFactoryBase.copyScopedObject(TopicMapFactoryBase.java:741) > at > org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java:507) > at org.tm4j.topicmap.TopicMapFactoryBase.copy > (TopicMapFactoryBase.java:259) > at > org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java:212) > at > org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java:203) > at org.tm4j.topicmap.TopicMapFactoryBase.copy > (TopicMapFactoryBase.java:96) > at > com.krl.examples.HibernateProviderTest.setUp(HibernateProviderTest.java:97) > at > com.krl.examples.HibernateProviderTest.main(HibernateProviderTest.java:108) > Caused by: java.lang.ClassCastException : > org.tm4j.topicmap.memory.TopicImpl cannot be cast to > org.tm4j.topicmap.hibernate.TopicImpl > at > org.tm4j.topicmap.hibernate.ScopedObjectImpl.setScope(Unknown Source) > ... 9 more > > Am I missing anything here... > > > Any help would me much appreciated!!! > -- > warm regards > Peri > > The best way out of difficulty is through it. :) > > > > > -- > warm regards > Peri > > The best way out of difficulty is through it. :) > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
|
From: SourceForge.net <no...@so...> - 2007-04-20 11:58:33
|
Bugs item #1704268, was opened at 2007-04-20 13:58 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=1704268&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Occurence may be member of zero to many different Topics Initial Comment: By analyzing the current code, I found out following: (1) Occurences may be removed from their parent topic by calling setOccurences(new Occurence[0]) on the parent topic. Then, these occurences are orphaned. (2) Occurences may be added to a different topic by calling setOccurences(new Occurence[foreignOccurence]) or by calling addOccurrence(foreignOccurence); (3) Occurences may be added to a different topic by calling newTopic.setOccurences(new Occurence[foreignOccurence]) while still not being removed from the old parent. Orphaned occurences are not supported by TMDM or by TMAPI. Moving occurences between different topics is also not supported by TMAPI. Support for orphaning occurences (for other reasons than to finally destroying them) and adding orphaned occurences should thus be removed. Thus, as a first step, the corresponding methods should be deprecated. I'm not sure wether any TM4J application exists which moves occurences between topics. I'm also not sure wether any TM4J applications exists which implicitly removes occurences from their parentTopic by calling parentTopic.setOccurences(smallerOccurenceArray) as opposed to just explicitly removing occurences by calling occurence.destroy(). If no such application exists, the methods Topic.addOccurrence() and Topic.setOccurrences() could be simply removed (the remaining functionality of Topic.setOccurences() would be just removing occurences, but this functionality is also available by calling occurence.destroy().) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895 |
|
From: Peri <per...@gm...> - 2007-04-17 11:17:03
|
hi,
Topic:
Copy of contents xtm files to my-sql DBMS.
The process goes smooth till it finds scope object in either <basename(s)>
or <occurrence(s)>
If observed, in the method copyScopedObject of
TopicMapFactoryBase.TopicMapFactoryBase, the Topic object is sent as is to
the implementation classes, which works fine if the copy is performed at the
same level (file-system to file-system).
Have tried fixing this problem and did a bit of testing too, to copy the
topics from various XTM, provided in the example section.
If there is a process I would have to follow in order to test the validity
of my logic, please let me know.
Thank you.
On 4/12/07, Peri <per...@gm...> wrote:
>
> Hi,
> I am trying to perform a copy from a TopicMap generated from in memory
> provider and populate my topicmap stored in the database.
> While copying the scope bounded basenames, the copy operations errors out
> with a class cast exception...
>
>
> TopicMap:
> topicmaps/kings_and_queens.xtm # Sample provided in the examples
>
> Code Snippet:
> TopicMapProvider provider_m = tmpf_m.newTopicMapProvider(providerProps);
> Locator baseLocator_m =
> provider_m.getLocatorFactory().createLocator("URI", getInputURI());
>
> TopicMapSource src_m = new SerializedTopicMapSource(getInputStream(),
> baseLocator_m);
>
> // Parse the topic map
> TopicMap tm_m = provider_m.addTopicMap(src_m);
>
> TopicMapProvider provider_h = tmpf_h.newTopicMapProvider(providerProps);
> Locator baseLocator_h =
> provider_h.getLocatorFactory().createLocator("URI", getInputURI());
>
> TopicMap tm_h = provider_h.getTopicMap(baseLocator_h);
> provider_h.removeTopicMap(tm_h);
> tm_h = provider_h.createTopicMap(baseLocator_h);
>
> // Perform a copy
> tm_h.getFactory().copy(tm_m);
>
>
> Stack trace:
> Exception in thread "main" org.tm4j.topicmap.TopicMapRuntimeException:
> Cause: java.lang.ClassCastException: org.tm4j.topicmap.memory.TopicImplcannot be cast to
> org.tm4j.topicmap.hibernate.TopicImpl
> Cause:org.tm4j.topicmap.memory.TopicImpl cannot be cast to
> org.tm4j.topicmap.hibernate.TopicImpl
> at org.tm4j.topicmap.hibernate.ScopedObjectImpl.setScope(Unknown
> Source)
> at org.tm4j.topicmap.TopicMapFactoryBase.copyScopedObject(
> TopicMapFactoryBase.java:741)
> at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
> :507)
> at org.tm4j.topicmap.TopicMapFactoryBase.copy (
> TopicMapFactoryBase.java:259)
> at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
> :212)
> at org.tm4j.topicmap.TopicMapFactoryBase.copy(TopicMapFactoryBase.java
> :203)
> at org.tm4j.topicmap.TopicMapFactoryBase.copy (
> TopicMapFactoryBase.java:96)
> at com.krl.examples.HibernateProviderTest.setUp(
> HibernateProviderTest.java:97)
> at com.krl.examples.HibernateProviderTest.main(
> HibernateProviderTest.java:108)
> Caused by: java.lang.ClassCastException :
> org.tm4j.topicmap.memory.TopicImpl cannot be cast to
> org.tm4j.topicmap.hibernate.TopicImpl
> at org.tm4j.topicmap.hibernate.ScopedObjectImpl.setScope(Unknown
> Source)
> ... 9 more
>
> Am I missing anything here...
>
>
> Any help would me much appreciated!!!
> --
> warm regards
> Peri
>
> The best way out of difficulty is through it. :)
--
warm regards
Peri
The best way out of difficulty is through it. :)
|
|
From: SourceForge.net <no...@so...> - 2007-04-17 05:05:02
|
Bugs item #1698885, was opened at 2007-04-12 03:59 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Import/Export Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: org.tm4j.topicmap.cmd.Merge crashes Initial Comment: call "java org.tm4j.topicmap.cmd.Merge -c test.xtm", where "test.xtm" is this file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "http://www.topicmaps.org/xtm/1.0/xtm1.dtd"> <topicMap id="x1nnj36ct9-0" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <topic id="id129"> <instanceOf> <topicRef xlink:href="#x1nnj36d5b-7"/> </instanceOf> </topic> <topic id="x1nnj36d5b-7"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://psi.somewhere/#something"/> </subjectIdentity> </topic> </topicMap> And you will get something like: 2 [main] FATAL org.tm4j.topicmap.cmd.Merge - Unexpected exception. java.lang.NullPointerException at java.util.Collections$UnmodifiableCollection.<init>(Collections.java:994) at java.util.Collections$UnmodifiableSet.<init>(Collections.java:1066) at java.util.Collections.unmodifiableSet(Collections.java:1056) at org.tm4j.topicmap.memory.TopicMapObjectImpl.getSourceLocators(TopicMapObjectImpl.java:175) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1673) at org.tm4j.topicmap.memory.TopicImpl.getSourceLocators(TopicImpl.java:1662) at org.tm4j.topicmap.utils.XTMWriter.getResourceID(XTMWriter.java:857) at org.tm4j.topicmap.utils.XTMWriter.getID(XTMWriter.java:927) at org.tm4j.topicmap.utils.XTMWriter.topicRef(XTMWriter.java:703) at org.tm4j.topicmap.utils.XTMWriter.onType(XTMWriter.java:605) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:119) at org.tm4j.topicmap.utils.TopicMapWalker.walk(TopicMapWalker.java:86) at org.tm4j.topicmap.utils.TopicMapSerializer.serialize(TopicMapSerializer.java:373) at org.tm4j.topicmap.cmd.Merge.run(Merge.java:99) at org.tm4j.topicmap.cmd.AppBase.initialise(AppBase.java:190) at org.tm4j.topicmap.cmd.Merge.<init>(Merge.java:62) at org.tm4j.topicmap.cmd.Merge.main(Merge.java:117) ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-17 07:05 Message: Logged In: YES user_id=506885 Originator: YES Partially fixed in CVS. (It works, but there may be cases left where it does not work.) ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-12 10:02 Message: Logged In: YES user_id=506885 Originator: YES This patch fixes the bug (at least makes the testcase succeed). File Added: removeMergedTopic.partialSupport.patch ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-12 09:54 Message: Logged In: YES user_id=506885 Originator: YES The cause seems to be in unmerging topics not being properly supported. XTMUtils.flattenTopicRefs destroys some topics. However, these destroyed topics may be merged with other topics. Thus, the destroyed topic needs to be properly unmerged from its merging partners. This seems to be not implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698885&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-17 04:48:57
|
Bugs item #1698489, was opened at 2007-04-11 16:20 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698489&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Import/Export Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Bursting of filedescriptor usage in org.tm4j.topicmap.cmd.* Initial Comment: When merging a large amount of small XTM files, the number of filedescriptors run out. The reason is that, currently, all files are opened before the first file is processed. This practically makes processing of a certain amount of files in one run impossible. ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-17 06:48 Message: Logged In: YES user_id=506885 Originator: YES Fixed in CVS. ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-11 16:22 Message: Logged In: YES user_id=506885 Originator: YES The solution works by delaying the actual opening of the underlying FileInputStream or URLInputStream up to the point the files are actually read and by hurrying up closing the underlying InputStream by closing directly after the last byte was read. File Added: onDemandInputStreams.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1698489&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-17 04:04:15
|
Feature Requests item #1698486, was opened at 2007-04-11 16:10 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1698486&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line apps Group: None >Status: Closed Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Support arguments file Initial Comment: Each platform the Java VM runs on has only a limited amount of arguments. If one wants to merge a massive amount of small XTM files, one may run out of arguments. Thus, the TM4J command line applications should support an "arguments file". That is a file which contains all the arguments without a limit on the number of arguments. ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-17 06:04 Message: Logged In: YES user_id=506885 Originator: YES Fixed in CVS. ---------------------------------------------------------------------- Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-11 16:14 Message: Logged In: YES user_id=506885 Originator: YES File Added: argumentsFile.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1698486&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2007-04-17 03:57:06
|
Feature Requests item #1699114, was opened at 2007-04-12 12:44 Message generated for change (Comment added) made by mediumnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1699114&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: None >Status: Closed Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: Update browserLauncher.jar Initial Comment: The "current" browserLauncher.jar distributed with tmnav is from the year 2003 and thus very outdated (and also buggy). Use a new copy of browserLauncher from http://browserlaunch2.sourceforge.net/ . It straightly works as a drop-in-replacement on my machine. ---------------------------------------------------------------------- >Comment By: Xuan Baldauf (mediumnet) Date: 2007-04-17 05:57 Message: Logged In: YES user_id=506885 Originator: YES Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1699114&group_id=27895 |
|
From: Lars H. <he...@se...> - 2007-04-13 16:02:14
|
Hi Xuân, [...] >> The topic type was/is used as simplification of a >> type-instance association (in the unconstrained scope). IMO it is >> useful from the API-user perspective. >> > Yes. But for me, there is no compelling reason to actually treat these > types of associations specially internally (actually, this made the Well, you could add associations behind the scenes. It is an implementation matter. > implementation of some of my TM4J applications harder). This increases > code complexity. And, these types of associations are missing as > ordinary associations (which is a bug then, not a feature of XTM 1.0, as > you pointed out). Well, "bug" depends on the perspective. :) As long as it is well documentated it is not a bug, IMO. AFAIK, nearly all Topic Maps engines support this "bug". It is easy to translate the "types" Set into associations and vice versa. [...] > However, I do not see why org.tmapi.core.Topic.getReified() returns a > Set<TopicMapObject>, not a plain TopicMapObject (or null). Allowing more Historical reasons. :) And the reification mechanism has been changed between XTM and TMDM. [...] > should be fixed in TMAPI, (Maybe along with aligning TMAPI to the latest > TMDM and to Java 1.5 as well. Maybe a kind of parallel project "TMAPI 2" ACK. But I am afraid that the TMAPI group is too lazy / busy to make a change. If you look into the TMAPI bug tracker, you'll see, that there are several feature requests which address these issues. [...] >> If you look into the classes located in the org.tm4j.tmapi package >> <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/tmapi/core/> >> you'll see some of the problems with the current TM4J-API and a >> TMDM-alike API. >> > After a short glance (maybe too short), I see just lots of wrapping work > (where I ask myself why does org.tm4j.topicmap.* not just extend > org.tmapi.core.*), Again, historical reasons. :) The TM4J API is older than TMAPI. And it was planned that TM4J should implement the TMAPI interfaces directly after 1.x, I guess. > I do not currently see specific problems (however, my > glance may not have been thorough enough). Would you mind pointing out a > serious (e.g. hard to fix) problem of the current TM4J-API? Hmmm.... . Without looking into the code, the handling variants and members are a lot different and if I remember right, there are some situations where a translation of the TM4J API into a TMDM-alike API is not possible. Sorry. Not very concrete... ;) Maybe you want to look into the code again and search for situations where a runtime exception is thrown (i.e. TMAPIRuntimeException). Additionally, TM4J is currently not datatype-aware (and TMAPI is also datatype-blind), you have to enhance the Occurrence / Variant or DataObject interfaces. All in all, a lot of work... . I am not sure if it is valueable to keep a TMDM/XTM 2.0 branch backwards compatible. I'd start with new interfaces / a new API (maybe an API which enhances the TMAPI interfaces). Best regards, Lars -- http://www.semagia.com |
|
From: SourceForge.net <no...@so...> - 2007-04-13 15:20:07
|
Bugs item #1700145, was opened at 2007-04-13 17:20 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=1700145&group_id=27895 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: In-Memory Impl Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xuan Baldauf (mediumnet) Assigned to: Nobody/Anonymous (nobody) Summary: TM4J forgets ordinary type-instance associations Initial Comment: TM4J has special support for type-instance associations (see http://www.isotopicmaps.org/sam/sam-model/#sect-types or http://www.topicmaps.org/xtm/index.html#desc-class-instance ) at the API level, such that it is conventient for the user to manipulate these associations using these special methods. However, TM4J treats these types of associations also specially internally, such that they do not show up as associations of the topics involved. Thus, TM4J currently does not reflect the data model of neither XTM 1.0 nor of the current TMDM draft. (Probably, these associations also do not show up as associations of one topic map.) See https://sourceforge.net/mailarchive/message.php?msg_name=461F9C5D.505%40baldauf.org for some discussion on this. Thanks to Lars Heuer for pointing out that this behaviour is TM4J-specific and not XTM-1.0-specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1700145&group_id=27895 |
|
From:
<xua...@ba...> - 2007-04-13 15:06:35
|
Lars Heuer wrote: > Hi Xu=C3=A2n, > > [...] > =20 >>> IMO very difficult if you want to support TMDM. >>> =20 >>> =20 >> My current idea is to support a superset of TMDM and the current TM4J = as >> laid out in >> http://tm4j.cvs.sourceforge.net/*checkout*/tm4j/tm4j/docs/TMDM-support= =2Ehtml?revision=3D1.1 >> . >> =20 > > One comment against the doc: > =20 You are free to change or amend it. :-) (However, a Wiki may or may not more appropriate for this.) > [...] > - topic type (removed in TMDM, replaced by a > http://psi.topicmaps.org/iso13250/model/type-instance association) > > In XTM 1.0 the type-instance (resp. class-instance) relationship is > also modelled by an association. Cf. > <http://www.topicmaps.org/xtm/index.html#desc-class-instance>. TMDM > does not remove or add something (the PSIs and terminology has been > changed, though). > =20 You are right. :-) I changed the document accordingly. > The topic type was/is used as simplification of a > type-instance association (in the unconstrained scope). IMO it is > useful from the API-user perspective. > =20 Yes. But for me, there is no compelling reason to actually treat these types of associations specially internally (actually, this made the implementation of some of my TM4J applications harder). This increases code complexity. And, these types of associations are missing as ordinary associations (which is a bug then, not a feature of XTM 1.0, as you pointed out). > > > TMAPI <http://www.tmapi.org/> is not perfect and not aligned to the > latest TMDM, but IMO it would be useful to keep an eye on the API or > use the lib and create your own interfaces ontop of it, i.e. > > public interface Occurrence extends org.tmapi.core.Occurrence { > > public void setValue(String value, Locator datatype); > > [...] > } > > You would support TMAPI natively but your implementation would be > TMAPI-independent. If the project dies, you can still use your > interfaces. The only problem I see is the Topic#getReified() method, > which returns a Set. But an additional Topic#getReifiedObject() or > something like that should solve it. > =20 Yes. However, I do not see why org.tmapi.core.Topic.getReified() returns a Set<TopicMapObject>, not a plain TopicMapObject (or null). Allowing more than one TopicMapObject to be returned violates the very basic topic map contract of "one topic represents at most one subject". Maybe this should be fixed in TMAPI, (Maybe along with aligning TMAPI to the latest TMDM and to Java 1.5 as well. Maybe a kind of parallel project "TMAPI 2" should be launched, but I maybe this would create more resistance, as there are more users involved, maybe less, because at least someone does the work which should be done anyway. I do not know. ;-)) > Best regards, > Lars > =20 Lars Heuer wrote: > [...] > =20 >> TMAPI <http://www.tmapi.org/> is not perfect and not aligned to the >> latest TMDM, but IMO it would be useful to keep an eye on the API or >> =20 > [...] > > If you look into the classes located in the org.tm4j.tmapi package > <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/tmapi/core/> > you'll see some of the problems with the current TM4J-API and a > TMDM-alike API. > =20 After a short glance (maybe too short), I see just lots of wrapping work (where I ask myself why does org.tm4j.topicmap.* not just extend org.tmapi.core.*), I do not currently see specific problems (however, my glance may not have been thorough enough). Would you mind pointing out a serious (e.g. hard to fix) problem of the current TM4J-API? > Best regards, > Lars > =20 Thank you, Xu=C3=A2n. :-) |
|
From: Lars H. <he...@se...> - 2007-04-13 12:11:07
|
[...] > TMAPI <http://www.tmapi.org/> is not perfect and not aligned to the > latest TMDM, but IMO it would be useful to keep an eye on the API or [...] If you look into the classes located in the org.tm4j.tmapi package <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/tmapi/core/> you'll see some of the problems with the current TM4J-API and a TMDM-alike API. Best regards, Lars -- http://www.semagia.com |
|
From: Lars H. <he...@se...> - 2007-04-13 12:03:20
|
Hi Xuân, [...] >> IMO very difficult if you want to support TMDM. >> > My current idea is to support a superset of TMDM and the current TM4J as > laid out in > http://tm4j.cvs.sourceforge.net/*checkout*/tm4j/tm4j/docs/TMDM-support.html?revision=1.1 > . One comment against the doc: [...] - topic type (removed in TMDM, replaced by a http://psi.topicmaps.org/iso13250/model/type-instance association) In XTM 1.0 the type-instance (resp. class-instance) relationship is also modelled by an association. Cf. <http://www.topicmaps.org/xtm/index.html#desc-class-instance>. TMDM does not remove or add something (the PSIs and terminology has been changed, though). The topic type was/is used as simplification of a type-instance association (in the unconstrained scope). IMO it is useful from the API-user perspective. TMAPI <http://www.tmapi.org/> is not perfect and not aligned to the latest TMDM, but IMO it would be useful to keep an eye on the API or use the lib and create your own interfaces ontop of it, i.e. public interface Occurrence extends org.tmapi.core.Occurrence { public void setValue(String value, Locator datatype); [...] } You would support TMAPI natively but your implementation would be TMAPI-independent. If the project dies, you can still use your interfaces. The only problem I see is the Topic#getReified() method, which returns a Set. But an additional Topic#getReifiedObject() or something like that should solve it. Best regards, Lars -- http://www.semagia.com |
153 messages has been excluded from this view by a project administrator.
