Plugins don't work on OSX?

[cabbey]

Nope. The classpath items in the plist replace the -classpath options on that line.

For crying out loud! How about -cp?

Same. they do that intentionally.

[chocolateboy]

Nope. The classpath items in the plist replace the -classpath options on that line.

For crying out loud! How about -cp?

Same. they do that intentionally.

In that case, I probably won't even bother looking at Limewire. It's obvious they (Apple? Ant developers? JarBundler developers?) are deliberately thwarting this solution, and, as you say, loading jars dynamically with class loader hacks is an ugly code-smell solution for something that shouldn't be an issue, and isn't on any other platform.

Thanks for your help (and workaround).

[cabbey]

In that case, I probably won't even bother looking at Limewire. It's obvious they (Apple? Ant developers? JarBundler developers?) are deliberately thwarting this solution, and, as you say, loading jars dynamically with class loader hacks is an ugly code-smell solution for something that shouldn't be an issue, and isn't on any other platform.

In theory it's a security reason. Sun refused to allow wild cards in jar paths when they shipped jars in the first place for that reason. It wasn't until java 6 that they relaxed that and allowed wildcards on the classpath to pickup JARs. Apple simply hasn't caught up with that change in their implementation (you can't pass a wild card on the command line to java either so far as I can tell). I didn't dig too deeply into JarBundler to see where they got the bit of native code that is the java stub launcher they package into the App bundle... but I suspect it's standard Apple issue, so it will have the same limitations. Technically it's an issue on most other platforms as well, the difference is that you have a shell script that wraps up the java call and builds the classpath for you. You could do that on OS/X as well... possibly even with the same shell script... but I don't know if JarBundler can support that. (And after two tries, I've not been able to successfully build the app from your sources to validate any of those theories.)

To be honest, my entire interest in PMS3 was to check out a specific plugin that was built by a 3rd party to access our servers... so I was on a bit of a single track mind when I investigated it this time around. I had done so quite some time ago just for personal use, but in the end went with a different DLNA solution due to the java prereq. (my DLNA server is sharing a small embedded device with 256M of memory.) I still don't currently think I'll be making much use of it now that I have it "working". (Why? Way too many unsupported features on the mac, way too many network connection issues on the ps3... it just didn't feel production ready... and didn't really jump out and grab me as a tool I have to have since I already have a much more stable DLNA server on my network that meets my needs.)

Thanks for your help (and workaround).

No problem, like I said, I was here for a specific reason, now accomplished... I just ran across this thread while trying to figure out how to make this work and didn't want the hours I spent investigating the problem to go to waste since it seemed I wasn't alone.

If the project doesn't want to do the kind of classpath hacks above, and doesn't want to write some kind of a deployment tool for deploying plugins on mac os/x, or hack up a new way to launch the app in the jarbuilder process... then possibly looking at a plugin manager like http://sourceforge.net/projects/javapmes/ would be a good idea. That appears to buy you several things, like validation of content and management of plugins, in addition to abstracting the uglyness of shoving an additional URLClassLoader into the system. (which in and of it's self isn't a bad thing... for a while it was either that or a wrapper script (batch file for the wintendo?) that went and found all your jar/zip files and built a classpath. The only reason for the distaste I expressed was that I didn't want to suggest changing core code to deal with an issue that was already solved in platform unique wrappers on other platforms.)

[taconaut]

Thanks for this interesting read.
I had tried to load the jars in the plugins directory by modifying the jarbuilder part in the osx ant script. to climb up the file system (something like /../../../plugins) but as for the above it didn't work

[chocolateboy]

In theory it's a security reason.

Yes, I assumed it was.

I don't know if JarBundler can support that. (And after two tries, I've not been able to successfully build the app from your sources to validate any of those theories.)

JarBundler's not terribly well documented in this area (hence my source-diving). I also did a Google Code search to see if anyone was doing anything similar/advanced with it, and couldn't find anything. So if it is possible, it probably requires another trawl through the JarBundler source, which is not really worth my while given I can't test it.

