tm4j-developers Mailing List for TM4J (Page 4)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

VluAGRA for LESS http://www.madesikadefinpadewinka.com

=20
Then I remembered and sat upright, grabbed his arms.
We go on-and you take a break. If things are going to be the same,


Bugs item #1552478, was opened at 2006-09-05 09:41
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=1552478&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: Documentation
Group: TM4J 0.9.7
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in Appendix A of developers doc

Initial Comment:
Report from Noel Hubers:

I found a typing error in 'Appendix A. Installing The
Hibernate Back-End'.
The Ant-target for copying the xml in build/classes
directory is 'hibernate-install-mappings'.

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

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



Bugs item #1501213, was opened at 2006-06-05 22:23
Message generated for change (Comment added) made by mediumnet
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1501213&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: CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Xuan Baldauf (mediumnet)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemberImpl.hashCode() is not consistent with equals()

Initial Comment:
When the constructor
org.tm4j.topicmap.memory.MemberImpl( AssociationImpl
parent, String id, Locator resourceLoc, Topic roleSpec,
Collection players) is used,

the to-be-constructed MemberImpl adds itself to each
m_rolesPlayed field of every TopicImpl of the players
collection. This field is a HashSet, and thus,
hashCode() of the MemberImpl object is called. The
method hashCode() (defined in
org.tm4j.topicmap.memory.TopicMapObjectImpl) itself
depends on the id of the MemberImpl object. However,
the id is currently set ("setID(id);") _after_ the
to-be-constructed MemberImpl adds itself to each
m_rolesPlayed field of every TopicImpl of the players
collection.

Thus, hashCode() returns different values at different
times (with a very high probability). In particular,
hashCode() returns a different value before the call to
setID(id) than after the call to setID(id).

This, in turn, makes the call
"m_rolesPlayed.contains(member)" in
org.tm4j.topicmap.memory.TopicImpl.removeRolePlayed(Member
member) return false, while it should return true.

>From this on, the topic map data structure is
inconsistent (and messed up).


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

>Comment By: Xuan Baldauf (mediumnet)
Date: 2006-06-05 22:25

Message:
Logged In: YES 
user_id=506885

This patch should fix the problem:

Index: tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java
===================================================================
RCS file:
/cvsroot/tm4j/tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java,v
retrieving revision 1.24
diff -u -r1.24 MemberImpl.java

--- tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java   7
Mar 2006 15:36:35 -0000       1.24
+++ tm4j/src/org/tm4j/topicmap/memory/MemberImpl.java   5
Jun 2006 20:08:49 -0000
@@ -56,14 +56,14 @@
         m_roleSpec = roleSpec;
         m_players = new ArrayList(players);

+        if (resourceLoc != null) addSourceLocator(resourceLoc);
+        setID(id);
         for (Iterator it = m_players.iterator();
it.hasNext();) {
             TopicImpl t = (TopicImpl) it.next();
             // TODO: Avoid the access of the
Topic.m_rolesPlayed field
             t.m_rolesPlayed.add(this);
         }

-        if (resourceLoc != null) addSourceLocator(resourceLoc);
-        setID(id);
         parent.addMember(this);
     }



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

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



Bugs item #1501213, was opened at 2006-06-05 22:23
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=1501213&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: CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Xuan Baldauf (mediumnet)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemberImpl.hashCode() is not consistent with equals()

Initial Comment:
When the constructor
org.tm4j.topicmap.memory.MemberImpl( AssociationImpl
parent, String id, Locator resourceLoc, Topic roleSpec,
Collection players) is used,

the to-be-constructed MemberImpl adds itself to each
m_rolesPlayed field of every TopicImpl of the players
collection. This field is a HashSet, and thus,
hashCode() of the MemberImpl object is called. The
method hashCode() (defined in
org.tm4j.topicmap.memory.TopicMapObjectImpl) itself
depends on the id of the MemberImpl object. However,
the id is currently set ("setID(id);") _after_ the
to-be-constructed MemberImpl adds itself to each
m_rolesPlayed field of every TopicImpl of the players
collection.

