out = tag.div(class_=""wiki-toc trac-nav"") }}} Could you please release a new version of your plugin with this option? Cheers, [[br]] Mathieu ",mtrocme Release,1312,HELP Need Exact Syntax for Allowed_Macros option,trac.tracnav,,task,normal,moschny,new,2013-04-26T19:13:16+02:00,2013-04-26T19:13:16+02:00,"I am having trouble following the instructions shown (see image below). [[Image(http://files.amkcreations.com/trac/amacros/TracNav_Usage.jpg)]] I am calling a TracNav that contains a TicketQuery macro. It will not display properly. Can you give me the correct syntax? My attempt: [ [ TracNav(ViewTickets|allowed_macros=TicketQuery) ] ] My Results are [[Image(http://files.amkcreations.com/trac/amacros/TracNav_Failed.jpg)]] TO RESTATE MY DESIRE: I am trying to get the TracNav to display the Count of each report next to the link. [[Image(http://files.amkcreations.com/trac/amacros/WishScreen.jpg)]] With your permission, I will edit the instructions so others can understand this better as well. Thanks for your time! God Bless, Arlene :)",akliewer99@… Release,190,Connections should be cleaned up asynchronously.,uka.karmi,1.09a,enhancement,normal,,new,2004-08-11T16:43:00+02:00,2005-02-02T23:17:02+01:00,"After each usage, a KaRMI connection is cleaned up and put back into a connection pool. This cleanup is done in closeReceiveResult() on the client side and in closeSendResult() on the server side. Under certain circumstances (see uka.transport.MarshalStream.symmetricReset()), this cleanup requires sending and receiving additional data. Since the cleanup phase of a connection should not be on the critical path of a remote operation, it should be handled asynchronously in a helper thread. The only requirement is that the cleanup is finished before the connection is reused. '''todo''' since 1.09a. ",Bernhard Haumacher Release,210,Gjc issue repository should be converted into tickets,gjc,1.07h,defect,normal,moschny,assigned,2005-01-31T16:23:09+01:00,2005-01-31T20:31:55+01:00,"The gjc compiler had its own issue repository, which was not maintained for a long time until revived in the checkpointing branch. The entries (at least the active ones) should be converted to trac tickets. See: source:branches/checkpointing/gj/doc/fixes.txt ",hauma 2.0 Release,240,Arrays of anonymous objects are always handled embedded. ,uka.transport,1.09c,defect,normal,hauma,new,2005-03-09T23:54:37+01:00,2005-04-03T14:29:21+02:00,"This is a workaround for the problematic ticket:232. The embedded annotation cannot be used within KaRMI source files, but it is required to generate correct marshaling code e.g. for ReplicaStub.",hauma 2.0 Release,186,Instances of replicated classes are not assignable to jp.lang.ReplicatedObject,jpc,1.09a,defect,critical,hauma,assigned,2004-08-11T16:43:00+02:00,2005-02-03T17:24:14+01:00,"Transparent replicated classes (see ticket:158) are marked with the {{{replicated}}} modifier. The implicit root class of all replicated classes is {{{jp.lang.ReplicatedObject}}} (like {{{jp.lang.RemoteObject}}} is the implicit root class of all remote classes). But the types defined by replicated classes are not assignment compatible with jp.lang.ReplicatedObject. === Test === {{{ jp.test.TestReplication with uncommented test case fooCast(). }}} '''todo''' since 1.09a. ",Bernhard Haumacher (haui at haumacher dot de) 2.0 Release,213,Optimized collective updates,uka.karo,1.08a,defect,critical,boh,new,2005-02-04T17:43:19+01:00,2010-07-26T13:22:06+02:00,"A collective update on a replicated object that does not employ PartialReplication corresponds to an all-to-all operation in MPI, because each replica must communicate its changes to each other replica. But if a replicated object is partially replicated, changes to one replica are only relevant for a small subset of all replicas. This fact should be used to optimize collective updates for partially replicated objects. ",hauma 2.0 Release,214,Separate compilation does not work with transparent replicated objects,jpc,1.09a,defect,critical,hauma,new,2005-02-07T13:24:11+01:00,2005-02-09T22:38:40+01:00,"If compiling the follwing two class files at once, everything works fine. When compiling first {{{A.java}}} and then {{{B.java}}}, the compiler complains about {{{B.java:6: variable x not found in class A}}} during the compilation of {{{B.java}}}. A.java: {{{ #!java replicated class A { static int x; } }}} B.java: {{{ #!java class B { static { A.x = 13; } } }}} ",hauma 2.0 Release,137,Pseudo class variable as argument to synchronized blocks,JP trafo,1.06c,defect,major,hauma,new,2002-08-12T18:54:22+02:00,2005-02-21T08:26:39+01:00,"Compiler crashes if it encounters an access to the pseudo {{{.class}}} variable of a remote class as argument to a synchronized block. === Problem === R.class is translated to ""this.class"" in the context of a synchonized block argument. This is nonsense. === Evaluation === The same difficulty exists for replicated classes (see ticket:157). === Test === {{{ jp.test.TestClassVariable }}} '''todo''' since 1.06c. ",Bernhard Haumacher (haui at haumacher dot de) 2.0 Release,167,Final variables in replicated objects,uka.karo,1.08a,defect,major,,new,2004-03-25T11:13:14+01:00,2005-02-03T17:26:02+01:00,"Final instance variables never change after the object is constructed. This property is used in replicated objects. Final variables are simply excluded from the update process. This would be fine, if those variables were initialized on all replicas in a consistent manner. But this is not the case, because after construction only the primary replica is initialized. All secondary replicas are allocated uninitialized and wait for an update. Since final variables are excluded from the update process, their state stays inconsistent even after the first update. === Evaluation === Final variables cannot be updated during the regular update process, because assignments to them are only allowed within their constructor. === Evaluation === Secondary replicas are created uninitialized, because the constructor in the replicated root class (ReplicatedObject) triggers the creation of the secondary replicas. At this time, the primary replica is not yet completely initialized. The problem could be fixed by delaying the creation of the secondary replicas to the time the construction of the primary replica has completed. '''todo''' since 1.08a. ",Bernhard Haumacher (haui at haumacher dot de) 2.0 Release,211,"Wrong transformation (or insufficient error checking) for collective, exclusive, and shared synchronization",jpc,1.09b,defect,minor,hauma,new,2005-02-03T15:36:29+01:00,2005-02-03T15:37:34+01:00,"Assume, one has ""forgotten"" the {{{replicated}}} modifier in the following class definition (Even with the replicated modifier, this program is nonsense, because there is only one thread performing a collective synchronization on the replicated class. Therefore, this program should hang unless executed in a distributed environment with only one virtual machine.): {{{ #!java import jp.lang.DistributedRuntime; class A { static int[] x = new int[DistributedRuntime.getMachineCnt()]; public static void main(String[] args) { int rank = DistributedRuntime.getMachineID(); collective synchronized (A.class) { x[rank] = rank; } } } }}} This program is ""illegal"", because there is an attributed (collective) synchronization on a class object that does not represent a replicated class. This mistake should either be detected at compile time, or the program should compile silently, but throw an exception at runtime. Instead, the compiler accepts the program, starts the transformation, produces an illegal transformation result, and '''then''' prints an error message containing details about the (wrong) transformation. The error message is: {{{ A.java:11: method __collectiveUpdate() not found in class java.lang.Class }}} ",hauma 2.0 Release,177,Collective exchange,uka.karo,1.08a,enhancement,normal,,new,2004-03-25T11:13:14+01:00,2005-02-03T17:25:40+01:00,"The only collective operation introduced in ticket:157 was the collective update. This operation consists of an exchange of concurrent modifications done to a replicated object. In addition to that, an application may need a more basic form of data exchange, without modifying the state of the replicated object. In general, cooperating threads might want to use all collective operations for pure data exchange known from MPI: barrier, broadcast, (all-)scatter, (all-)gather, all-to-all. Even the combined communication/computation operations (all-)reduce, and scan are conceivable. === Evaluation === Implementing all flavors of MPI-style collective communications is to time consuming. As prove of concept, the most powerful ""all-to-all"" communication should be implemented. === Solution === A collectively replicated object serves as context for a collective data exchange. Therefore, the base class of replicated objects provides a set of collective methods that are inherited by subclasses. The all-to-all communication is implemented in the {{{Object[] exchange(Object[])}}} method. The caller must provide a list of arguments, one for each rank of the replicated object. The method returns a list of results, one from each rank (data from rank {{{r}}} is stored at index {{{r}}} in the result list). The object at position {{{caller-rank}}} is copied from the argument list to the corresponding index within the result list. === Problem === The semantic of the exchange operation is problematic. See ticket:180 for details. '''todo''' since 1.08a. ",Bernhard Haumacher (haui at haumacher dot de) 2.0 Release,179,Merge annotations for collective replicated objects,JP trafo,1.08a,enhancement,normal,,new,2004-03-25T11:13:14+01:00,2005-02-07T17:34:13+01:00,"Collective replicated objects as introduced in ticket:157 require the modified state of a replicated object to be strictly partitioned among the cooperating threads. This restriction is to limiting for most applications. Concurrent modifications during collective operations should be allowed, if a merge strategy is provided that specifies how to merge modifications done to the same state on different nodes into a consistent view. === Solution: Application-provided differencing methods === Instead of relying on the automatically generated methods for object differencing and merging, the application could provide tailored methods that extract a difference in a way that is suited for being applied non-destructively to another also modified copy. E.g., if a variable of type {{{int}}} is modified additively, instead of marshaling the current (modified) state, the difference to its former state could be marshaled. At the receiving side, this difference could be added to both, the current value and its former value. This merges the modification by another thread into an existing local modification at the receiving side (without overriding the local modification). Of cause, subtracting the backup copy form the current value to represent the modification is not generally valid: Both modifying thread could have multiplied the value with some factor. Merging these modifications additively would result in undesired effects. Therefore, the merging strategy must be application provided. === Evaluation: Application-provided differencing methods === Replacing the whole automatically generated methods with user-defined ones is not the best solution: In those methods details about the differencing and merging process are revealed. Hand-coding those methods is both tedious and error-prone. === Solution: Merge annotations === An instance variable of a replicated class, or a whole replicated class could be annotated with another class that provides the functionality for differencing and merging. === Cave === In combination with the handling of updates to locally dead objects according to ticket:207, the code that was generated for merging updates into the local state was broken (see ticket:181). '''todo''' since 1.08a. ",Bernhard Haumacher (haui at haumacher dot de) 2.0 Release,180,Semantics of collective exchange operations,uka.karo,1.08b,defect,normal,,reopened,2004-03-25T11:13:14+01:00,2005-02-08T23:14:35+01:00,"The collective exchange (see ticket:177) was originally designed as pure data exchange (without touching the replicated state of the corresponding replicas). But two things might happen: * The exchanged data may reference parts of the replicated state (by incident). * The application might use the exchange operation to actively ""migrate"" parts of the replicated state from on rank to another by means of an exchange. To deal with both cases, during the exchange, data that is unrelated to the replicated object is passed by value as in a regular remote method invocation, while data that was '''already''' part of the replicated object is passed ''by reference'' (by transmitting the corresponding object identifiers and resolving them on the target node to the already existing copy of the object). This approach causes two semantic problems: * Exchanging references to replicated data may behave unexpected, because the exchanged data can differ on the sending and receiving side, if the replicated state is currently inconsistent (e.g. in the middle of a collective update operation). The effect is similar when passing a volatile reference from one thread to another, without ensuring that the receiver will see fresh values upon dereferencing. * Since an exchange operation is meant for exchanging data that is not directly related to the state of a replicated object, it is acceptable that the argument passing semantics depends on the fact, whether a referenced object is part of the replicated graph, or not. But within a temporarily inconsistent replicated object, it is not clear, which object currently belongs to the replicated state and which does not. E.g., an object that is just entered to the replicated graph in a running collective update is at the one hand already referenced form the graph, but not yet registered, because it was not yet detected by an update. Such object would be passed by value, instead of by reference. This will result in unexpected behavior. === Solution: Update before exchange === Both problems described above can be solved by preventing an exchange operation on a temporarily inconsistent replicated object. If the replicated object is in a consistent state, all ranks have a consistent view to all shared objects. Then, there does not exist a newly created object that is not yet registered at the replicated graph. The only way of preventing an exchange within an inconsistent replicated object is to perform an update before the exchange operation. === Evaluation: Non-shared objects are not registered === For performance reasons, objects that are not shared between ranks of a replicated object are not registered. If such object takes part in an exchange operation it will be passed by value regardless whether the replicated object is in a consistent state, or not. This limits the exchange operation to shared objects. An exchange may therefore not be used to share an otherwise unshared object. It depends on the application, whether this restricts the usability of the exchange operation. Ensuring that all referenced objects (shared and non-shared) are registered requires traversal of the whole replicated graph during each update and will result in prohibitive cost. ",Bernhard Haumacher (haui at haumacher dot de) 2.0 Release,215,NaN values in replicated state produce continuous updates,uka.karo,1.08a,defect,normal,hauma,new,2005-02-08T10:20:26+01:00,2005-02-08T10:27:08+01:00,"The update mechanism used in CollectiveReplication only marshals updates form one replica to another, only if the actual value in one replica has changed. This test uses the built-in (==) operator for all primitive types. Since {{{Double.NaN != Double.NaN}}}, this test detects always an update for replicated {{{float}}} and {{{double}}} values that are {{{NaN}}}. A side effect of this behavior is that {{{NaN}}} values are likely to dominate changes to replicas of such {{{double}}} or {{{float}}} variables. After some has set a variable to {{{NaN}}}, it is hard to override this in a collective update, because each rank generates an update for its {{{NaN}}} value. ",hauma 2.0 Release,217,Broken transparent replicated class transformation (access to static parts of a replicated class),jpc,1.09a,defect,normal,hauma,new,2005-02-08T15:40:24+01:00,2005-03-12T18:34:36+01:00,"Crashes the compiler where it should not: {{{ replicated class A { static int x = 10; static int y = x; } }}}",hauma 2.0 Release,218,Broken transparent replicated class transformation (initializer of instance variable),jpc,1.09a,defect,normal,hauma,new,2005-02-08T15:55:04+01:00,2005-02-08T15:55:04+01:00,"The compiler does reject the following code, where it should not: {{{ replicated class A { static int x = 10; int y = x; } }}} It makes the following excuses: {{{ A.java:52: variable x not found in class A int y = x; ^ 1 errors }}} ",hauma 2.0 Release,219,Missing backup copies for objects transmitted in a CollectiveExchange,uka.karo,1.09b,defect,normal,hauma,new,2005-02-09T10:31:13+01:00,2005-02-09T10:31:13+01:00,"Refactoring the order of backup creation and reference filtering in [2528] broke CollectiveExchange. Backup copies are now created immediately after creating a patch (directly within the method {{{PatchAdapterImpl.Output.createPatch()}}}). The exchange is done after creating patches to bring the replicated state up to date. If a shared object is transmitted during the exchange operation to a rank, where previously no copy existed, no backup copy is created for that object. ",hauma 2.0 Release,222,Optimized collective updates require frozen objects ,uka.karo,1.09b,defect,normal,hauma,new,2005-02-16T12:23:31+01:00,2005-02-16T12:23:31+01:00,"The replicated root object is present at each rank of a replicated object. Since this could have been modified during a collective update, the underlying communication is always potentially all-to-all. To optimize collective updates effectively according to ticket:213, there must be the possibility to ""freeze"" at some point in time after construction. A frozen object must no longer be modified and is excluded from updates.",hauma 2.0 Release,223,Difficulties defrosting objects,uka.karo,1.09b,defect,normal,hauma,new,2005-02-16T12:30:37+01:00,2005-02-16T12:30:37+01:00,"An object can be frozen during a collective or exclusive synchronization according to ticket:222. Since frozen objects are excluded from updates, collective updates can be optimized according to ticket:213. Unfortunately, defrosting an object is an operation that modifies the state of the replicated object on all machines holding a copy of the frozen object. Therefore, an optimized collective update cannot be used to bring a replicated object with defrosted objects up-to-date. Defrosting must either be restricted to exclusive updates, or a special collective operation must be introduced for object defrosting.",hauma 2.0 Release,228,Anonymous objects should replace value mode marshaling (non-recursive),uka.transport,1.08a,defect,normal,hauma,new,2005-02-24T14:55:46+01:00,2011-05-30T21:50:23+02:00,"The {{{uka.transport}}} marshaling does support value mode marshaling. For objects marshaled in value mode, no cycle resolution is performed. This prevent such (temporary) objects from being inserted into the streams object spaces, which is especially important in the context of replicated objects to keep the set of objects watched for modifications small. All objects marked with {{{uka.lang.Immutable}}} (and all objects transitively referenced from those objects) were transmitted in value mode. This is problematic, because there are classes that should be transmitted in value mode without extending the value mode to referenced objects. A new marker {{{uka.lang.Anonymous}}} (see [2833], [2834]) was introduced that guarantees (non-recursively) equivalence of objects and copies. {{{uka.transport}}} should respect this annotation and transmit anonymous objects without inserting them into the stream's object spaces. ",hauma 2.0 Release,231,Embedded objects,uka.transport,1.09b,defect,normal,hauma,new,2005-02-25T07:45:31+01:00,2005-02-25T07:45:31+01:00,"When value mode marshaling is replaced with anonymous objects (see ticket:228), a possibility is required build complex anonymous objects that internally consist of multiple helper objects e.g. arrays (which in turn cannot be declared anonymous, because their class is not extendable). To prevent references to those helper objects from being marshaled ""by reference"", they should be declarable as being embedded into its owner object. In the following example, an anonymous class {{{A}}} internaly consists of an array of references to other objects stored in an array {{{A.r}}}. As well as the refernce to {{{A}}} as the reference to the internal helper array {{{A.r}}} should be marshaled in value mode. Only for the containing references {{{A.r[n]}}}, regular marshaling should apply: {{{ #!java class A implements Anonymous { /** @embedded */ Object[] r = new Object[10]; } }}} The {{{@embedded}}} anotation marks the refereced Object {{{A.r}}} as being anonymous in the context of {{{A}}}. This annotation is not restricted to variables of anonymous classes. Also helper objects of regular classes can be embedded (declared anonymous in the context of their owner). By declaring an object embedded, a class guarantees that the embedded reference is the '''only reference''' to the embedded object (an that this reference '''cannot be {{{null}}}'''). With this guarantee, it should be possible for a JIT compliler to inline the embedded object.",hauma 2.0 Release,233,"Add a ""-local"" mode to jpc where it does not depend on the availability of JP runtime classes",jpc,1.09b,defect,normal,hauma,new,2005-02-25T08:06:51+01:00,2005-02-25T16:51:18+01:00,"To be able to compile KaRMI with {{{jpc}}} (see ticket:232), the JavaParty compiler must work without the JP runtime being available (because this requires KaRMI to be built first). A new option should be added to the compiler, where it does ""local"" compilation with only generating marshaling methods, but without transforming remote classes. ",hauma 2.0 Release,237,Transport code generation failure for classes without default super constructor,jpc,1.09c,defect,normal,hauma,new,2005-03-08T19:35:03+01:00,2005-03-08T19:35:03+01:00,"Wrong transport code is generated, when jpc tries to retrofit a serializable class that does extend a non-serializable class, which has no default constructor. When compiling the following example (with the -local option to prevent transport code generation for '''all''' classes (see: ticket:233)), jpc crashes with ""errors in generated code"": {{{ class A { private int x; A(int x) { this.x = x; } } class B extends A implements java.io.Serializable { int y; B(int x, int y) { super(x); this.y = y; } } }}} In such situation, no transport code should be generated at all, because it is impossible to generate transport code for {{{B}}} that marshals the complete state including the private instance variable {{{x}}} of superclass {{{A}}}. ",hauma 2.0 Release,238,Application startup fails in JavaParty for RMI,JP environment,1.07i,defect,normal,hauma,reopened,2005-03-09T15:10:10+01:00,2005-04-01T12:17:36+02:00,"When using the RMI compatibility version of JavaParty, application startup randomly fails with the following error: {{{ invoking main() method failed: java.lang.reflect.InvocationTargetException. caused by: java.rmi.NoSuchObjectException: no such object in table java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0() at sun.reflect.NativeMethodAccessorImpl.invoke() at sun.reflect.DelegatingMethodAccessorImpl.invoke() at java.lang.reflect.Method.invoke() at jp.lang.JavaParty.invokeMain() at jp.lang.JavaParty.mainExec() at jp.lang.JavaParty.main() Caused by: jp.lang.RemoteError: method BenchMethodRemote.getClassNode() at jp.bench.BenchMethodRemote.getClassNode() at jp.bench.BenchMethodCalls.main() ... 7 more Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer() at sun.rmi.transport.StreamRemoteCall.executeCall() at sun.rmi.server.UnicastRef.invoke() at jp.bench.BenchMethodRemote_class_impl_Stub.getClassNode() at jp.bench.BenchMethodRemote.getClassNode() ... 8 more }}} The exception looks like RMI allows to garbage collect some remote object prematurely. Such exception should normally no be observable by an application. Is this a bug in RMI? ",hauma 2.0 Release,242,KaRMI GM technology hangs under heavy traffic,uka.gm,1.07i,defect,normal,hauma,new,2005-03-22T16:41:11+01:00,2005-03-22T16:41:11+01:00,"Under heavy traffic (especially during replicated object updates) a vitual machine locks up in the native method gmReceive(). The effect is reproducible with {{{jp.bench.BenchReplication -none -frozen}}}. ",hauma 2.0 Release,300,"Add option for inline vs pullout display, like the PageOutline macro",trac.tracnav,1.05e,enhancement,normal,moschny,new,2010-02-11T23:33:55+01:00,2013-05-26T07:23:23+02:00,"It would be a nice enhancement to allow content to be displayed inline, for use on e.g. the main page of a Trac site, like the `PageOutline` macro does. {{{ [[PageOutline(2-5, Page Outline, inline)]] }}}",ryano@… 2.0 Release,209,Duplicate transformation results for replicated classes,jpc,1.09b,defect,trivial,hauma,new,2005-01-31T13:19:30+01:00,2005-02-02T23:18:11+01:00,"Replicated classes are transformed twice. The first time, the {{{replicated}}} modifier is transformed away, and the second time, usages of remote classes within method bodies of replicated classes are transformed. Both transformation phases produce source code, which is saved. Since writing transformation results does not overwrite files (for safety reasons), the compiler always issues warning messages, when compiling replicated classes. Saving the transformation result directly after the replicated class transformation step is required for debugging the transformation. See issue [2561]. ",hauma 2.1 Release,208,Redistribution of partially replicated graphs,uka.karo,1.08a,enhancement,normal,,new,2004-03-25T11:13:14+01:00,2005-03-12T18:30:39+01:00,"With partial replication (see ticket:171), the application may want to change the distribution of single objects or reorganize the distribution of a whole replicated object graph. '''todo''' since 1.08a. ",Bernhard Haumacher (haui at haumacher dot de) JPlater Release,184,Generation of marshaling routines does not respect user-provided implementations,uka.transport,1.08b,defect,major,,new,2004-03-25T11:13:14+01:00,2005-03-12T18:40:05+01:00,"The JavaParty compiler declares classes transportable and generates appropriate implementations of marshaling methods. Unfortunately, it does not respect user-provided implementations of the Transportable interface. Instead it generates duplicate methods and crashes when compiling generated sources. === Test === {{{ jp.test.TestStringTransport_SendPackage }}} === Evaluation === There should be a possibility to specify user-defined marshaling routines in a more abstract way that is suitable for java.io serialization '''and''' uka.transport mashaling. These user-defined methods should only use the general interfaces java.io.Object{In|Out}put instead of the concrete implementations java.io.Object{In|Out}putStream and uka.transport.{Unm|M}arshalStream.",Bernhard Haumacher (haui at haumacher dot de) JPlater Release,189,A CallHandler is unnecessarily associated with each connection.,uka.karmi,1.09a,defect,normal,,new,2004-08-11T16:43:00+02:00,2005-03-12T18:36:37+01:00,"Each connection in KaRMI is a call handler. This is not useful for each kind of connection (e.g. the connections used in the replicated wait process or the collective or exclusive update operations on replicated objects). The calls {{{StreamClientConnection.openSendCall()}}} and {{{StreamClientConnection.closeReceiveResult()}}} register and unregister their corresponding call handler, if the connection's command identifier is {{{APP_CALL}}}. The registration of a call handler marks it responsible for handling incoming calls for the current distributed thread. Multiple registrations of call handlers for the same thread identifier build up a stack of call handlers that models the distributed stack of the current distributed thread. During unregistering a call handler, the top of this stack is removed. Obviously, the call handler registration is unnecessary for special remote operations that cannot cause a recursive call back. If call handlers are not unregistered in exactly the reverse order of their registration, the distributed stack gets completely confused. === Workaround === If a thread opens more then one connection in {{{APP_CALL}}} mode, it has to close them in reverse order. === Solution === A new sort of connections is required that are not associated with a call handler. Or at least a new command identifier should be introduced that causes the remote operation to be executed in the local representative thread (like {{{APP_CALL}}}), but does not require a call handler registration, because no recursive call is possible. The new command identifier could be called {{{APP_CALL_NR}}} for non-recursive application calls. '''todo''' since 1.09a. ","Bjoern-Oliver Hartmann, Bernhard Haumacher" JPlater Release,229,Support wildcard type parameters in GJ.,gjc,1.07i,defect,normal,moschny,assigned,2005-02-24T20:15:15+01:00,2010-10-03T12:17:17+02:00,"GJ doesn't support bound and unbound wildcard type parameters such as {{{}}}, {{{}}} and {{{}}} at all. This inhibits the usage of GJ and thus of JavaParty in a Java5 environment, because some of the library classes make use of those wildcard type params. ",moschny JPlater Release,232,KaRMI should be compilable with jpc for automatic generation of marshaling routines,uka.transport,1.09b,defect,normal,hauma,new,2005-02-25T08:01:34+01:00,2005-03-12T18:38:55+01:00,"Currently, KaRMI with uka.transport is compiled in three phases. It is first compiled with javac. This requires to replace all declarations of the {{{Transportable}}} interface with {{{java.io.Serializable}}}. The resulting class files are read with the ""transportc"" retrofitting tool that generates code snippets with implementations of the marshaling methods, which are included into the original source code. In a third phase, the enriched source files are recompiled with javac to produce the transportable class files. The procedure described above doese not work for classes with marshaling annotations as described in ticket:179 and ticket:231, because they are not understood by javac and therefore not included into the resulting class files. Even if this could be improved with Java 5 meta data annotations, a preliminary solution is to directly use {{{jpc}}} to translate the KaRMI classes which should become transportable. This is necessary, because some of the KaRMI classes depend on the annotations. ",hauma JPlater Release,236,Remove the interface uka.transport.Transportable,uka.transport,1.09c,defect,normal,hauma,new,2005-02-28T15:56:25+01:00,2005-03-12T18:37:47+01:00,"The property of being transportable is determined at runtime by checking the availability of a static field {{{TRANSPORT_DESCRIPTOR}}} in the class. This makes the interface {{{Transportable}}} superfluous. Since, it is not safely possible to automatically promote each serializable class to transportable ones. If the class implements its own marshaling protocol using writeObject() methods, it may be difficult to convert those methods into marshaling methods valid for uka.transport. The property of being transportable is not in all cases inherited to subclasses. Since a subclass of a serializable class that was promoted to a transportable class could declare custom marshaling methods, the subclass can no longer be promoted to a transportable class. ",hauma JPlater Release,243,"Collective replication over GM requires ""server-less"" connections",uka.gm,1.09c,defect,normal,hauma,new,2005-03-24T14:53:37+01:00,2005-03-24T14:53:37+01:00,"In particular collective updates (see: ticket:157) are much slower when using KaRMI/GM instead of KaRMI/Ethernet. The reason seems to be that collective operations involve lots of (server-) threads for accumulating the required connections. Currently, a collective operation is mapped to multiple connections that normally serve as transport for remote method invocations. Each such connection is associated on one end with a server thread that is either responsible for executing the remote method invocation, or for forwarding the call to a waiting segment of a transparent distributed thread (see ticket:140). The problem could be mitigated by introducing a second connection abstraction in KaRMI that is not automatically associated with a server thread. Such server-less connection can only be used, if two threads on both ends agree on a collective operation. ",hauma JPlater Release,244,"Access restrictions for ""const"" variables are too tight",JP trafo,1.07i,defect,normal,hauma,new,2005-03-30T17:53:51+02:00,2005-03-30T17:53:51+02:00,"In ticket:118, replicated static constants of remote classes were introduced. To enable constants of array type, the unused ""const"" modifier was re-introduced to declare the whole (multi-dimensional) array to be constant. Access to arrays declared ""const"" is restricted to ensure that their values cannot be modified outside the static initializer. These restrictions completely forbid creating alias references to const arrays. This restriction is too tight. Instead, the const modifier should be usable for local variables as well. Aliasing a constant static array as local const variable is OK, since the compiler can track the further usage of such local variables and prevent modifications of them. ",hauma JPlater Release,245,Embedded references have to be final,JP trafo,1.09b,defect,normal,hauma,new,2005-04-03T14:28:48+02:00,2005-04-03T14:28:48+02:00,"There is no way to detect the modification of an embedded reference (in the context of transparent replicated objects, see ticket:158), because the referenced object does not have an assigned identifier and the reference in the original and the copy point to different objects by default. The property of being final should be enforced by the compiler. ",hauma JPlater Release,254,Compatibility JavaParty with JDK 1.5,gjc,,defect,normal,moschny,assigned,2006-02-24T16:14:27+01:00,2006-03-23T10:51:20+01:00,"Hello, i'am developping a middelware in order to perform javaparty's migration and perform the load of JVM and machines. The problem that i find is the compatibility of javaparty with JDK 1.5. So, i can compile and run with 1.4 but with the 1.5 i can't compile any file. Can you help me please or give me some informations wich can help me. TRhanks",ali_bou59@… JPlater Release,306,Redirect to Wiki Pages containing underscore doesn't work,trac.redirect,1.02,defect,normal,moschny,new,2011-01-01T21:49:08+01:00,2013-05-05T19:18:18+02:00,"[[redirect(wiki:__)]] doesn't work, although the wiki page '__' does exist. ",anonymous