Announcement Announcement Module
Collapse
No announcement yet.
Registering a Editor for use with GatewayProxyFactoryBean Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Registering a Editor for use with GatewayProxyFactoryBean

    Hello all.

    I have a situation here where the GatewayProxyFactoryBean is invoking a convertIfNecessary method on a SimpleTypeConverter that delegates to a TypeConverterDelegate that finally tries to convert my message payload. (uff, why can't these things be more simple and straightforward???)

    Now my payload is a custom object that has no converters, so I have a error. Then I wrote a PropertyEditor to handle that. Finnaly, I see no way of registering my editor with the propertyEditorRegistry that the said TypeConverterDelegate uses. (uff again...)

    I'm sure that is my fault and/or ignorance, but how the &*$^ can I do such a thing that I naively thought it was simple?

    Thanks in advance.

  • #2
    You need to use a http://static.springframework.org/sp...onfigurer.html. OR you can put the PropertyEditor in the same package as the type you're trying to convert.

    Ignorance is bliss

    This is mostly Spring Core stuff, so it's not likely going to change. Can you explain why you need to convert your payload? It would be interesting to see how we can make things simpler.

    Comment


    • #3
      Well, I did try to put the MyClassEditor in the same package as MyClass, but that didn't work. Then I extended a PropertyEditorManager and declared it as a bean with the searchpath as a bean property, but that didn't work either...

      Now I did see that this is Spring Core, but I posted here because, and this is the funny part, I don't need that %(*%(&^% object to be converted, but I don't know why the SI GatewayProxyFactoryBean thinks it needs conversion...

      Basically, sometimes when I'm expecting a Object value what I really get is a null value, so in that cases I put a dummy NullObject in the payload. It's just a object whose toString() outputs "null".

      And that's this object that I don't want to convert that the GatewayProxyFactoryBean tries to convert...

      Any clues here?

      Thanks.

      Comment


      • #4
        Can you show the interface definition that is being used by the GatewayProxyFactoryBean?

        Comment


        • #5
          Nothing fancy, something like (annotated with Jersey)

          Code:
          @Path("/data")
          public interface DataService {
          	@GET
          	@Path("/data/{entity}/{key}")
          	@Produces("text/xml")
          	String read(@PathParam("entity")String entity, @PathParam("key")String key);
          }
          Then, the service handler invokes the implementation method, like this

          Code:
          		Object[] objs = (Object[]) message.getPayload();
          		Method method = methods.get(message.getHeaders().get("internal.header.invokedmethod"));
          		Object response = ReflectionUtils.invokeMethod(method, service, objs);
          		return response == null ? new GenericMessage<Object>(new NullObject()) : new GenericMessage<Object>(response);
          Now this situation returns a String, but in other situations I had "custom" objects being returned without any problem. Only this NullObject gives the problem...

          Comment


          • #6
            OK. Can you also provide the stack trace for the Exception you're getting?

            Thanks.

            Comment


            • #7
              I can't, sorry...

              However I trace the problem up to TypeConverterDelegate
              Code:
              if (!ClassUtils.isAssignableValue(requiredType, convertedValue)) {
                // Definitely doesn't match: throw IllegalArgumentException.
              where

              requiredType = String
              convertedValue = NullObject

              So the problem will be solved (I think) as soon as I discover the hidden and complicated way to register my NullObjectEditor...

              Comment


              • #8
                Actually, I think the problem is more complex, as the Editors only cover the cases of Object<->String and not Object<->Object, so in general this is quite complicated. But I have to leave it for now, no time to do it...

                When I get back to this I'll post my findings here...

                Comment


                • #9
                  Thank you. Please do post back here. Simple customization of type-conversion is something that we want to provide, and your experience may lead to some good ideas.

                  Comment

                  Working...
                  X