Rack Development Google Group

Rack with SOAP integration

k.arunmo...@gmail.com (Arunmohan) — Tue, 05 Jan 2010 07:17:49 UT

Hi All,
I am new to Rack. I am ROR developer. I have to work SOAP webservice
integration between a Rack and a Rails application. Rack app should be
a soap server and Rails app should be a soap client. How to work on
it? Anybody here, please help me. Give some simple sample code to
handle soap application between this.

Re: Why env.object_id is different in each middleware?

i...@aliax.net (Iñaki Baz Castillo) — Mon, 04 Jan 2010 19:44:15 UT

A workaround is creating an initial middleware (like rack-config), adding some
empty entries to env hash and latter, in other middlewares or final
application, using env["NEW_ENTRY"].replace.
Of course this is a hack as it's only valid if the new entry is a String or an
object supporting "replace".

Re: Why env.object_id is different in each middleware?

i...@aliax.net (Iñaki Baz Castillo) — Mon, 04 Jan 2010 00:58:18 UT

Yes it does :)
Thanks.

Re: Why env.object_id is different in each middleware?

g...@spork.in (Tim Carey-Smith) — Mon, 04 Jan 2010 00:50:22 UT

Hi there,
I've hit this before. This is because you are using Rack::URLMap (via
Builder#map).
The inner app is called with a new env hash.
Is this patch useful?
Is it useful to assume that a request will only have a single env hash?
Will it make Rack::Cascade and friends behave incorrectly?
Should URLMap revert the change in an ensure to allow subsequent

[PATCH] make Rack::Session::Cookie spec immune to Marshal changes

normalper...@yhbt.net (Eric Wong) — Thu, 31 Dec 2009 20:19:29 UT

Various versions/implementations of Ruby may Marshal data
differently. Instead of relying on a fragile test that
relies on exact byte sequence matches, just rely on existing
round-trip tests for the cookies.
---
> > �Otoh, I feel this test is so fragile that it's probably best to
> > �scrap it and rely on the round-trip tests...

Re: [PATCH] make Rack::Session::Cookie spec pass under 1.9.2dev

chneukirc...@gmail.com (Christian Neukirchen) — Thu, 31 Dec 2009 10:15:15 UT

[PATCH] make Rack::Session::Cookie spec pass under 1.9.2dev

normalper...@yhbt.net (Eric Wong) — Thu, 31 Dec 2009 01:37:05 UT

There appears to be a small change to the Marshal output
under 1.9.2dev that makes it output differently than
under 1.9.1. Tested with Ruby trunk r26127.
---
Otoh, I feel this test is so fragile that it's probably best to
scrap it and rely on the round-trip tests...
Pushed out to the "mri-1.9.2dev" branch of git://git.bogomips.org/rack

Re: Call for 1.1.0 release

normalper...@yhbt.net (Eric Wong) — Thu, 31 Dec 2009 01:22:52 UT

I sent the patches ad the end of this message to Christian which should
get test-spec mostly working under 1.9 (though I can't get test-spec to
pass its own tests).
Under all versions of Ruby I tested, the basic test suite fails
spec_rack_logger.rb:
<"Program started\nNothing to do!\n"> expected to be =~

Re: deferrable bodies in Rainbows!

normalper...@yhbt.net (Eric Wong) — Wed, 30 Dec 2009 10:47:29 UT

Rainbows! 0.90.1 should support deferrable bodies needed for async apps
on EM.
I stole the async_app.ru and async_tailer.ru examples from Thin and made
them a part of the integration tests (in t/t04??-*.sh).
The app.deferred?(env) isn't supported, yet. It's in the TODO and I
don't think many people use it... (correct me if I'm wrong).

deferrable bodies in Rainbows!

normalper...@yhbt.net (Eric Wong) — Sat, 26 Dec 2009 23:27:32 UT

Moving to rainbows list
Hi James, thhanks for the heads up.
Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
the first time around), so it can't do everything Thin does with EM, yet.
It's already in the TODO, I'll make a mental note to work on it sooner.

Re: Call for 1.1.0 release

jftuc...@gmail.com (James Tucker) — Sat, 26 Dec 2009 14:41:23 UT

Eric - I had a report from one of the async_sinatra users who tried out rainbows with EM, and found that the API didn't actually line up with what Thin was doing. I really want to devote some more time with this but I've been very busy. Sadly due to this I don't want to say stop, but, well, I want to say please check existing apps against it. I guess could you check async_*.ru from github.com/macournoyer/thin/ma ster/tree/examples/async_*.ru, as from what was reported, they're not working with the rainbows implementation of the deferrablebody hacks.

Re: Call for 1.1.0 release

jftuc...@gmail.com (James Tucker) — Sat, 26 Dec 2009 14:38:38 UT

+1 we need to hold off, there's more to discuss in this area.

[PATCH] update README, Sunshowers is not a web server

normalper...@yhbt.net (Eric Wong) — Sat, 26 Dec 2009 06:25:41 UT

Sunshowers is a library that can enhance Rack::Request when
used with Rainbows! but is not a server itself. Additionally,
the official name for Rainbows! is "Rainbows!" with a bang.
---
I've also pushed this out to the "rack-1.1-doc" branch of
git://git.bogomips.org/rack
I'm fairly certain I won't release another new Rack server

Re: Upcoming 1.1 release

scyt...@gmail.com (Scytrin dai Kinthra) — Sat, 26 Dec 2009 03:40:48 UT

Agreement on the version bump. There's been quite a few changes since
1.0 that I'm fairly sure are not backwards compatible.
Completed the migration of Auth::OpenID to rack-contrib. Had the
change pending a push. :P
After the next release I'm going to update all the references to me. I
had waaay to many pen names.

Upcoming 1.1 release

chneukirc...@gmail.com (Christian Neukirchen) — Fri, 25 Dec 2009 12:31:00 UT

Some things left to do:
I think we should update Rack::VERSION and Rack.release to 1.1.
We shouldn't remove Auth::OpenID without putting it to rack-contrib.
Also I updated the README, I hope I forgot nobody in the THANKS.