Thus, hashCode() returns different values at different
times (with a very high probability). In particular,
hashCode() returns a different value before the call to
setID(id) than after the call to setID(id).

This, in turn, makes the call
"m_rolesPlayed.contains(member)" in
org.tm4j.topicmap.memory.TopicImpl.removeRolePlayed(Member
member) return false, while it should return true.

>From this on, the topic map data structure is
inconsistent (and messed up).


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

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



* Kal Ahmed
>
> When I tried to migrate TM4J from JDK 1.3 to 1.4, a lot of people  
> complained that they were not able to upgrade their environment to  
> 1.4. I'm not doing a lot of Java development these days, so I don't  
> really have a good feel for how widely used JDK 1.5 is.
>
> I would be interested to hear from the other developers on this  
> list to know what their opinion is.

For what it's worth, Ontopia's experience is that there are still  
organizations whose server environments are standardized on JDK 1.3,  
mainly because they've standardized on early WebSphere or WebLogic  
versions.

--
Lars Marius Garshol, Ontopian               http://www.ontopia.net
+47 98 21 55 50                             http://www.garshol.priv.no





It would be interesting to see that! AFAIK there should be nothing 
stopping you creating an applet. I believe that TouchGraph is quite 
happy to run as an applet. One issue is the number of library JAR files 
required by TM4J - you can cut that down a bit by only using the 
in-memory backend and by not using the tolog implementation, but still 
it is quite a heavy-weight application.