possibly looking at a plugin manager like http://sourceforge.net/projects/javapmes/ would be a good idea

I'm not sure those extras would be of much use with PMS: signing plugins would be overkill, and PMS provides a simple hook for plugins to register a GUI. Still, I'll take a look. My concern is not so much the impact on PMS code (in principle, it could be localized to PMS.java with, possibly, a new helper class or two). I'm more concerned with any solution that involves patching PMS as patches don't get applied. At least with a build/packaging patch, someone/anyone else can take on packaging duties (e.g. [1][2]) without waiting for PMS to wake from its slumber.

in addition to abstracting the uglyness of shoving an additional URLClassLoader into the system. (which in and of it's self isn't a bad thing

No, I didn't mean to imply that it's intrinsically bad. It's de rigueur for interpreters like Groovy to use a custom class loader. It's just a shame to use a big gun like that, or a plugin manager wrapper, when, as you say, a one-liner serves just as well on every other platform.

[chocolateboy]

(you can't pass a wild card on the command line to java either so far as I can tell)

(You can.)

I didn't dig too deeply into JarBundler to see where they got the bit of native code that is the java stub launcher they package into the App bundle... but I suspect it's standard Apple issue, so it will have the same limitations. Technically it's an issue on most other platforms as well, the difference is that you have a shell script that wraps up the java call and builds the classpath for you. You could do that on OS/X as well... possibly even with the same shell script... but I don't know if JarBundler can support that.

Well despite myself, I've poked around further and it turns out that PMS already uses a shell script wrapper to launch itself on Macs. It doesn't use the "official" way to do this (the stubfile attribute). Instead it does a search and replace in Info.plist and replaces JavaApplicationStub with JavaApplicationStub.setenv.

So, given the fact that this shim is available, it should be possible to build up a -classpath argument in the shell script containing all the available jars.

Here's a rough sketch:

Code: Select all

#!/bin/sh

# set environment variables here
export LANG=en_US.UTF-8

working_dir=`pwd`
classpath=`(find $working_dir/ -maxdepth 1 -name update.jar; find $working_dir/plugins -name '*.jar') | paste -s -d':'`

# execute the real JavaApplicationStub
here="${0%/*}"
cmd="JavaApplicationStub"

if [ x"$classpath" != x"" ]; then
    exec "$here/$cmd" -classpath "$classpath" "$@"
else
    exec "$here/$cmd" "$@"
fi


Note: the -maxdepth find option has been supported since Mac OS v10.2 (Jaguar) and the minimum Mac OS version supported by the Mac build is v10.5 (Leopard).

As mentioned before, I don't have access to a Mac, so someone else will need to test/tweak it.

[Redlum]

Interesting, I'll give this a try soon. Thanks for the work.

[blueshifter]

Nope, can't get this to work. I'm running
PS3MS 1.20.409
OS X 10.6.4
java version "1.6.0_20"

I downloaded the smugmumg plugin (since cabbey seemed to have succes with that one), and the soundcloud plugin (the one i want).
added all the jar files to the the /Contents/Resources/Java/plugins
modified /Contents/info.plist and added the jars to the classpath
confirmed the plist viewer shows the new items, just like in cabbey's screenshot
saved everything, launch the app -

Nothing in the "plugin system" area of General Configuration tab.

Can anyone confirm they have gotten this to work?

[chocolateboy]

Can anyone confirm they have gotten this to work?

Got what to work? There are multiple proposed workarounds in this thread.

[blueshifter]

Got what to work? There are multiple proposed workarounds in this thread.

The "what" are the steps I described, which are also the steps user cabbey described in the first workaround. Namely, add the jars to the classpath of the info.plist, as well placing the jars within the plugins folder of the Package Contents. You, chocolateboy, then went on to make a tool to automate that using jarbundler, then you and cabbie went back and forth testing that tool, but I'm only asking about the original, manual process. Thanks!