<xxneolithicxx>
im using Jruby to run some dynamically created ruby object (it uses a JSON hash containing its definition to add methods with different number of parameters on creation of the object instance). In ruby this works fine, but in jruby it ends up calling the wrong dynamically added method (and the one that it calls is expecting different parameters than whats defined in the JSON file).
<xxneolithicxx>
Are there limitations in Jruby regarding dynamically created objects?
tesmar has joined #jruby
tesmar has quit [Quit: tesmar]
Aethenelle_ has joined #jruby
mje113__ has quit [Quit: Connection closed for inactivity]
Aethenelle has quit [Ping timeout: 245 seconds]
Aethenelle_ is now known as Aethenelle
<xxneolithicxx>
appears theres an older post about define_method not working right in jruby i just found so I guess it doesnt work right
pgokeeffe has quit [Ping timeout: 246 seconds]
xcv has quit [Remote host closed the connection]
zeroecco has joined #jruby
josh-k_ has quit [Remote host closed the connection]
josh-k has joined #jruby
zorak8 has quit [Read error: Connection reset by peer]
josh-k has quit [Ping timeout: 272 seconds]
zorak8 has joined #jruby
tvo1 has quit [Quit: Leaving.]
josh-k has joined #jruby
tylersmith has quit [Remote host closed the connection]
tylersmith has joined #jruby
zeroecco has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Sinjo has quit [Quit: leaving]
iamjarvo has joined #jruby
Sinjo has joined #jruby
jsvd has joined #jruby
Hobogrammer_ has joined #jruby
colinsurprenant has joined #jruby
zorak8 has joined #jruby
tvo1 has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tvo1 has quit [Quit: Leaving.]
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/master cf817d7 Chris Seaton: [Truffle] Re-use Module#Include implementation for main.include.
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/29CAUQ
JRubyGithub has left #jruby [#jruby]
<mkristian>
kares, ping
<kares>
mkristian: pong
bbrowning is now known as bbrowning_away
dabradley has quit [Ping timeout: 245 seconds]
<mkristian>
hi, I am about to get my part green on jruby-1_7 and one problem is jboss-wildfly comes with BC-1.50 registered as SecutiryPRovider but then jruby-openssl fails to load java.lang.NoClassDefFoundError: org/bouncycastle/asn1/ASN1Encodable
<mkristian>
since jruby-openssl first check on BC provider before loading the jars
yfeldblum has joined #jruby
<kares>
mkristian: hmm ... well I thought that if a BC is explicitly registered a user knows what to expect ...
<mkristian>
it looks like the provider will work but the classes are not reachable with Thread.currentThrect.contextClassLoader
<kares>
that was meant as an "easy" way for allowing to override gem's BC ... did not think containers do setup BC ;(
benlovell has joined #jruby
<kares>
mkristian: do you have an idea why is that possible ?
<kares>
I mean the classes ... it should be on a "reachable" CP or maybe there's a Java security setting
<kares>
... why would it be setup if it can not be used from within apps
<kares>
bbrowning_away: might know about this ?
<mkristian>
bbrowning_away, might be the better person to ask
<kares>
mkristian: in the meantime if there's no way around it we'll have to revert the BC check before loading
x1337807x has joined #jruby
<mkristian>
kares, but if you register the BC but leave the actual BC classes in some other classlaoder - that is what I try to do in such a case.
<kares>
although it might be kind of unfortunate esp. if there's such mumbo-jumbo since if we end up using a BC class from elsewhere will be in much deeper issues ...
<mkristian>
kares, I guess we want to support jboss-wildfly
yfeldblum has quit [Ping timeout: 258 seconds]
<mkristian>
then currently see only to remove the check
<kares>
mkristian: we do not register BC now
<mkristian>
but wildfly - just thinking . .
benlovell has quit [Ping timeout: 250 seconds]
<kares>
mkristian: yes removing the check might be the only way or working around it with a piece of configuration
<kares>
but still it's concerning why BC is registered but the classes are not visible - smells like trouble
<kares>
in wildfly
<mkristian>
well, usually you do not use the classes directly but the javax.crypto API
<mkristian>
that why I think you can hide them
dabradley has joined #jruby
andreanastacio has joined #jruby
<mkristian>
kares, the configuration as an opt-in would do. opt-out is tricky - it took me a while to figure out why those bouncycastle classes were not found.
<kares>
mkristian: makes sense - hopefully they're hidden well or for good ... BUT some of the code might assume BC casting on returned pieces - not sure - hope not but I've seen it before
<kares>
as I'm getting closer to passing all tests
<mkristian>
it works for locally
elia has quit [Quit: Computer has gone to sleep.]
<kares>
mkristian: hmm .. not really but maybe it goes away as jruby-openssl is polished
<kares>
doesn;t it relate to the jar:/! loading issue ?
bbrowning_away is now known as bbrowning
<mkristian>
I hope
<cprice404>
since you guys are talking about ssl... :)
<cprice404>
mkristian: would you be amenable to a PR that upgraded you to BC 1.50?
<cprice404>
if we ever have time to work one up :)
<mkristian>
well it is one issue and websphere is another one
<bbrowning>
kares: mkristian: so you're expecting to use the bouncycastle classes shipped by wildfly?
<bbrowning>
wildfly uses something called jboss modules to control exactly what is and isn't visible to deployments
<mkristian>
bbrowning, wildfly does register BC as SecurityPRovider
<bbrowning>
this allows deployments to bring in different versions of various jars and allows the container (wildfly) to use jars internally that aren't visible to deployments
<mkristian>
and jruby-openssl currently wants to load the bouncy-castle classes since it think they are accessible
<mkristian>
via the context classloader of the webapp
<mkristian>
seems not be the case
<bbrowning>
yes - jboss modules will prevent bouncycastle classes from being seen there
<bbrowning>
you can configure that behavior inside the webapp with a jboss-deployment-structure.xml file in WEB-INF, I think
<bbrowning>
but that's obviously specific to wildfly
<mkristian>
kares, sounds like the config option is best way to go - IMO
<mkristian>
bbrowning, yes wildfly specific but we want jruby-openssl to work just work there as well
<mkristian>
again my opinion
<kares>
bbrowning: thanks - that is useful! mkristian: well, likely - will look into wildfly than at some point - removing it for now should be fine by default (unless someone plays with the jboss descriptor)
<bbrowning>
any app, even a standard java webapp, that wants to use bouncycastle deployed to wildfly will probably have this same issue
<bbrowning>
I can google around and figure out what their standard advice is to java users
<psyberduckling>
doesn't bouncycastle have to be installed into the jvm's extension classpath?
<psyberduckling>
typically $JAVA_HOME/jre/lib/ext ?
<bbrowning>
well, wildfly already installs bouncy castle as a security provider
<mkristian>
cprice404, you can use BC-1.50 but is a bit tricky
<cprice404>
psyberduckling: no; we use it just bundled into our jars
<bbrowning>
the problem just comes if you try to use code that links against any bouncy castle classes directly vs just using the java crypto apis
<cprice404>
mkristian: because those BC class APIs have changed? or..?
<cprice404>
we've been using 1.50 and like it much better than 1.47
<bbrowning>
there are a couple of different ways to tell wildfly to let your application code see the org.bouncycastle.* classes the container uses, but of course then you're using whatever BC version wildfly ships with
<cprice404>
we try very hard to avoid registering the global BC security provider
<cprice404>
we just realized yesterday that JRuby is bundling 1.47 inside our jar, while we're bundling 1.50... so i'm a little scared :)
<mkristian>
bbrowning, cprice404 jruby-openssl works ok with 1.49 or 1.50
<mkristian>
cprice404, how are you bundling 1.50 ? jbundler ?
<bbrowning>
mkristian: kares: jruby-openssl should have no problems bringing and using its own BC inside of wildfly - the problem would only arise if you try to use the BC wildfly provides
<bbrowning>
there's some code somewhere that tries to use bouncy castle from security provider stuff instead of just using BC directly?
<mkristian>
bbrowning, yes understood.
<psyberduckling>
If you want to avoid registering the service providers, you could probably exclude META-INF/services/ from the jar?
<psyberduckling>
least, I'm assuming that's how it's loaded by the jvm.
<cprice404>
mkristian: we ship our apps as uberjars
<kares>
cprice404: we're updating slowly - wanted to do 1.49 before 1.50
<cprice404>
mkristian: so our build tools (leiningen, specifically, which is kind of the maven replacement for Clojure) put the BC 1.50 classes into our jar.
<cprice404>
and then our jar also contains the BC 1.47 jars from JRuby in the META-INF.
<kares>
since it somehow was a considerable release (for us) ... later we'll ship 1.50 when we support 1.51
<cprice404>
I'm hoping that you guys are doing some stuff with classloaders that would prevent things from colliding :) we haven't had any issues so far.
<kares>
cprice404: that is pretty much non-standard stuff ... you know you're way around exluding a jar or two :)
<mkristian>
cprice404, yes, sounds OK but let me see how to tell jruby-openssl NOT to load the BC from META-INF
e_dub has quit [Quit: ZZZzzz…]
<cprice404>
kares: oh, interesting... so do you think it would Just Work if we set up our build to exclude the BC jar from META-INF?
colinsurprenant has quit [Quit: colinsurprenant]
phrinx has joined #jruby
<mkristian>
cprice404, yes, that should work. which jruby version are you using ?
<kares>
cprice404: with latest jruby that is safer (for the future) since we're not yet detecting BC versions but might need to at some point (1.51)
<kares>
with 2 BC versions on the near CP that would be trouble ...
<kares>
cprice404: on the other hand ignore me since ... we always need the BC .jars to load up till 0.9.5 (hopefully will change) ... me and mkristian are working on it
<cprice404>
kares: mkristian: we're shipping with jruby 1.7.15 for our upcoming release; we will be updating to 1.7.16 shortly after
<cprice404>
I'll put in a ticket in our issue tracker about just trying to exclude the BC jar from meta-inf in our builds and see if that works
<cprice404>
thanks for the info!
Stranger has joined #jruby
<cprice404>
are you guys calling `Security.addProvider` to register BC? I grepped your source for it and didn't see it. We've been trying to avoid that.
<mkristian>
cprice404, you can also try require 'jar-dependencies'; Jars.freeze_loading; require 'openssl' - that disable loading those embedded jars from META-INF ;)
Stranger is now known as Guest98240
<mkristian>
cprice404, not anymore
Guest98240 has quit [Client Quit]
<cprice404>
awesome
<cprice404>
yay!
JohnBat26 has joined #jruby
<mkristian>
kares, it looks like removing the check also fixed websphere tests :)
ahhMichael has quit [Ping timeout: 256 seconds]
pchalupa has joined #jruby
pchalupa has quit [Client Quit]
vtunka has quit [Ping timeout: 272 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/jruby-1_7 a0f96db Christian Meier: * fix version in GH-1983 test...
<JRubyGithub>
jruby/jruby-1_7 9a1b609 Christian Meier: delete installed jars on clean to avoid packing old jars as well
<JRubyGithub>
[jruby] jrubyci pushed 2 new commits to jruby-1_7: http://git.io/7rV6fg