New AMD64x2 Turion Latop Pain

This is a brief note for google really, if anyone else has problems with a Packard Bell EasyNote MV51 laptop and linux. Namely the x86_64 kernels refusing to start (hanging after "io scheduler cfq registered" ) with Ubuntu Efty Edge (and in fact any 2.6.17 or 2.6.18 64 bit kernel). Meaning you have to run with 'noapic' as one of your kernel options, which drops you down to a single cpu.

The new 2.6.19 rc6 kernel fixes it all!! Hooray, I now have 2 cpu-cores again, and in all its 64 bit loveliness!

Constructing a document literal-wrapped WSDL document

caveat: This document was originally written for an intranet wiki page to aid our team to construct WSDL for ActiveBPEL that was suitable for use by XFire Web Service clients and by .Net Web Service method calls. It was my first attempt at the problem and as such is probably wrong in several ways [one such example is the stuff I'm doing with namespaces, I now know that I should have two namespaces, one for my schemas and one for my definitions (WSDL documents), I didn't know /hadn't discovered this at the time, hence the uri: approach. (sorry!) ]

Anyway, hopefully this will help someone else going down this route :)

Steps to construct a document literal wrapped WSDL document:

• Decide on your service name, and the parameters it takes .
• Parameters seem to be defined in0,in1,in2 and out etc.
• For this example we're going to define a service called sprinkleDust which takes a Pixie entity and returns a tired Pixie.
• Construct your WSDL Document's basic structure
• We need to bring in the standard namespaces/schema definitions:
  

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="SprinkleDust"
  targetNamespace="http://yournamespace"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:smf="http://yournamespace"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
</definitions>

• Next we want to define the PortType that defines our service method:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="SprinkleDust"
  targetNamespace="http://yournamespace"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:smf="http://yournamespace"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <portType name="SprinkleDustServiceInterface">
      <operation name="sprinkleDust">
      </operation>
  </portType>
</definitions>

• Web methods aren't that useful without inputs and outputs, for this we need to define two WSDL message elements, and tell our operation to use them, note the naming scheme used here ServiceNameRequest and ServiceNameResponse [this is a convention but I don't think it actually matters]. Also note carefully where the prefix has been used.:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="SprinkleDust"
  targetNamespace="http://yournamespace"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:smf="http://yournamespace"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <message name="sprinkleDustRequest">
  </message>

  <message name="sprinkleDustResponse">
  </message>

  <portType name="SprinkleDustServiceInterface">
      <operation name="sprinkleDust">
          <input message="smf:sprinkleDustRequest" name="sprinkleDustRequest" />
          <output message="smf:sprinkleDustResponse" name="sprinkleDustResponse" />
      </operation>
  </portType>
</definitions>

• Now in order for the WSDL document to be truly document-literal/wrapped, we need to define our WSDL message elements carefully, they must conform to the following requirements:
• The input message has a single part
• The part is an element (not a type/reference)
• The element has the same name as the operation
• The element's complex type has no attributes
• Because this is a fairly complex set of requirements, first of all we'll flesh out the message elements, then we'll deal with the element it actually uses:
  

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="SprinkleDust"
  targetNamespace="http://yournamespace"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:smf="http://yournamespace"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:smfprocess='urn:SprinkleDustServiceProcess'>

  <message name="sprinkleDustRequest">
      <part name="parameters" element="smfprocess:sprinkleDust" />
  </message>

  <message name="sprinkleDustResponse">
      <part name="parameters"  element="smfprocess:sprinkleDustResponse"/>
  </message>

  <portType name="SprinkleDustServiceInterface">
      <operation name="sprinkleDust">
          <input message="smf:sprinkleDustRequest" name="sprinkleDustRequest" />
          <output message="smf:sprinkleDustResponse" name="sprinkleDustResponse" />
      </operation>
  </portType>
</definitions>

