Cliente en OAS

Ya viste hasta abajo?

Caused by: java.lang.NoSuchMethodError: org.tempuri.ServiceSoap.fnRecibeValores(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/util/Calendar;)Ljava/lang/String;

Yo sospecho de alguna diferencia en classpaths, o diferencia de versiones de alguna biblioteca en el contenedor. Por ejemplo que si usas Axis, en Jboss viene una versión (que sí te funciona) y en OAS viene otra (que no te funciona).

Esa clase está rara porque el nombre suena muy genérico,   pero el nombre del método sí suena como algo que hiciste tú o que te dieron para que invoques,  . Será que se tiene que generar el stub en tiempo de ejecución y no se genera, o se genera mal, o distinto a lo que esperas...

El ear con el cliente que generamos apunta a productivo (la url WSDL no cambia) desde que se genera y en pruebas locales con OAS con la misma versión productiva si nos responde, salvo que el OAS de desarrollo es para Windows (donde si funcia) y la productiva esta en Linux #Fail

org.tempuri ?

URI temporal? Algo suena raro, como que hiciste ( hicieron ) copy/paste de algún código que se encontraron en internet.

Por lo que google dice o lo que logré entender, parece que ese org.tempuri se debe de reemplazar por tu URI correcta o algo así, aunque no me hace mucho sentido porque finalmente es el nombre de un paquete. Quizá ( y es pregunta ) la "herramienta" que usaron para generar el cliente toma en cuenta el nombre del paquete para generar un espacio de nombre o algo así. De ser esta la causa podría ser que no coincide con el dominio del servidor que está en producción. Pff... quién sabe.

En terminos generales:

NoSuchMethodError sucede cuando el código fue compilado y el método si fue encontrado, pero ahora ( en tiempo de ejecución ) el jar o la clase que tenía ese método cambio.

NoSuchMethodException ( que no es este caso ) sucede cuando a través de reflection se quiere acceder a un método que en realidad no existe.

Como en el stacktrace aparece el primero yo opino ( y casi sin saber ) que el problema está en que en el OAS de producción se instaló una versión incorrecta del cliente ( una versión que NO tenía el método   que recibe entre otras cosas un ¿java.util.Calendar? )

Espero que esto te ayude en algo

Edit El que uno corra en Windows y otro en Linux no tiene NADA QUE VER!, aunque esa haya sido tu primera reacción y/o la diferencia que lograste entender, no hay evidencia suficiente para que concluyas que esa es la razón. Hay muchos elementos más que influyen.

Lo menciono porque muchas veces resulta más fácil descartar algo por corazonada que ponerse a investigar la razón del fondo. No caigas en ese error, porque lo peor de todo es que no resuelves las cosas ( imaginate que logras que te pongan un servidor Windows en producción y después de mucha gestión ..... pues resulta que esa no era la causa )

Saludos.

No fue mi primera reacción, solo lo mencione en caso de que fuera relevante, lo de "#Fail" fue porque en el servidor de Linux es donde falla, no es porque tenga una preferencia hacia Wndows =S jaja de hecho yo uso Fedora, pero bueno. Tampoco pretendo que cambien el servidor a un Windows =S

Nosotros consumimos ese servicio, el cliente lo hicimos con Axis, ya tenemos otros clientes en ese mismo servidor que si funcionan.

Saludos y gracias =)

Ah vaya.

Y el OAS es donde está el servicio ? O donde está el cliente ? Ese stacktrace de donde es?

Yo pienso que lo que pasó es que no está bien instalado algo. Compilaron y al momento de hacer el deploy una clase o un ear se fue con una versión anterior. El primer lugar a revisar es precisamente a donde pertenezca ese stacktrace, si es del cliente pues del cliente si es del servicio pues en el servicio.

:)

El OAS es donde esta el cliente, la pila es del cliente. Por acá creemos que el problema es con el OAS, alguna librería o algo que le falte =S pero no estamos seguros de como cual podría ser