Passing the compiler with runtime types

Welcome to the world of "Why SOAP should die a horrible death"

What you probably need to do is to create different packages for the different objects obtained for the different endpoints.

I feel your pain.

Cheers,
Viktor

On Tue, Jan 20, 2009 at 12:14 PM, Tim Perrett <hello@timperrett.com> wrote:

Guys,

In a little scala application I've written, Im calling a bunch of SOAP
services and making quite heavy use of reflection and manifests to load the
various SOAP endpoint drivers etc etc.

Now im being told that I have to support a legacy version of those SOAP
endpoints as well - this obviously causes a problem, as my current setup
makes use of parameterized types, but if there are two possible endpoints
(new or legacy), it does not know which type to pass. I then thought that I
would just wrap it all up with an object and a set of vals so the code
doesn't care if its legacy or new, but this is throwing the compiler as if I
do not provide a type setting it thinks they are java.lang.Object instances
rather than the passed type instance.

Is there a way of telling Drivers.production that it could be type A or type
B?

object Drivers {
 ...
 // this makes the compiller blow for anything
 // that calls Drivers.production as it cant
 // determine the type
 val production = legacy_? match {
   case true => LegacyDriver()
   case _ => NormalDriver()
 }
}

object NormalDriver extends EndpointBase[Production,ProductionSoap]{
 val name: String = "normal"
}

object LegacyDriver extends
EndpointBase[LegacyProduction,LegacyProductionSoap]{
 val name: String = "normal"
}


Thanks in advance

Cheers

Tim

--
Viktor Klang
Senior Systems Analyst

Re: [scala-user] Passing the compiler with runtime types
After spending most of the day trying to make this work, I really think its not going to be possible without some serious refactoring to accommodate this late change.

Its actually going to be cheaper to just get the client using our legacy API to upgrade so there no longer legacy. Nightmare.

The joys of SOAP ;-)

Cheers

Tim

On 20/01/2009 16:30, "Viktor Klang" <viktor [dot] klang [at] gmail [dot] com" rel="nofollow">viktor.klang@gmail.com> wrote:

Welcome to the world of "Why SOAP should die a horrible death"

What you probably need to do is to create different packages for the different objects obtained for the different endpoints.

I feel your pain.

Cheers,
Viktor

On Tue, Jan 20, 2009 at 12:14 PM, Tim Perrett <hello [at] timperrett [dot] com" rel="nofollow">hello@timperrett.com> wrote:
..com">hello@timperrett.com> wrote:

Guys,

In a little scala application I've written, Im calling a bunch of SOAP
services and making quite heavy use of reflection and manifests to load the
various SOAP endpoint drivers etc etc.

Now im being told that I have to support a legacy version of those SOAP
endpoints as well - this obviously causes a problem, as my current setup
makes use of parameterized types, but if there are two possible endpoints
(new or legacy), it does not know which type to pass. I then thought that I
would just wrap it all up with an object and a set of vals so the code
doesn't care if its legacy or new, but this is throwing the compiler as if I
do not provide a type setting it thinks they are java.lang.Object instances
rather than the passed type instance.

Is there a way of telling Drivers.production that it could be type A or type
B?

object Drivers {
  ...
  // this makes the compiller blow for anything
  // that calls Drivers.production as it cant
  // determine the type
  val production = legacy_? match {
    case true => LegacyDriver()
    case _ => NormalDriver()
  }
}

object NormalDriver extends EndpointBase[Production,ProductionSoap]{
  val name: String = "normal"
}

object LegacyDriver extends
EndpointBase[LegacyProduction,LegacyProductionSoap]{
  val name: String = "normal"
}


Thanks in advance

Cheers

Tim

Volunteer to help them out ;)

On Tue, Jan 20, 2009 at 5:44 PM, Tim Perrett <hello@timperrett.com> wrote:

After spending most of the day trying to make this work, I really think its not going to be possible without some serious refactoring to accommodate this late change.

Its actually going to be cheaper to just get the client using our legacy API to upgrade so there no longer legacy. Nightmare.

The joys of SOAP ;-)

Cheers

Tim

On 20/01/2009 16:30, "Viktor Klang" <viktor [dot] klang [at] gmail [dot] com" target="_blank" rel="nofollow">viktor.klang@gmail.com> wrote:

Welcome to the world of "Why SOAP should die a horrible death"

What you probably need to do is to create different packages for the different objects obtained for the different endpoints.

I feel your pain.

Cheers,
Viktor

On Tue, Jan 20, 2009 at 12:14 PM, Tim Perrett <hello [at] timperrett [dot] com" target="_blank" rel="nofollow">hello@timperrett.com> wrote:

Guys,

In a little scala application I've written, Im calling a bunch of SOAP
services and making quite heavy use of reflection and manifests to load the
various SOAP endpoint drivers etc etc.

Now im being told that I have to support a legacy version of those SOAP
endpoints as well - this obviously causes a problem, as my current setup
makes use of parameterized types, but if there are two possible endpoints
(new or legacy), it does not know which type to pass. I then thought that I
would just wrap it all up with an object and a set of vals so the code
doesn't care if its legacy or new, but this is throwing the compiler as if I
do not provide a type setting it thinks they are java.lang.Object instances
rather than the passed type instance.

Is there a way of telling Drivers.production that it could be type A or type
B?

object Drivers {
  ...
  // this makes the compiller blow for anything
  // that calls Drivers.production as it cant
  // determine the type
  val production = legacy_? match {
    case true => LegacyDriver()
    case _ => NormalDriver()
  }
}

object NormalDriver extends EndpointBase[Production,ProductionSoap]{
  val name: String = "normal"
}

object LegacyDriver extends
EndpointBase[LegacyProduction,LegacyProductionSoap]{
  val name: String = "normal"
}


Thanks in advance

Cheers

Tim

--
Viktor Klang
Senior Systems Analyst