A better solution for an applet might be TinyTIM 
(http://tinytim.sourceforge.net/) integrated with TouchGraph. As TinyTIM 
implements TMAPI, you should be able to port the code you write against 
TinyTIM to TM4J's TMAPI implementation (and vice-versa).

Hope this helps!

Kal





Hi Xu=E2n,

When I tried to migrate TM4J from JDK 1.3 to 1.4, a lot of people=20
complained that they were not able to upgrade their environment to 1.4.=20
I'm not doing a lot of Java development these days, so I don't really=20
have a good feel for how widely used JDK 1.5 is.

I would be interested to hear from the other developers on this list to=20
know what their opinion is.

Best regards

Kal

Xu=E2n Baldauf wrote:
> Hello,
>=20
> I'd like to create a project which uses tm4j (and ozone). However, tm4j=
=20
> is still not converted to use Java 1.5 generics (see=20
> http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf ). Thus, I'd lik=
e=20
> to change tm4j to use Java 1.5 generics. However, after this conversion=
,=20
> using a generics-capable Java compiler (Java 1.5 javac or special Java=20
> 1.4 javac) is required to compile the changed tm4j.
>=20
> Would the current tm4j community accept such changes to the development=
=20
> tree of tm4j? (If not, I would not put work into doing these changes.)
>=20
> Regards,
>=20
> Xu=E2n Baldauf.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> that extends applications into web and mobile media. Attend the live=20
> webcast
> and join the prime developer group breaking into this new coding territ=
ory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>=20
>=20




* =E5=91=A8=E4=BA=AD
>
> Is there anybody use the Velocity to build a topic map? I'm a =20
> beginner of it
> and come across some problems.

To create the topic map, you mean? I don't think Velocity is really =20
suited for that, but in theory it is possible to produce, say, an LTM =20=

file with Velocity.

It would be easier to help if you said more about what you were doing.

--
Lars Marius Garshol, Ontopian               http://www.ontopia.net
+47 98 21 55 50                             http://www.garshol.priv.no





Hi

Has anyone started adapting the TMNav as applet to run within a browser or
as Mozilla/Firefox extension?

Thanks

Michi

-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
mic...@wy...                        mi...@ap...
+41 44 272 91 61




Hello,

I'd like to create a project which uses tm4j (and ozone). However, tm4j 
is still not converted to use Java 1.5 generics (see 
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf ). Thus, I'd like 
to change tm4j to use Java 1.5 generics. However, after this conversion, 
using a generics-capable Java compiler (Java 1.5 javac or special Java 
1.4 javac) is required to compile the changed tm4j.

Would the current tm4j community accept such changes to the development 
tree of tm4j? (If not, I would not put work into doing these changes.)

Regards,

Xuân Baldauf.




Hello,
  Is there anybody use the Velocity to build a topic map? I'm a beginner =
of it
and come across some problems.
  Best!
                                                    zhouting




Bugs item #1092125, was opened at 2004-12-28 12:40
Message generated for change (Comment added) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1092125&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Tryfon (gtryfon)
Assigned to: Nobody/Anonymous (nobody)
>Summary: TMAPI 

Initial Comment:
Hello,
I am using TM4J 0.9.8 
(I didn't find this in the Group and I selected "None")

I am having problem on working with
 http://tmapi.org/features/automerge
 http://tmapi.org/features/merge/byTopicName
 http://tmapi.org/features/readOnly
 http://tmapi.org/features/model/xtm1.0
 http://tmapi.org/features/model/xtm1.1
 http://tmapi.org/features/notation/URI

this is what I do:

       propsprops.setProperty
("http://tmapi.org/features/readOnly",
"true");
       mapFeatures.put
("http://tmapi.org/features/readOnly", Boolean.TRUE);

      TMAPITopicMapSystemImpl tmApiSystImpl = new
TMAPITopicMapSystemImpl
(providerFactory.getClass().getName(), props, mapFeatures);

        URI uri = ...
        InputStream is = uri.toURL().openStream ();
        TopicMap tm = OpenXtmSupport.readXtm (is,
uri.toString(), provider,
tmApiSystImpl);
        is.close ();


  static public TMAPITopicMapImpl readXtm (InputStream
is, String baseURI,
TopicMapProvider provider, TMAPITopicMapSystemImpl
tmApiSystImpl) throws
Exception
  {
    try
    {
      Locator baseLoc =
provider.getLocatorFactory().createLocator("URI",
baseURI);
      TopicMapSource source = new
SerializedTopicMapSource (is, baseLoc);
      TopicMap tm = provider.addTopicMap (source);
      TMAPITopicMapImpl tmImpl =
(TMAPITopicMapImpl)Wrapper.wrap (tm,
tmApiSystImpl);
      return tmImpl;
    }
    catch(LocatorFactoryException ex)
    {
      throw new RuntimeException("Could not convert
file name:  " + baseURI
+ " to a TM4J Locator.");
    }
    catch(TopicMapProviderException ex)
    {
      throw new RuntimeException("Could not parse topic
map file: ", ex);
    }
  }

also:
      tmApiSystImpl.getProperty
("http://tmapi.org/features/readOnly") gives
"true"
      tmApiSystImpl.getFeature
("http://tmapi.org/features/readOnly") gives
Boolean.TRUE

but still I don't get Exception when I change the TopicMap.
also I can't merge without TopicName (they merge
TopicNames)
(I haven't tested the rest)


Cheers
George Tryfon
(TA-KT research group)


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

>Comment By: Lars Heuer (lheuer)
Date: 2006-03-14 14:20

Message:
Logged In: YES 
user_id=399396

Fixed in CVS

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

Comment By: Lars Heuer (lheuer)
Date: 2006-02-18 18:11

Message:
Logged In: YES 
user_id=399396

As long as you use the TMAPI interfaces rather than the
concrete TMAPI implementation of TM4J, the fix here:
https://sourceforge.net/tracker/index.php?func=detail&aid=1434160&group_id=27895&atid=391879
should solve the reported problems

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

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



Bugs item #1430090, was opened at 2006-02-12 13:56
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1430090&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: TM4J 0.9.7
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Much (thmuch)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssociationImpl.getMembers inefficient?

Initial Comment:
If an association has no members, getMembers() returns a new ArrayList on each invocation. Why not return Collections.EMPTY_SET instead?

    public Collection getMembers() {
        Collection ret = m_members;
        if (ret == null) {
            return java.util.Collections.EMPTY_SET; // already immutable
        }
        return Collections.unmodifiableCollection(ret);
    }

Or, if implementations rely on a list being returned, EMPTY_LIST.


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

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



Bugs item #1430091, was opened at 2006-02-12 14:03
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1430091&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: TM4J 0.9.7
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Much (thmuch)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssociationImpl.getMembersOfRole crashes with NPE

Initial Comment:
... if the association has no members at all. A fix is easy, we just need to check m_members at the beginning of the method:

    public Collection getMembersOfRole(Topic roleSpec) {
        if (m_members == null) {
            return java.util.Collections.EMPTY_SET;  // or EMTPY_LIST?
        }
        // ...
    }


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

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



Bugs item #1430800, was opened at 2006-02-13 17:26
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1430800&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: TM4J 0.9.7
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Much (thmuch)
Assigned to: Nobody/Anonymous (nobody)
Summary: getMembersOfRole cannot search for null roleSpec

Initial Comment:
AssociationImpl.getMembersOfRole(null) crashes with a NPE instead of returning all members without a role type. A possible fix:

    public Collection getMembersOfRole(Topic roleSpec) {
        Collection ret = new ArrayList();
        Iterator it = m_members.iterator();

        if (roleSpec == null) {
            while (it.hasNext()) {
                Member m = (Member) it.next();
                Topic rs = m.getRoleSpec();
                if (rs == null) {
                    ret.add( m );
                }
            }
        }
        else {
            // old while loop
        }

        return Collections.unmodifiableCollection(ret);
    }


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

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



Bugs item #1433530, was opened at 2006-02-17 12:47
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1433530&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: Utilities
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: TopicMapCopier forgets to copy VariantName(s)

Initial Comment:
The TopicMapCopier forgets to copy the VariantNames, it
only copies the Variant(Container)s.
Additionally the TopicMapCopier creates a lot of unused
arrays (BaseName, Occurrence, Variant).

The attached patch solves the above mentioned problems.
With this patch applied the TopicMapCopier copies the
Variants incl. variant names.
Additionally the copying process is faster and uses
less memory.
The patch is against the CVS

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

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



Bugs item #1434160, was opened at 2006-02-18 15:55
Message generated for change (Settings changed) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1434160&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: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMAPI Implementation is unstable

Initial Comment:
The TMAPI implementation of TM4J is unstable. In
summary there are the following problems:

- Sometimes the wrapping of native TM4J objects to the
TMAPI interfaces is forgotten (i.e. see (now closed)
bug #1433778)
- The update of collections may be slow (i.e. the
removeSubjectIdentifier method does not not check if
the the collection is really modified but sets the
whole subject identifiers to a new value).
- Removal of objects is sometimes inefficient.
- Contains unused code
- The Wrapper cannot handle the wrapping of wrap(Object
obj) where obj is an instance of a VariantName.
- Sometimes arrays are created without the need to
create them. Sometimes the utility methods of
java.util.Collections can be used instead of handling
everything manually.

The attached patch solves the mentioned problems.
The patch is against the CVS and makes the TMAPI
implementation more stable and efficient, using less
memory.

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

Comment By: Lars Heuer (lheuer)
Date: 2006-02-18 18:07

Message:
Logged In: YES 
user_id=399396

Added a slightly modified patch that removes an unnecessary
call to "checkUpdatesAllowed" in the TopicMapSystemImpl.

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

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



Bugs item #1435978, was opened at 2006-02-21 16:37
Message generated for change (Settings changed) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1435978&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: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMAPITopicNamesIndex returns wrong get..ByType(null) result

Initial Comment:
The TopicNamesIndex returns even for 
   Collection coll = tnIdx.getTopicNamesByType(null);
an empty collection.
This is wrong because it has to return all untyped
topic names (this currently means ALL topic names
contained in the topic map).

The attached patch fixes this.

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

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



Bugs item #1435978, was opened at 2006-02-21 16:37
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=1435978&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMAPITopicNamesIndex returns wrong get..ByType(null) result

Initial Comment:
The TopicNamesIndex returns even for 
   Collection coll = tnIdx.getTopicNamesByType(null);
an empty collection.
This is wrong because it has to return all untyped
topic names (this currently means ALL topic names
contained in the topic map).

The attached patch fixes this.

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

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



Bugs item #1092125, was opened at 2004-12-28 12:40
Message generated for change (Comment added) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1092125&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
Submitted By: George Tryfon (gtryfon)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMAPI "features"

Initial Comment:
Hello,
I am using TM4J 0.9.8 
(I didn't find this in the Group and I selected "None")

I am having problem on working with
 http://tmapi.org/features/automerge
 http://tmapi.org/features/merge/byTopicName
 http://tmapi.org/features/readOnly
 http://tmapi.org/features/model/xtm1.0
 http://tmapi.org/features/model/xtm1.1
 http://tmapi.org/features/notation/URI

this is what I do:

       propsprops.setProperty
("http://tmapi.org/features/readOnly",
"true");
       mapFeatures.put
("http://tmapi.org/features/readOnly", Boolean.TRUE);

      TMAPITopicMapSystemImpl tmApiSystImpl = new
TMAPITopicMapSystemImpl
(providerFactory.getClass().getName(), props, mapFeatures);

        URI uri = ...
        InputStream is = uri.toURL().openStream ();
        TopicMap tm = OpenXtmSupport.readXtm (is,
uri.toString(), provider,
tmApiSystImpl);
        is.close ();


  static public TMAPITopicMapImpl readXtm (InputStream
is, String baseURI,
TopicMapProvider provider, TMAPITopicMapSystemImpl
tmApiSystImpl) throws
Exception
  {
    try
    {
      Locator baseLoc =
provider.getLocatorFactory().createLocator("URI",
baseURI);
      TopicMapSource source = new
SerializedTopicMapSource (is, baseLoc);
      TopicMap tm = provider.addTopicMap (source);
      TMAPITopicMapImpl tmImpl =
(TMAPITopicMapImpl)Wrapper.wrap (tm,
tmApiSystImpl);
      return tmImpl;
    }
    catch(LocatorFactoryException ex)
    {
      throw new RuntimeException("Could not convert
file name:  " + baseURI
+ " to a TM4J Locator.");
    }
    catch(TopicMapProviderException ex)
    {
      throw new RuntimeException("Could not parse topic
map file: ", ex);
    }
  }

also:
      tmApiSystImpl.getProperty
("http://tmapi.org/features/readOnly") gives
"true"
      tmApiSystImpl.getFeature
("http://tmapi.org/features/readOnly") gives
Boolean.TRUE

but still I don't get Exception when I change the TopicMap.
also I can't merge without TopicName (they merge
TopicNames)
(I haven't tested the rest)


Cheers
George Tryfon
(TA-KT research group)


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

Comment By: Lars Heuer (lheuer)
Date: 2006-02-18 18:11

Message:
Logged In: YES 
user_id=399396

As long as you use the TMAPI interfaces rather than the
concrete TMAPI implementation of TM4J, the fix here:
https://sourceforge.net/tracker/index.php?func=detail&aid=1434160&group_id=27895&atid=391879
should solve the reported problems

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

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



Bugs item #1434160, was opened at 2006-02-18 15:55
Message generated for change (Comment added) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1434160&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMAPI Implementation is unstable

Initial Comment:
The TMAPI implementation of TM4J is unstable. In
summary there are the following problems:

- Sometimes the wrapping of native TM4J objects to the
TMAPI interfaces is forgotten (i.e. see (now closed)
bug #1433778)
- The update of collections may be slow (i.e. the
removeSubjectIdentifier method does not not check if
the the collection is really modified but sets the
whole subject identifiers to a new value).
- Removal of objects is sometimes inefficient.
- Contains unused code
- The Wrapper cannot handle the wrapping of wrap(Object
obj) where obj is an instance of a VariantName.
- Sometimes arrays are created without the need to
create them. Sometimes the utility methods of
java.util.Collections can be used instead of handling
everything manually.

The attached patch solves the mentioned problems.
The patch is against the CVS and makes the TMAPI
implementation more stable and efficient, using less
memory.

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

>Comment By: Lars Heuer (lheuer)
Date: 2006-02-18 18:07

Message:
Logged In: YES 
user_id=399396

Added a slightly modified patch that removes an unnecessary
call to "checkUpdatesAllowed" in the TopicMapSystemImpl.

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

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



Bugs item #1433698, was opened at 2006-02-17 18:02
Message generated for change (Comment added) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1433698&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: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: tmapi.BaseName fetches TopicMapFactory without need

Initial Comment:
The TMAPIBaseNameImpl fecthes the TopicMapFactory in
the buildVariants method but does not use it.

The attached patch removes the TopicMapFactory import
and simplifies the getVariants() method a bit (the
buildVariants method is removed)

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

>Comment By: Lars Heuer (lheuer)
Date: 2006-02-18 15:58

Message:
Logged In: YES 
user_id=399396

See bug report and patch #1434160, that fixes this bug, too.

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

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



Bugs item #1433542, was opened at 2006-02-17 14:07
Message generated for change (Comment added) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1433542&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: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMAPI Wrapper should check for VariantName != null

Initial Comment:
The Wrapper.java checks for variant != null, but IMO it
should also check for VariantName != null.

Attached patch introduces the described behavior.

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

>Comment By: Lars Heuer (lheuer)
Date: 2006-02-18 15:57

Message:
Logged In: YES 
user_id=399396

See bug report and patch #1434160, that fixes this bug, too.

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

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



Bugs item #1433778, was opened at 2006-02-17 20:07
Message generated for change (Comment added) made by lheuer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1433778&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: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: tmapi.Variant forgets to wrap its scope

Initial Comment:
The method TMAPIVariantImpl.getScope() returns an
"unwrapped" collection of native TM4J topics.

The patch solves this problem. The topics are wrapped
to the TMAPI impl.

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

>Comment By: Lars Heuer (lheuer)
Date: 2006-02-18 15:57

Message:
Logged In: YES 
user_id=399396

See bug report and patch #1434160, that fixes this bug, too.

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

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



Bugs item #1434160, was opened at 2006-02-18 15:55
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=1434160&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Nobody/Anonymous (nobody)
Summary: TMAPI Implementation is unstable

Initial Comment:
The TMAPI implementation of TM4J is unstable. In
summary there are the following problems:

- Sometimes the wrapping of native TM4J objects to the
TMAPI interfaces is forgotten (i.e. see (now closed)
bug #1433778)
- The update of collections may be slow (i.e. the
removeSubjectIdentifier method does not not check if
the the collection is really modified but sets the
whole subject identifiers to a new value).
- Removal of objects is sometimes inefficient.
- Contains unused code
- The Wrapper cannot handle the wrapping of wrap(Object
obj) where obj is an instance of a VariantName.
- Sometimes arrays are created without the need to
create them. Sometimes the utility methods of
java.util.Collections can be used instead of handling
everything manually.

The attached patch solves the mentioned problems.
The patch is against the CVS and makes the TMAPI
implementation more stable and efficient, using less
memory.

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

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




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

tm4j-developers Mailing List for TM4J (Page 4)

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