Least intrusive way to order cvm classpath?

[ixtab]

Hi,

ok... this might require a little more explanation as to why I'm asking this at all. I'm specifically looking for a solution for the Kindle Touch here, but this is a general question mostly independent from the actual device.

Some of the already existing hacks require patches to (existing) Java classes. The ones I know about are:

1. GUI Launcher by Yifan Lu
2. Localization (more specifically, the locale_enabler stuff)
3. Font Hack (more specifically, the "Kindlet Jailbreak")

There are generally two ways to achieve such a replacement. The obvious one is to simply modify the existing jar. The less obvious, but more elegant and preferred one (at least in this context) is to put them in a different jar, making sure that it appears before the original jar in the classpath. This works because when a class is initially looked up, the classpath is scanned "linearly", and the first occurrence wins.

The second alternative is preferred in this context because it entirely avoids messing with Amazons proprietary files. It will (generally) not affect framework updates, it can be easily undone, etc.

For the first two of the abovementioned hacks, the second method worked, because the classes that required changes were inside /opt/amazon/ebook/booklet/. The "patches" went into /opt/amazon/ebook/lib/ instead, and thus were always loaded before the originals (see below).

For the third hack, it didn't work. But for this particular case (the affected jar is the "simple_json" one), this isn't too much of a problem either, because simple_json is released under the Apache Software license, so it can be freely distributed in the hack installer and uninstaller.

However now, I'm running into a problem. The reason is that in order to solve this problem/request, a class inside /opt/amazon/ebook/lib/ReaderSDK-impl.jar has to be changed. Publically distributing this file in an installer/uninstaller is extremely questionable from a legal point of view. And of course, I want to use the "elegant" way.

So after all this introduction, here are some relevant lines from /etc/upstart/framework (a lot of the file is stripped away here):

EHOME=/opt/amazon/ebook

JAR_LIST=$(find $EHOME/lib $EHOME/booklet /usr/local/ebook/lib -name \*.jar 2>/dev/null)
CPATH=$(echo $JAR_LIST | sed -e 's/ \+/:/g')

JOPTS="-Dsun.awt.exception.handler=com.amazon.agui.swing.event.EventQueueExceptionHandler \
-Xbootclasspath/a:$JLIB/localedata.jar:$JLIB/charsets.jar:$LPATH \
-Dsun.boot.library.path=$JLIB \
-cp $CPATH"
OPTS="$HEAP $JOPTS $IHPROF $DEBUG $AOPTS"

$JHOME/bin/cvm $OPTS $APP 2>&1 | logger -p local2.debug

The "problem" here is the order of the classpath, or more specifically, the output of "find". Any file in $EHOME/lib is guaranteed to appear before the files in $EHOME/booklet, but the order of files inside the same directory is essentially random.

A simple approach would of course be to edit the file directly, inserting a few sort commands. But that would again go against my goal of being as unintrusive as possible by only *adding* stuff (which can be easily removed) instead of *modifying* stuff.

One way that I thought of, and that would probably work, is to create the file /usr/local/bin/find, which would act as a wrapper to /usr/bin/find, taking some further action on particular arguments.

Can anyone think of another, nicer, alternative?

... a bit like "sudoku for freaks" ...

Thanks!

[thatworkshop]

Originally Posted by ixtab

The "problem" here is the order of the classpath, or more specifically, the output of "find". Any file in $EHOME/lib is guaranteed to appear before the files in $EHOME/booklet, but the order of files inside the same directory is essentially random.

Can't you simply put the added file in a sub-directory inside $EHOME/lib lets say $EHOME/lib/myLib and then put its path before the parent path?!

[geekmaster]

I like this idea. We need our changes to be minimally intrusive whenever possible.

ixtab's karma just jumped past the 10K mark!

[ixtab]

Wooohoooo! Merci beaucoup, Monsieur geekmaster

Unfortunately, my idea of using /usr/local/bin/find didn't work (I tried it, but it seems like the built-in busybox commands are preferred over $PATH), and neither did cscat's proposal

So... any other ideas?

[geekmaster]

Originally Posted by ixtab

Wooohoooo! Merci beaucoup, Monsieur geekmaster

Unfortunately, my idea of using /usr/local/bin/find didn't work (I tried it, but it seems like the built-in busybox commands are preferred over $PATH), and neither did cscat's proposal

So... any other ideas?

I had that problem with busybox. I was not able to use a fully-qualified path, so I launched my app inside a new shell (different busybox) that did not have the command that I needed built-in, so it used the one on the search path.

For example, when booted to main, to start a shell using the diags busybox, do:

mount /dev/mmcblk0p2 /mnt/mmc
/mnt/mmc/bin/busybox sh

Of course, that was only useful on the K4, which has very different Busyboxes on main and diags, but on the touch they were identical, when I checked. But don't let that stop you. You can use a custom busybox.

The new shell inherits your PATH, but if you now use a command that is not in the diags busybox but which is in and would be intercepted by main busybox, you are good to go, and the command on the search path now runs instead of the stripped busybox version that is missing options you need...

Anyway, that is how *I* solved a problem similar to the one you described... *

Of course, you probably want to start a shell in a DIFFERENT busybox that is in /mnt/us/bin, right?

