Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <8578658.1149023490555.JavaMail.jira@brutus>
Date: Tue, 30 May 2006 21:11:30 +0000 (GMT+00:00)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Commented: (HADOOP-217) IllegalAcessException when creating
 a Block object via WritableFactories
In-Reply-To: <1616267.1147481890143.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/HADOOP-217?page=comments#action_12413905 ] 

Doug Cutting commented on HADOOP-217:
-------------------------------------

I think this has been fixed, no?

The problem is that, when we modified Hadoop to use a classloader the writable factory stuff partially broke.  In particular, one can now obtain a reference to a Class instance when the static initializers of that class have not yet been run.  In particular, the RPC code calls something like 'WritableFactories.newInstance(ClassLoader.findClass("foo.bar.Baz")), and foo.bar.Baz's static initializer, which registers the writable factory, has not yet run, and the call to newInstance fails as above.  The work-around we've been using thus far is to, in the RPC client code, add a 'static { new Baz(); }' to force the static initializers of Baz to run.  Long-term we should find a better solution.

We'd like to be able to pass objects in RPCs that are not public classes.  This means that the RPC code needs to be able to construct an instance.  The WritableFactory mechanism was created to solve this, but, as described above, it mysteriously broke when we stopped using the bootstrap classloader.

> IllegalAcessException when creating a Block object via WritableFactories
> ------------------------------------------------------------------------
>
>          Key: HADOOP-217
>          URL: http://issues.apache.org/jira/browse/HADOOP-217
>      Project: Hadoop
>         Type: Bug

>   Components: dfs
>     Versions: 0.3
>     Reporter: Hairong Kuang
>     Assignee: Hairong Kuang
>      Fix For: 0.4
>  Attachments: access.patch
>
> When I ran the dfs namenode, I received an error message listed below. Changing Block class to be public will be able to fix the problem.
> java.lang.RuntimeException: java.lang.IllegalAccessException: Class org.apache.hadoop.io.WritableFactories can not access a member of class org.apache.hadoop.dfs.Block with modifiers "public"
> java.lang.RuntimeException: java.lang.IllegalAccessException: Class org.apache.hadoop.io.WritableFactories can not access a member of class org.apache.hadoop.dfs.Block with modifiers "public"
>         at org.apache.hadoop.io.WritableFactories.newInstance(WritableFactories.java:49)
>         at org.apache.hadoop.io.ObjectWritable.readObject(ObjectWritable.java:226)
>         at org.apache.hadoop.io.ObjectWritable.readObject(ObjectWritable.java:163)
>         at org.apache.hadoop.io.ObjectWritable.readObject(ObjectWritable.java:211)
>         at org.apache.hadoop.ipc.RPC$Invocation.readFields(RPC.java:88)
>         at org.apache.hadoop.ipc.Server$Connection.run(Server.java:154)
> Caused by: java.lang.IllegalAccessException: Class org.apache.hadoop.io.WritableFactories can not access a member of class org.apache.hadoop.dfs.Block with modifiers "public"
>         at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
>         at java.lang.Class.newInstance0(Class.java:344)
>         at java.lang.Class.newInstance(Class.java:303)
>         at org.apache.hadoop.io.WritableFactories.newInstance(WritableFactories.java:45)
>         ... 5 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira