<boc_tothefuture[>
That goes and grabs a ThingImpl from a registry that tracks them in a global variable.
<headius[m]>
fwiw that CamelCase package layout is not recommended... you can use the plain lowercase name with :: instead of . and we don't have to parse and guess at capitalization
<headius[m]>
Java::com::ope
<headius[m]>
openhabetc
<boc_tothefuture[>
ok.. let me colon it up.
<headius[m]>
it probably won't help but just a better pattern to use
<boc_tothefuture[>
you are recommending this:
<boc_tothefuture[>
class Java::org::openhab::core::thing::internal::ThingImpl
<headius[m]>
hmmm
<headius[m]>
yeah
<headius[m]>
Java::com.openhab.core .... is equivalent as well
<boc_tothefuture[>
Ok, so, that didn't help. but if I put a puts here, let me show you waht I get.
<boc_tothefuture[>
so with the get, it works.. and the class can be found.
<boc_tothefuture[>
Just trying to figure out.. why doing a get.. loads the class and then it can be found?
<boc_tothefuture[>
If the get doesn't pull back an object (the lookup fails) I do get the error. So it is like JRuby can't load the class unless its already pulled in somehow? This is the first I am seeing this.
<boc_tothefuture[>
would a java_import make a difference?
<headius[m]>
how are you pulling that library in? requiring a jar?
<boc_tothefuture[>
no idea.... Part of a large OSGI project running in apache karaf.. bundles get loaded, etc..
<headius[m]>
ok we'll just say it is complicated then
<boc_tothefuture[>
:-)
<boc_tothefuture[>
I can get what I need to do by monkey patching the object rather than the class..
<headius[m]>
if you can pass -d to JRuby we may see more output from the NameError
<boc_tothefuture[>
so I have a workaround, but its odd.
<boc_tothefuture[>
well its JSR233.. So what property do you want passed?
<headius[m]>
also -Xbacktrace.style=full will show us where in Java support it is erroring and maybe we are incorrectly swallowing some other error there
<headius[m]>
hmm checking
<headius[m]>
jruby.cli.debug
<boc_tothefuture[>
anything else or just that one?
<boc_tothefuture[>
that didn't make a big difference...
<headius[m]>
ok I see your line of code up there access a different class
<headius[m]>
Java::OrgOpenhabCoreThing::ThingUID
<headius[m]>
Perhaps this ThingUID is loading in more code itself that causes ThingImpl to get loaded?
<headius[m]>
I do not know how your app is structured, but from what we have seen it seems like ThingImpl is simply not available to JRuby before passing through that ThingUID class, which tells me that ThingUID or some code it calls is loading additional stuff
<headius[m]>
logging classloading around the error might tell us something, like JVM flag -verbose:class with and without the line that makes it work
<headius[m]>
that should at least show the sequence of classes being loaded and maybe tell us why accessing ThingUID constructor causes ThingImpl to be available
<headius[m]>
I assume you are opening this class to add some Ruby features
<boc_tothefuture[>
Well, the ThinkUID doesn't matter.. because if I put in a non-existant UID it doens't work. It only works if that method brings back a working ThingImpl
<headius[m]>
right, so it is causing ThingImpl to be accessi
<headius[m]>
accessible
<boc_tothefuture[>
ThingImpl implements the Thing interface.. Could I add method_missing on the interface?
<headius[m]>
like it is loading in some additional jar or component or classloader and then the class becomes available
<headius[m]>
I think that would work, yes
<boc_tothefuture[>
it is marked as internal so maybe its not loaded in some weird way by the OSGI system.
<headius[m]>
m_m is tweaky sometimes but you should be able to decorate the interface with Ruby stuff rather than decorating the Impl
<boc_tothefuture[>
how would that look? would it just be a module?
<boc_tothefuture[>
I tried with "class" which didn't work because its an interface.
<headius[m]>
module Java::path::to::Thing
<boc_tothefuture[>
ok.. let me try that.
<headius[m]>
yeah we map interfaces as modules
<boc_tothefuture[>
that seems to work.
<boc_tothefuture[>
must just be an odd class loading situation
<headius[m]>
ok cool
<headius[m]>
yeah hard to say but OSGI does a lot of stuff
<headius[m]>
nice, travis folks got back to us and bumped up concurrency to 20 to match what we had on .org
<headius[m]>
hopefully this also means we will not run into paid limits