• Looking at the above WSDL you should be able to see we satisfy the previously defined constraints:
• The input message has a single part - in this case named parameters
• The part is an element (not a type/reference) - the element referenced is smfprocess:sprinkleDust or smfprocess:sprinkleDustResponse
• The element has the same name as the operation - smfprocess:sprinkleDust is the same name as the operation's name ( sprinkleDust )
• The element's complex type has no attributes - Can't see this just yet, but it doesn't, honest.
• Now we need to pull in the element's we're referring to that make up the document that is sent and received to/from the web service method:
  

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="SprinkleDust"
  targetNamespace="http://yournamespace"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:smf="http://yournamespace"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:smfprocess='urn:SprinkleDustServiceProcess'>
  <types>
      <xs:schema targetNamespace="urn:SprinkleDustServiceProcess">
          <xs:import schemaLocation="SAAll.xsd" namespace="http://yournamespace"/>
          <xs:element name="sprinkleDust" >
              <xs:complexType>
                  <xs:sequence>
                      <xs:element name="in0"  type="smf:Pixie" nillable="true" minOccurs="1" maxOccurs="1"/>
                  </xs:sequence>
              </xs:complexType>
          </xs:element>

          <xs:element name="sprinkleDustResponse">
              <xs:complexType>
                  <xs:sequence>
                      <xs:element name="out" type="smf:Pixie" nillable="true" minOccurs="1" maxOccurs="1"/>
                  </xs:sequence>
              </xs:complexType>
          </xs:element>            
      </xs:schema>
      </types>
  <message name="sprinkleDustRequest">
      <part name="parameters" element="smfprocess:sprinkleDust" />
  </message>

  <message name="sprinkleDustResponse">
      <part name="parameters"  element="smfprocess:sprinkleDustResponse"/>
  </message>

  <portType name="SprinkleDustServiceInterface">
      <operation name="sprinkleDust">
          <input message="smf:sprinkleDustRequest" name="sprinkleDustRequest" />
          <output message="smf:sprinkleDustResponse" name="sprinkleDustResponse" />
      </operation>
  </portType>
</definitions>

• This step was quite complex, we've added a types section, that defines our document-literal/wrapped elements, however it belongs to its own namespace. This is because in this WSDL file we're importing an external Schema that contains the definitions of our Pixie complex types and there are some special semantics around namespaces an imports + includes.

Last but not least, If we want our service to be used by other BPEL processes we need to add in a PartnerLink element, so our structure now looks like:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="SprinkleDust"
  targetNamespace="http://yournamespace"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:smf="http://yournamespace"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:smfprocess='urn:SprinkleDustServiceProcess'
      xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
  <types>
      <xs:schema targetNamespace="urn:SprinkleDustServiceProcess">
          <xs:import schemaLocation="SAAll.xsd" namespace="http://yournamespace"/>
          <xs:element name="sprinkleDust" >
              <xs:complexType>
                  <xs:sequence>
                      <xs:element name="in0"  type="smf:Pixie" nillable="true" minOccurs="1" maxOccurs="1"/>
                  </xs:sequence>
              </xs:complexType>
          </xs:element>

          <xs:element name="sprinkleDustResponse">
              <xs:complexType>
                  <xs:sequence>
                      <xs:element name="out" type="smf:Pixie" nillable="true" minOccurs="1" maxOccurs="1"/>
                  </xs:sequence>
              </xs:complexType>
          </xs:element>            
      </xs:schema>
      </types>
  <message name="sprinkleDustRequest">
      <part name="parameters" element="smfprocess:sprinkleDust" />
  </message>

  <message name="sprinkleDustResponse">
      <part name="parameters"  element="smfprocess:sprinkleDustResponse"/>
  </message>

  <portType name="SprinkleDustServiceInterface">
      <operation name="sprinkleDust">
          <input message="smf:sprinkleDustRequest" name="sprinkleDustRequest" />
          <output message="smf:sprinkleDustResponse" name="sprinkleDustResponse" />
      </operation>
  </portType>

  <plnk:partnerLinkType name="sprinkleDustPartnerLink">
      <plnk:role name="User">
          <plnk:portType name="smf:SprinkleDustServiceInterface" />
      </plnk:role>
  </plnk:partnerLinkType>
</definitions>

svn:externals and moving servers

Having just gone through the pain of moving our subversion repository off a machine that died on us, we discovered, or rather re-discovered the pain of (ab)using svn:externals to refer internally to the repository. i.e. we had a series of 'svn:externals' properties pointing to the server that went down.

To fix this I wrote the following ruby script to iterate over a checked-out repository and replace any existing svn:externals references to the current server with a new address. This post is really meant just to hold the ruby code I wrote so I can find it in the future ! :)

directory="";
Dir.foreach( directory ) do |x|
        unless x== "." or x == ".." or x ==".svn"
            if  File.directory?( directory + "/" + x )
                # Do the externals check here.
                externals= `svn propget svn:externals "#{directory}/#{x}"`.split("\n");
                if externals.length > 0
                    puts "--------------  #{directory}/#{x} -------- "
               
                    # Swap the bala for svn.
                    externals.collect! do |line|
                        line.gsub!( /oldServer:81/, 'newServer:81' );
                    end
               
                    # Write the new svn:externals property out to a file to use with the propset...
                    File.open("externals.txt","w") do |file|
                        file.puts( externals.join("\n") );
                    end
               
                    # Apply the new svn:externals property.
                    `svn propset svn:externals "#{directory}/#{x}" --file externals.txt`
                end
                manipulateDirectory( directory+"/"+x );
            else
            end
        end
end

end

manipulateDirectory( "." ) ;