SUMMARY: To break out of the Busybox "sandbox" for its built-in commands, start a child shell from a different Busybox that does not have your chosen command built-in, or at least has a more-capable built-in that does what you need.

P.S. Busybox commands do not need symlinks. You can just stick "busybox" in front of busybox built-in commands (like "busybox sh").

[ixtab]

Got that. But at the point in time where I need it, there hasn't even been a chance to tamper with these things... (AFAIK)

The problem is that I'm trying to influence (if at all possible) the "environment" that the KT sees while executing /etc/upstart/framework, while it is booting. I had hoped that the "find" command there would be "substitutable" because of $PATH resolution, but it's obviously using the built-in one from busybox at that time.

So the question is pretty much: can anybody find a "hook point" in that script where one could influence how the individual commands are resolved? I was also thinking about aliases which could be (transitively?) introduced through /etc/upstart/(functions|env), but I doubt that at this time of the startup process, any of these would be used, since most of the commands are "busybox" anyway...

[knc1]

Originally Posted by geekmaster

P.S. Busybox commands do not need symlinks. You can just stick "busybox" in front of busybox built-in commands (like "busybox sh").

There are two ways that busybox may be configured -
One (which does not require sym-links) does require that /proc be mounted.

The other configuration choice does require links (either symbolic or hard) but will work without /proc mounted.
This configuration option also allows you to just replace a bb link with an executable and you will get the real-executable. Also a real-executable "wins" according to the usual path rules over the bb link.

From your post, the BBs that you write about must be configured per the first choice above.
I always option my builds of BB according to the second way.

[twobob]

Sure it's an old thread.

But I just wanted to add that it is possible to bypass this busybox configuration option's shortcoming (as demonstrated in the building a better busybox thread).

Assuming you have a spare busybox lying around... if one aliases the find command find to busybox find the second -replacement - busybox is invoked - something similar could perhaps work for this. IE an aliasing solution. As outlined by GM above. Don't see why this could not be further abused.

Just thinking out loud. Simply wanted to say that this hard-coded command line limitation can seemingly be bypassed. I also noted that it could be further bypassed by added the <ENV=whatever> environment variable in non interactive shells FWIW.



Oh and in other news I finally got my cvm to spit out the bits I was looking for...
(and my logs configured in a sane enough way to read it easily)

[root@kindle root]# /usr/java/bin/cvm -version

From log:

cvm[15431]: I def:print::Product: Sun Java Embedded Client, Advanced Graphics Edition 1.0 phoneme_advanced-Core-1.3-b16 sjmc-b111 (built on 17/Jul/2012 16:53 PDT)
cvm[15431]: I def:print::
cvm[15431]: I def:print::Profile: Personal Basis Profile (Security Optional Package) 20120717 (Specification 1.1.2  Optional Pkg: AGUI Specification 1.0)
cvm[15431]: I def:print::
cvm[15431]: I def:print::JVM:     CVM phoneme_advanced-Core-1.3-b16 sjmc-b111 (mixed mode)
cvm[15431]: I def:print::

[root@kindle root]# /usr/java/bin/cvm -XbuildOptions

   121112:170355 cvm[15773]: I def:print::AWT_IMPLEMENTATION=gci
[!]121112:170355 CVM_AGENTLIB=true
[!]121112:170355 CVM_AOT=true
[!]121112:170355 CVM_CCM_COLLECT_STATS=false
[!]121112:170355 CVM_CLASSLIB_JCOV=false
[!]121112:170355 CVM_CLASSLOADING=true
[!]121112:170355 CVM_CREATE_RTJAR=false
[!]121112:170355 CVM_CSTACKANALYSIS=false
[!]121112:170355 CVM_DEBUG=false
[!]121112:170355 CVM_DEBUG_ASSERTS=false
[!]121112:170355 CVM_DEBUG_CLASSINFO=true
[!]121112:170355 CVM_DEBUG_DUMPSTACK=true
[!]121112:170355 CVM_DEBUG_STACKTRACES=true
[!]121112:170355 CVM_DEFAULTENCODING_UTF8=true
[!]121112:170355 CVM_DUAL_STACK=false
[!]121112:170355 CVM_DYNAMIC_LINKING=true
[!]121112:170355 CVM_EMBEDDED_HOOK=false
[!]121112:170355 CVM_FORCE_HARD_FLOAT=true
[!]121112:170355 CVM_GCCHOICE=generational
[!]121112:170355 CVM_GCOV=false
[!]121112:170355 CVM_GC_DEFAULT_SIZE_OVERRIDE=false
[!]121112:170355 CVM_GENERIC_MONITOR_TASK_ENABLED=true
[!]121112:170355 CVM_GPROF=false
[!]121112:170355 CVM_GPROF_NO_CALLGRAPH=true
[!]121112:170355 CVM_HAVE_CUSTOM_SYS_MEM_ALLOC=false
[!]121112:170355 CVM_HEAP_MONITOR_TASK_ENABLED=true
[!]121112:170355 CVM_HOST=arm-generic-linux
[!]121112:170355 CVM_IAI_OPT_ALL=true

etc...

yay me. lol.