Rails 1.2 impact on Ajuby release 0.4

We are running into quite a few issues with latest Rails version 1.2 starting with Theme generator complaining about "named_route" , following is the exception that we get

=> Booting WEBrick...
./script/../config/../vendor/plugins/theme_support/lib/patches/routeset_ex.rb:26:in `create_theme_routes': undefined method `named_route' for #<actioncontroller::routing::routeset:0xb7d34690> (NoMethodError)
from script/../config/../vendor/plugins/theme_support/lib/patches/routeset_ex.rb:13:in `draw'


Reason is Theme generator is using its own routes extension for its custom routes and as per Rails 1.2 release , Routes section).


So meanwhile we figure out how to fix this or Theme generator comes with fix for Rails 1.2, Following is the fix that you can do

# Lets freeze the Rails for Ajuby release by running following command

> rake rails:freeze:edge TAG=rel_1-1-6

This will take rails 1.1.6 and make rails available within Ajuby framework, (We will eventually go this route. Every release will be bundled with Rails , so one less thing to worry with)

# After above step successfully complete, start the WEBrick and see if you run into any error , if yes possibly you would not have Activerecord core frozen properly. Not sure whether its a bug in the rake process. If you see this error like undefined method "deprecate" or #<Class:......

Copy activerecord/lib directory from your installed Rails (wherever you have installed rails version 1.1.6 before above freeze process) to <ajubyhome>/vendor/rails/activerecord/lib directory

Ajuby Release 0.4 is out

We are happy to announce latest release of Ajuby (0.4) out for general access/download on source forge/Google code.

• Here is the download information
• Latest release information
  

We are gearing up for next release, with interesting features like Module builder. Updates will be on the Ajuby wiki for coming release

Apache Axis namspace quirk in a SOAP response

When you use Apache Axis for your web services implementation , its a wise move but you got to remember its few one off situations, like this one that I'm going to explain.
Apache axis generates namespaces in every single element of the response , which can be very painful for the client if client is going parse and moreover its additional overhead in your SOAP response back to client, you are pushing more data over the wire where it can be avoided. sample looks something like this

<SOAP ENV..>
<SOAP Header..>
</SOAP Header..>
<SOAP body>
<ns1:elemenntname xsi:type="xsd:string"
xmlns:ns1="http://a.b.c/...." >
<ns2:elemenntname xsi:type="xsd:string"
xmlns:ns2="http://a.b.c/...." >

<ns3:elemenntname xsi:type="xsd:string"
xmlns:ns3="http://x.y.z/...." >

</SOAP body>
</SOAP Env...>


So above if you see , its unnecessary data getting duplicated in each element, where as ideally axis should be doing this internally by aggregating namespaces. So what you have to do is add following code in the your services code

org.apache.axis.utils.NSStack namespaceList = new org.apache.axis.utils.NSStack();
namespaceList .add("http://a.b.c./...", "ns1");
namespaceList .add("http://x.y.z./...", "ns2");
soapRespEnv.setNSMappings(namespaceList .cloneFrame());

Where as soapRespEnv is SOAP response envelope fetched from MessageContext. So what will above code do is, it will notify Axis engine to aggregate SOAP response namespaces in the SOAP envelope root. your response would look like below after above change



<SOAP ENV. xmlns:ns1="http://a.b.c/...." xmlns:ns2="http://x.y.z/....">
<SOAP Header..>
</SOAP Header..>
<SOAP body>
<ns1:elemenntname xsi:type="xsd:string">
<ns1:elemenntname xsi:type="xsd:string">

<ns2:elemenntname xsi:type="xsd:string">

</SOAP body>
</SOAP Env...>



benefitof above approach is

* Sheer data size reduction, that goes over the wire
* SOAP response looks like very clean.