Recent changes to bugs

Static path to log4j.xml in org.aglets.log.AgletsLogger

Anonymous — Thu, 08 Dec 2011 15:18:44 -0000

In-class initializer in AgletsLogger points to log4j.xml path as {aglets.home}/cnf/log4j.xml

If one would want to move this file somewhere else, one would get FileNotFound exception every time Tahiti started.

I propose to change line 49:
DOMConfigurator.configure(agletsHome);
to
DOMConfigurator.configure(System.getProperty("log4j.configuration", agletsHome));

This allows to set location of log4j file using standard log4j property and still falls back to default in case no property is given.

Slash proliferation in policy file

Thomas Herlea — Thu, 22 Mar 2007 22:30:23 -0000

When using Tahiti's interface to edit permissions, the number of slashes in the URL of the codeBase being saved increases at each saving.

problem with CLASSPATH

Anonymous — Wed, 25 May 2005 17:38:29 -0000

Hello Everyone,

I got to know that the classes which come under the
CLASSPATH variable cannot be exported.ie they are not
mobile.
but i want a class in my CLASSPATH to be mobile. so,
can anyone tell me how to make a class that is in the
CLASSPATH mobile. Is there any variable that can be
set to relax that restriction. I know that it is for security
reason that
the classes in the CLASSPATH are not mobile. but still
i want it in my project. So,please send a solution to
mmy problem. I'll be grateful to you if anyone tell me the
solution to this problem.

Heres my Email-ID : yadavsandee@rediffmail.com

problem between two Linux machines

Anonymous — Tue, 11 Mar 2003 13:29:37 -0000

I've got the aglets-2.0.1
I've got the java runtime environment j2sdk1.4.1

I've one Linux red hat 7.0 Guinness, Kernel 2.2.16-3smp
on a 2-processor i686 -> machine A

I've one Linux red hat 7.0 Guinness, Kernel 2.2.16-22 on
an i686 -> machine B

when I dispatch one agent from A to B, i've the following
errors :

on machine A :

code = 400
com.ibm.maf.MAFExtendedException: INTERNAL
ERROR
at
com.ibm.maf.atp.MAFAgentSystem_ATPClient.receive_
agent0(Unknown Source)
at
com.ibm.maf.atp.MAFAgentSystem_ATPClient.access$
000(Unknown Source)
at
com.ibm.maf.atp.MAFAgentSystem_ATPClient$1.run
(Unknown Source)
at java.security.AccessController.doPrivileged
(Native Method)
at
com.ibm.maf.atp.MAFAgentSystem_ATPClient.receive_
agent(Unknown Source)
at com.ibm.aglets.LocalAgletRef.dispatch
(Unknown Source)
at com.ibm.aglets.SystemMessage.handle
(Unknown Source)
at com.ibm.aglets.AgletThread.run(Unknown
Source)
com.ibm.aglet.RequestRefusedException: atp://jade,
Integrity=DIGEST, Confidentiality=SHORTSECRETKEY,
Timeout=0 examples.simple.DisplayAglet
at com.ibm.aglets.LocalAgletRef.dispatch
(Unknown Source)
at com.ibm.aglets.SystemMessage.handle
(Unknown Source)
at com.ibm.aglets.AgletThread.run(Unknown
Source)

on machine B :

java.lang.NullPointerException
at com.ibm.aglets.tahiti.Tahiti.agletArrived
(Unknown Source)
at com.ibm.aglets.AgletContextImpl.postEvent0
(Unknown Source)
at com.ibm.aglets.AgletContextImpl.postEvent
(Unknown Source)
at com.ibm.aglets.LocalAgletRef.startArrivedAglet
(Unknown Source)
at com.ibm.aglets.AgletContextImpl.receiveAglet
(Unknown Source)
at
com.ibm.aglets.MAFAgentSystem_AgletsImpl$2.run
(Unknown Source)
at java.security.AccessController.doPrivileged
(Native Method)
at
com.ibm.aglets.MAFAgentSystem_AgletsImpl.receive_a
gent(Unknown Source)
at
com.ibm.maf.atp.ConnectionHandler.handleDispatchReq
uest(Unknown Source)
at
com.ibm.maf.atp.ConnectionHandler.handleRequest
(Unknown Source)
at com.ibm.maf.atp.ConnectionHandler.handle
(Unknown Source)
at com.ibm.maf.atp.ConnectionHandler.run
(Unknown Source)

