- This topic has 12 replies, 3 voices, and was last updated 16 years, 9 months ago by Riyad Kalla.
-
AuthorPosts
-
imurilloMemberAfter having tried just about anything possible I still have the following error when I try to get a LIST from a web service.
The error:
20:45:07,625 INFO [DefaultFaultHandler] Fault occurred!
org.codehaus.xfire.fault.XFireFault: No write method for property {http://v2.geoservicios.com}entLeyenda in class com.geoservicios.v2.ArrayOfEntLeyenda
at org.codehaus.xfire.aegis.type.basic.BeanType.writeProperty(BeanType.java:308)
at org.codehaus.xfire.aegis.type.basic.BeanType.readObject(BeanType.java:192)
at org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBindingProvider.java:154)
at org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding.java:206)
at org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBinding.java:50)
at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64)
at org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38)
at org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireServletController.java:301)
at org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:130)
at org.codehaus.xfire.transport.http.XFireServlet.doPost(XFireServlet.java:116)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)***************************************************************************************************
The code for the list bean:
package com.geoservicios.v2;import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlType;/**
* <p>Java class for ArrayOfEntLeyenda complex type.
*
* <p>The following schema fragment specifies the expected content contained within this class.
*
* <pre>
* <complexType name=”ArrayOfEntLeyenda”>
* <complexContent>
* <restriction base=”{http://www.w3.org/2001/XMLSchema}anyType”>
* <sequence>
* <element name=”EntLeyenda” type=”{http://www.geoservicios.com/v2.0}EntLeyenda” maxOccurs=”unbounded” minOccurs=”0″/>
* </sequence>
* </restriction>
* </complexContent>
* </complexType>
* </pre>
*
*
*/
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = “ArrayOfEntLeyenda”, propOrder = {
“entLeyenda”
})
public class ArrayOfEntLeyenda {@XmlElement(name = “EntLeyenda”, required = true, nillable = true)
protected List<EntLeyenda> entLeyenda;/**
* Gets the value of the entLeyenda property.
*
* <p>
* This accessor method returns a reference to the live list,
* not a snapshot. Therefore any modification you make to the
* returned list will be present inside the JAXB object.
* This is why there is not a <CODE>set</CODE> method for the entLeyenda property.
*
* <p>
* For example, to add a new item, do as follows:
* <pre>
* getEntLeyenda().add(newItem);
* </pre>
*
*
* <p>
* Objects of the following type(s) are allowed in the list
* {@link EntLeyenda }
*
*
*/
public List<EntLeyenda> getEntLeyenda() {
if (entLeyenda == null) {
entLeyenda = new ArrayList<EntLeyenda>();
}
return this.entLeyenda;
}}
**********************************************************************************************The code for the individual entries in the list:
Note: the individual entries work just fine!
package com.geoservicios.v2;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlType;/**
* <p>Java class for EntLeyenda complex type.
*
* <p>The following schema fragment specifies the expected content contained within this class.
*
* <pre>
* <complexType name=”EntLeyenda”>
* <complexContent>
* <restriction base=”{http://www.w3.org/2001/XMLSchema}anyType”>
* <sequence>
* <element name=”Secuencia” type=”{http://www.w3.org/2001/XMLSchema}int”/>
* <element name=”Orden” type=”{http://www.w3.org/2001/XMLSchema}int”/>
* <element name=”Nombre” type=”{http://www.w3.org/2001/XMLSchema}string” minOccurs=”0″/>
* <element name=”Descripcion” type=”{http://www.w3.org/2001/XMLSchema}string” minOccurs=”0″/>
* <element name=”Visible” type=”{http://www.w3.org/2001/XMLSchema}boolean”/>
* <element name=”Editable” type=”{http://www.w3.org/2001/XMLSchema}boolean”/>
* <element name=”Estilo” type=”{http://www.w3.org/2001/XMLSchema}string” minOccurs=”0″/>
* <element name=”RangoMin” type=”{http://www.w3.org/2001/XMLSchema}long”/>
* <element name=”RangoMax” type=”{http://www.w3.org/2001/XMLSchema}long”/>
* <element name=”CampoEtiqueta” type=”{http://www.w3.org/2001/XMLSchema}string” minOccurs=”0″/>
* <element name=”FuenteEtiqueta” type=”{http://www.w3.org/2001/XMLSchema}string” minOccurs=”0″/>
* <element name=”CamposSeleccion” type=”{http://www.w3.org/2001/XMLSchema}string” minOccurs=”0″/>
* <element name=”TextosDuplicados” type=”{http://www.w3.org/2001/XMLSchema}boolean”/>
* <element name=”Opacidad” type=”{http://www.w3.org/2001/XMLSchema}unsignedByte”/>
* </sequence>
* </restriction>
* </complexContent>
* </complexType>
* </pre>
*
*
*/
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = “EntLeyenda”, propOrder = {
“secuencia”,
“orden”,
“nombre”,
“descripcion”,
“visible”,
“editable”,
“estilo”,
“rangoMin”,
“rangoMax”,
“campoEtiqueta”,
“fuenteEtiqueta”,
“camposSeleccion”,
“textosDuplicados”,
“opacidad”
})
public class EntLeyenda {@XmlElement(name = “Secuencia”)
protected int secuencia;
@XmlElement(name = “Orden”)
protected int orden;
@XmlElement(name = “Nombre”)
protected String nombre;
@XmlElement(name = “Descripcion”)
protected String descripcion;
@XmlElement(name = “Visible”)
protected boolean visible;
@XmlElement(name = “Editable”)
protected boolean editable;
@XmlElement(name = “Estilo”)
protected String estilo;
@XmlElement(name = “RangoMin”)
protected long rangoMin;
@XmlElement(name = “RangoMax”)
protected long rangoMax;
@XmlElement(name = “CampoEtiqueta”)
protected String campoEtiqueta;
@XmlElement(name = “FuenteEtiqueta”)
protected String fuenteEtiqueta;
@XmlElement(name = “CamposSeleccion”)
protected String camposSeleccion;
@XmlElement(name = “TextosDuplicados”)
protected boolean textosDuplicados;
@XmlElement(name = “Opacidad”)
protected short opacidad;/**
* Gets the value of the secuencia property.
*
*/
public int getSecuencia() {
return secuencia;
}
more getters and setters …
*****************************************************************************************************The service.xml:
<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://xfire.codehaus.org/config/1.0″><service>
<name>ImefeService</name>
<serviceClass>com.sgn.servicios.IImefeService</serviceClass>
<implementationClass>
com.sgn.servicios.ImefeServiceImpl
</implementationClass>
<style>wrapped</style>
<use>literal</use>
<scope>session</scope>
</service>
</beans>
******************************************************************************************************Could anyone please help concerning the “No write method for property” for property error and any work around.
Thanks in advance
Riyad KallaMemberIt’s a bug in XFire, will be fixed in 1.2.7:
http://jira.codehaus.org/browse/XFIRE-509
imurilloMemberI’ve already voted guys!
Thanks for your prompt reply.
Is there any known workaround.
Riyad KallaMemberimurillo,
I am not sure, it would be in the bug report if there is one, but the XFire team releases pretty often so that 1.2.7 release should be out soon.
imurilloMemberRiyad,
I hope this is fixed soon because it’s seriously affecting my work (THE BOSS’S FAVORITE BUG!).
Cheers and thanks again.
Dave StubbsMemberIs there any update on this. My developers are all finding that the setter methods are not being produced on the Web Services where maxoccurs=”unbounded” and it’s a serious impact on source control to have to manually re-add all the setters back in by hand after regenerating the classes from the wsdl.
As far as I can tell, XFire haven’t produced a release since 1.3.6 and this reflects badly on myeclipse IDE as I assume your now going to have to impliment a replacement.
Riyad KallaMemberZentive,
I don’t think this issue was addressed yet in our most recent release (I can’t pin point a PR that addresses it).As far as the XFire issue, we are moving our Web Services support to focus on the JAX-WS standard moving forward now that it’s there and mature, and more and more customers are demanding it from us. It’s similar to how there was a lot of “this or that” about persistence technologies until JPA came out and became the standard, now implementors and companies can target their efforts against a single standard, as can we. And just focus our efforts on providing kick-ass tools against those standards.
Dave StubbsMemberCan you point me at the tooling your planning to base this around. I’m keen to get our developers up to speed with whatever the technology it is your using ASAP and not to invest any more time in XFire as it’s clearly now been mothballed and the apache project being in Incubator is too high a risk to take currently.
Do you have the new JAX-WS integration on roadmap yet, I’ve read that your putting it in the BLUE release, but we won’t be interested in tying in to WebSphere in any way, it’s not mentioned on the roadmap web page as being a part of any other release.
When can we expect to begin testing with it?
Riyad KallaMemberZentive,
You are right the initial incarnation of it will be in MyEclipse Blue 6.1 release (in March) and then it is our plan to generalize that work with JAX-WS support for the MyEclipse 6.5 release a few months after that, but we will have milestones before that to use.I don’t have more details right now as management hasn’t commented on them. They are heads-down until Blue is out.
I know that one of our targetted servers for the JAX-WS work will definitely be Glassfish 2/Sun App Server 9.1 and supporting smooth operation with that environment as we did with EJB3. Certainly it will work with any JAX-WS compliant server but if that information helps I wanted to pass it along.
Dave StubbsMemberThanks, however I have a real problem with this.
Many of our customers are very large corperate organisations that have made large investments in Application servers, predominantly Websphere 4,5 & 6, none of which has JDK 5 support.
By constantly replacing the components in MyEclipse IDE we find it increasingly difficult to get the benefits of newer and better tooling but still maintain product compatibility with our clients application server environments.
The technology moves on and rightly we need the tooling for it, but I can’t afford to loose the tooling we are using to support older installations (especially when the cost of upgrading multiple App Server farms is so expensive).
It’s a shame we have to keep old versions of Eclipse & MyEclipse around just to be able to support 90% of our customer base while we develop new applications on another environment for the other 10%. It’s not easy to manage.
What is the Genuitec strategy for tools development and support. Is backward compatibility just something you can’t afford to do?
It’s probably true to say that every other IDE suffers the same problems of keeping up with the latest tech, it’s just in the real world we have to support such a spread of clients that this becomes a challenge that the tooling doesn’t help us to solve.
Riyad KallaMemberZentive, I’m sorry if I wasn’t clear with my original post, but we have *never* removed support for a technology from MyEclipse… ever (except for a really crappy Bugzilla view a few years ago that was totally replaced by Mylyn).
Just because we plan on adding support for JAX-WS doesn’t mean we are *removing* anything. Also we will be adding JAX-RPC support (services and clients) which works on WebSphere 5.1, 6.0 and 6.1 which might be a great fit for your customers.
If you need more information about anything just let me know and I’ll be happy to fill you in (on particular techs for example).
Dave StubbsMemberMy mistake. I assumed as XFire was no longer being developed or maintained it would not be included going forward.
I’m interested in the JAX-RPC support (well I’d prefer not to be but if I can’t get the customers to budge I’ve got no choice) I’ve not seen any reference to that. Is this going into the Blue and then the general release versions as well?
Riyad KallaMemberMy mistake. I assumed as XFire was no longer being developed or maintained it would not be included going forward.
We will keep our existing XFire support in good shape, and making any fixes or enhancements needed by our users, but you are right… in general the framework has now merged into a much bigger service stack… I don’t recall the name.
I’m interested in the JAX-RPC support (well I’d prefer not to be but if I can’t get the customers to budge I’ve got no choice) I’ve not seen any reference to that. Is this going into the Blue and then the general release versions as well?
As of now, it will be a Blue-only feature. I just wrapped up a web service/client tutorial for it today actually that will be part of the blue release. We should have M1 out of the gate early next week for you to try out if you want.
-
AuthorPosts