[ANNOUNCE] - 1.1 Released

[Mark Mandel]

Hey all,

Just a heads up that I just release JavaLoader 1.1

For a quick synopsis, to copy and paste from my blog:

http://www.compoundtheory.com/?action=displayPost&ID=549

A couple of new items in this release of JavaLoader:

• A few bug fixes in the NetworkClassLoader that allowed the Tika library to work.
• A new function for switching out the ThreadContextClassLoader.

The new function, swithThreadContextClassLoader() is useful as it is often required when dealing with libraries, such as dom4j, that use the ClassLoader to define singletons or search for implementing classes, and don't allow you to overwrite what ClassLoader they use. Check out the wiki for more details on why this is neccessary, and how easy it is to now do, thanks to our new function!

Also, JavaLoader has been move to GitHub, along with the all the documentation. This should make collaboration much easier moving forward!

Enjoy!

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast

http://www.2ddu.com/

[Dennis Clark]

Now that Mark has officially announced the move of JavaLoader to GitHub, I can now say that I have integrated a couple of modifications contributed by members of this into git "feature branches", now available on my fork at https://github.com/boomfish/JavaLoader. The branches are:

feature/factory: Merge of Jamie Krug's factory CFC that instantiates and reuses JavaLoader objects in the server scope into JavaLoader 1.0.1 (https://groups.google.com/forum/#!topic/javaloader-dev/o5X1ib2FYaU)

feature/urlclassloader: Patch by Barnaby Relph against JavaLoader 1.0 to support custom URLClassLoader classes (https://groups.google.com/forum/#!topic/javaloader-dev/2wlBUQf81ts)

I have yet to use these features myself, but they seem useful enough to be worth sharing. I'm pretty much done with them for now, so if anyone wants to add to either of these I suggest forking Mark's repository (instead of mine) on GitHub and just pulling the feature branch you want to work on from my remote.

Cheers,

-- Dennis

[Mark Mandel]

Jamie, Barnaby - do you guys have your own GitHub repos you want me to pull from for these changes?

Also.. not seeing any unit tests for either of them? :D

Mark

--
You received this message because you are subscribed to the Google Groups "javaloader-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaloader-dev/-/8IxuXotOKs4J.
To post to this group, send email to javaloa...@googlegroups.com.
To unsubscribe from this group, send email to javaloader-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaloader-dev?hl=en.

[Dennis Clark]

FYI I created my feature/factory branch by pulling from the master branch of https://github.com/jamiekrug/JavaLoaderFactory (which is not a fork of JavaLoader and contains no JavaLoader files), merging into JavaLoader 1.0.1, then moving the factory files into its own folder. The only thing you would gain from pulling from Jamie's repo over my branch is the JavaLoaderFactoryBean.cfc he added in his develop branch. If you want to merge his develop branch you'd probably want to move that file into its own folder as well.

The feature/urlclassloader branch is simply a commit of the file Barnaby posted on the list. I used a diff tool to find the version of JavaLoader that was closest to the file he uploaded, created the feature branch from that point and committed his changed file.

Neither Jamie nor Barnaby provided unit tests and each of the two branches implements a feature that introduces complications to unit testing. Frankly was more interested in making the branches available than integrating them into the main project.

The JavaLoaderFactory component uses the server scope to cache JavaLoader instances, so a unit test run will be influenced by previous test runs unless some extra magic is introduced.

Unit-testing the feature/urlclassloader branch would require reproducing the conditions that caused Barnaby to write the patch in the first place, i.e. a jar file that conflicts with some of the jars provided by ColdFusion and a custom child-first URLClassLoader class. I'm not familiar enough with slicing-and-dicing jar files to be able to write a unit test that doesn't involve including the 15MB jar file mentioned in the discussion thread.

It wasn't my intention to make these branches "pull-ready", and I do not plan to submit pull requests for them. However if anyone else wants to work on this I'd be happy to assist in any way I can.

-- Dennis

[Barnaby Relph]

Hi All,
I'm on Holiday at the moment, but I'll look early next week at
putting tests around the changes I made. I've not got a gitbub repo
set up yet, but if I can work out tests, I'll set one up. I may need
some assistance in doing the forking/pull request stuff, but I'll
shout when i get there.

thanks

Barny

> --
> You received this message because you are subscribed to the Google Groups
> "javaloader-dev" group.

[Jamie Krug]

Mark,

I'll try to have a closer look over the next couple days. I have a couple different versions of that factory (a standalone and one for ColdSpring 1.2--the latter of which works with CS 2 as well by simply implementing interface instead of extending, IIRC). I was hoping to clean up both and offer pull requests for JavaLoader and/or ColdSpring 2.0. So, I'll review both projects, and put together unit tests in my own fork.

@Dennis: Thanks for the nudge to streamline this stuff :)

Best,
Jamie

[Jamie Krug]

Barny,

GitHub makes forking and pull requests rather nice. To start, merely login to your github.com account, then go to https://github.com/markmandel/JavaLoader and click "Fork" :) I'm not sure whether you're new to Git, or just GitHub (or maybe only fork/pull); but if you are just getting git setup locally, I'll recommend setting up your global git config settings and including a proper `core.autocrlf` setting. This takes care of cross-platform line ending issues, as explained here. In a nutsell, execute `git config --global core.autocrlf input` if you're on Linux/Mac, or `git config --global core.autocrlf true` if you're on Windows.

After forking the primary JavaLoader project repo, I cloned my fork like so (be sure to change the git URL to that of your own fork!):

# cd <parent directory to project we're about to clone>

git clone g...@github.com:jamiekrug/JavaLoader.git

I'll then set the main project repo as the "upstream" remote (and fetch, to get all branches and stuff):

cd JavaLoader/

git remote add upstream git://github.com/markmandel/JavaLoader.git

git fetch upstream

JavaLoader uses the "develop" branch for the main line of development, or bleeding edge, if you will (based on the fantastic git branching model described at http://nvie.com/git-model). Since the clone command just creates the default "master" branch locally, we'll want to create a "develop" branch for our fork (PS: "origin" is the remote name of our own forked repo, while "upstream" is the remote name for the primary project repo):

git checkout -b develop origin/develop

Now we want to hack, so we'll create a local feature/topic branch from develop before we start hacking:

git checkout -b some-topic

After making some commits to our "some-topic" branch, we'll want to merge those changes into our "develop" branch, but first we'll want to ensure we have all recent changes from the main project repo (upstream). To do this, we fetch from upstream again, and if there are any new changes, we'll rebase our branch on upstream's develop branch:

git fetch upstream

git rebase upstream/develop

# address merge conflicts, if any

Finally, we can merge our changes and then push them up to our GitHub fork (the "origin" remote):

git checkout develop

git merge --no-ff some-topic

git push origin develop

Now you can head to your fork on the GitHub Web site and submit a pull request to the project repo, for Mark to receive. GitHub help pages explain all this stuff pretty well, so I won't repeat it here. Just be sure your pull request is for your "develop" branch, to go to Mark's "develop" branch.

Hope that helps!

Best,
Jamie

[Mark Mandel]

Best. Explanation. Ever.

Mark

[Barnaby Relph]

Jamie, thanks so much for the explanation, I really appreciate the
effort! I'll work through the instructions over the next week or so
and get my changes in a state to pull.

again, thanks

Barny

[Jamie Krug]

Barny, glad to help. I remember trying to dive into git, GitHub and work flows all at once. It feels quite simple now, but it certainly was not when I first jumped in all at once ;-)