Is someone knows what is happened to me please ?

bug no:491627

Anonymous — Sat, 08 Mar 2003 07:30:11 -0000

hi,
i have downloaded aglets 2.0.1. but read me file
shows bug with no: 491627. please help me how can i
get rid of this problem.

Changes:
Ver. 2.0.1

Bug: Description: Contributer:
---------------------------------------------------------------------
#491627 Selection of keystore provider Andreas
Pashalidis
Solaris text color Alexander Hoole
Message failure with deactived aglet Robert
Bergstrom

Policy file parser error and MORE...

Andreas Pashalidis — Wed, 20 Feb 2002 15:32:29 -0000

The aglet's policy file parser
(com.ibm.aglets.security.PolicyFileReader) does not
interpret the 'keystore' directive. Instead, it throws
an exception.

Furthermore (and more significant) the Aglets
Framework does not seem to support code authentication
based on signed jar files, DESPITE WHAT IS WRITTEN in
the aglets book, page 185, and at
http://www.trl.ibm.com/aglets/relnotes11b1.html

The framework simply IGNORES the 'signedBy' directive
(although the PolicyFileReader parses it), granting
persmissions to unsigned code.

I don't know if it is a bug in the AgletClassLoader
(which extends ClassLoader, NOT SecureClassLoader or
URLClassLoader) or the JarAgletClassLoader, or in the
Policy implementation.

As it is obvious from AgletRunTime, the keystore used
for user authentication is (unless otherwise
specified) ${user.home}/.keystore.

bugfix: keystore problem in aglets-2.0b0

Andreas Pashalidis — Tue, 11 Dec 2001 16:45:01 -0000

if someone uses a keystore other than the default
keystore (which is of type 'jks') an exception is
thrown when trying to initialize the Aglet runtime.
(= when trying to start Tahiti, or any custom aglet
context).

the bug is in com.ibm.aglets.AgletRuntime.java

I fixed the bug changing line 754 from

_keyStore = KeyStore.getInstance("jks");

_keyStore = KeyStore.getInstance
(KeyStore.getDefaultType());

Now the aglets framework can work with any type
of keystore (including "jceks")

(provided of course that the security provider for
the keystore type has been configured in the
java.security file)

Andreas Pashalidis

http://www.come.to/xrtc

getAgletProxy(agletID) + Finder problem

David Rennalls — Thu, 19 Apr 2001 00:23:06 -0000

I have found that although Aglets were listed in
the "finder_viewer" confirming that they were
registered, a call to getAgletProxy( agletId ) always
results in an EntryNotFound exception, whenever the
Aglet being looked is in another context. I finally
tracked down the cause of the problem today, I could
be wrong but it seems to be a bug in the Aglets source
code. I'm using Aglets 1.2 (from Kovey's page) and JDK
1.3 for the development. Here's what seems to be the
bug.

the createAglet() from
com.ibm.aglets.AgletContextImpl...
public AgletProxy createAglet(URL url, String
classname, Object init)
throws IOException,
AgletException, ClassNotFoundException,

InstantiationException {
Certificate owner =
AgletRuntime.getCurrentCertificate();

return createAglet(url, classname,
owner, init);
}

