i'm asked to do the same thing~. so i'm wondering if you have already stopped working on this issue
在 2011年8月13日星期六UTC+8下午3时59分32秒，Gardner!!写道： > > This is really helpful! I am going to work with dalvik-server first > because it seems to be the most sensible long-term approach. I'll > submit a pull request when I have it working! :) > > -g > > On Aug 11, 9:09 pm, Kohsuke Kawaguchi <[email protected]> > wrote: > > On 08/10/2011 09:34 PM, Gardner!! wrote: > > > > > I am very excited about this as well. It would be possible to reduce > > > the complexity of our testing system 3 fold. > > > > > Initially I was focused very much so on the client ClassLoader > > > implementation (that runs on the Android device in the slave.jar). By > > > modifying the RemoteClassLoader to check for java.vm.name == "Dalvik" > > > and adding the code directly to the RemoteClassLoader we could allow > > > for _any_ class to be fed into the Slave jar that is running on the > > > Android device to be converted by the dex tool, on the Android device, > > > in a procrastinated manner. The problem with procrastination is that > > > it causes work work to be duplicated always and forever. In this case > > > the work is being delegated and duplicated to and on an already > > > overloaded micro-platform. > > > > I was under the assumption that a jar file is a minimum unit of > > conversion, not a class file, and hence my suggestion. But I think you > > are saying that is not the case. > > > > (OTOH, when I look at the DexClassLoader and DexFile source code, it > > seems to me that my assumption is correct, and if we create one dex per > > one class, I'm not sure if Dalvik can cope with that many DEX files.) > > > > If "one class at a time" lazy conversion is possible, I think that's a > > very good starting point. For one, that's how all the slaves work, and > > it can be iteratively improved from there, for example to push the > > conversion to the server, or cache the result. > > > > Do you have some code that shows how to convert one class and load it > > into Android? Some kind of PoC/sandbox that lets other people (including > > me) to kick the tire? > > > > > Given this, It may be acceptable to dex _every_ jar if an "Android > > > Client Plugin" is installed. This would bloat the client jar for ALL > > > platforms but would exponentially reduce the work load that is pushed > > > to Android clients over time. > > > > Yes. Or a fairly straight-forward optimization from there is to > > translate a regular jar to a dexed jar on the fly (with some kind of > > caching) if we know we are talking to Android slave. > > > > > That being the case, what needs to > > > > > happen now is a discovery of how extra slave jars/classes are > > > maintained and a test of dexing all of them and then using the > > > existing RemoteClassLoader that all slave jars use to get on par with > > > the master to load the dexed jars from the existing slave jar. > > > > The general workflow in the current RemoteClassLoader implementation is: > > > > 1. slave tries to load "a.b.c.Foo" class > > 2. RemoteClassLoader requests the master to send it the byte[] > > for a/b/c/Foo.class > > 3. master sends it to the client > > 4. slave injects that into VM via ClassLoader.defineClass > > > > so the whole scheme doesn't involve the notion of jar file at all. > > > > For Android slaves, the workflow needs to be: > > > > 1. slave tries to load "a.b.c.Foo" class > > 2. RemoteClassLoader requests the master to send the > > jar file that contains a.b.c.Foo > > 3. master creates a dex file for the jar > > 4. byte[] gets sent > > 4. slave opens this dex file via DexFile and loads the class > > > > > Kohsuke, can you give any insight to where these classes are stored > > > and marked as being "required" for the slave to have? > > > > I've pushed 'dalvik-server' and 'dalvik-client' branches inhttp:// > github.com/jenkinsci/remoting > > > > They contain the pseudo-code that I think will make it work. The reason > > there are two branches, as opposed to one, is simply because I was lazy; > > the client side that runs on Dalvik needs to use some Dalvik-specific > > classes, so that portion needs to be isolated somewhat so that it won't > > cause UnsatisfiedLinkError when run on JavaVM. > > > > I'll leave that exercise to you :-) > > > > I think it'll be also easier to create a small stand-alone JavaSE > > program that initiates the channel pair, as opposed to do this > > experiment with full-blown Jenkins. > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > Gardner > > > > > On Aug 10, 4:10 pm, Kohsuke Kawaguchi<[email protected]> wrote: > > >> This is awesome! > > > > >> At runtime, master has all the jars that constitute the Jenkins code > > >> (including all the plugins deployed), so it's relatively easy to > > >> convert each jar file to a dex file and copy it over the wire to > > >> Dalvik. This assumes that Dalvik is resource-rich enough to be able > to > > >> load them all (or smart enough to only load classes that are > actually > > >> used), but it seems like the good first step to shoot for. > > > > >> How do you programmatically load a dex file into running Dalvik VM? > > >> Does it use the same java.lang.ClassLoader, or does it have another > > >> class that does it? > > > > >> 2011/8/10 Gardner!!<[email protected]>: > > > > >> > Hello, > > >> > I am tasked with testing our code across a growing number of > real > > >> > Android devices. During my discovery process I converted the > slave jar > > >> > into Dalvik byte code using the dex tool. I then included this > jar in > > >> > a regular Android application that I had created using Eclipse. > But I > > >> > ran into trouble when the Slave jar attempted to load remote > classes > > >> > from the master. I have scratched up a wiki document with a few > links > > >> > to information related to getting this working. > > >> > > https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Slave+on+DalvikVM... > > > > >> > I guess the next logical step is to start the custom ClassLoader. > > >> > Would anyone else be interested in this? > > > > >> > Thanks, > > >> > Gardner > > > > >> -- > > >> Kohsuke Kawaguchi > > > > -- > > Kohsuke Kawaguchi | CloudBees, Inc. |http://cloudbees.com/