the last call to another createAglet method uses the
certificate later on as follows
...
LocalAgletRef ref = new
LocalAgletRef(this, _secure);
ref.setName
(AgletRuntime.newName(owner));
...
...
The finder0 seems to be called everytime an event
occurs (creation, cloning, disposal etc..)
in this method the following is done for creation,
cloning and arrival
...
finder.register_agent(ref.getName(),
_hostingURL.toString(),
MAF.toAgentProfile
(ref.info));
...
So the certificate is used to create a Name object
(com.ibm.maf.Name), and this Name object is used when
registering the newly created Aglet with the Finder.
Name class has the following instance variables.
...
public byte[] authority;
public byte[] identity;
public short agent_system_type
...
However in the getAgletProxy(AgletID) code, when the
aglet isn't found in the local context the finder is
used, by the following code:
...
public AgletProxy getAgletProxy(AgletID aid) {
AgletProxy p = (AgletProxy)_agletProxies.get
(aid);

if (p != null) {
return p;
}
try {
MAFFinder finder =

MAFAgentSystem.getLocalMAFAgentSystem
().get_MAFFinder();

if (finder != null) {
String[] locations =
------> finder.lookup_agent(MAFUtil.toName
(aid, null), null);
p = getAgletProxy(new URL
(locations[0]), aid);
}
....

The line noted is where a Name object is created by
MAFUtil.toName() and used for the lookup_agent() call.
However the second parameter to MAFUtil.toName() is a
certificate and null is supplied, so the Name object
created has an empty authority field. So the
finder.lookup_agent() call will never find a matching
Name object for calls to getAgletProxy( id) where id
is that of a remote Aglet will never work, as all
fields of the Name object are checked in it's equals()
method.

Ticket scheme case sensitive

Robert Bergstrom — Tue, 27 Feb 2001 21:55:09 -0000

Thanks to Marc Mosko.

While playing with using HTTP messages to cause aglet
dispatch, I found
that creating a ticket is case sensitive to the
protocol name. The
error
is really in java.net.URL. See below.

Perhaps in Ticket.java, the function setDestination
(...) should have:

_protocol = destination.getProtocol().toLower();

Marc

----- Sample 1
** Request
farpoint.tear.com% lynx -dump
http://farpoint.tear.com\:4434/aglets/default/ddc/msg_D
ispatch\?
aglet=edu.ucsc.cse.http.mmosko.Sample\&amp;dest=ATP%3A%2F%
2Froaster.tear.com%3A4434

** Tahiti console snips
Mon Feb 26 11:39:33 PST 2001 (BaseUtil): Message <
[Message : kind =
msg_Dispatch: arg =
{%querystring%
=aglet=edu.ucsc.cse.http.mmosko.Sample&dest=ATP%3A%2F%
2Froaster.tear.com%3A4434,
dest=ATP://roaster.tear.com:4434, cgi-response=,
aglet=edu.ucsc.cse.http.mmosko.Sample}: priority = 5]>

java.net.MalformedURLException: unknown protocol: ATP
at java.net.URL.<init>(URL.java:290)
at java.net.URL.<init>(URL.java:210)
at java.net.URL.<init>(URL.java:229)
at com.ibm.aglet.Ticket.getDestination
(Ticket.java:179)
at com.ibm.aglets.LocalAgletRef.dispatch
(LocalAgletRef.java:881)
at com.ibm.aglets.SystemMessage.handle
(SystemMessage.java:200)
at com.ibm.aglets.AgletThread.run
(AgletThread.java:106)

------ Sample 2
farpoint.tear.com% lynx -dump
http://farpoint.tear.com\:4434/aglets/default/ddc/msg_D
ispatch\?
aglet=edu.ucsc.cse.http.mmosko.Sample\&amp;dest=atp%3A%2F%
2Froaster.tear.com%3A4434

(works fine)

Improper parsing of CGI query string

Robert Bergstrom — Tue, 27 Feb 2001 21:44:31 -0000

Thanks to Marc Mosko.

The current (1.2) parser in HttpCGIRequestImpl.java
does not
handle "/" characters in a CGI query string. It
considers them token
separators (like the &). The token delimiter should
be removed when
the parsing gets to the query string so the "cgi"
variable will be set
to whatever is remaining in the line.

It would also be nice to be able to pass relative path
information
to an aglet (e.g.
http://aglet:4434/default/aglet/mine/relative/path\),
but that's a bigger change.

Marc

farpoint.tear.com% diff HttpCGIRequestImpl.java
HttpCGIRequestImpl.orig
264,265c264
< // Marc M - change delimiter
to "" to get to EOL
< cgi = t.nextToken("");
---
> cgi = t.nextToken();