[jira] [Commented] (WSS-599) Upgrade to Java 8 DateTime API
[ https://issues.apache.org/jira/browse/WSS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360066#comment-17360066 ] Jochen Wiedmann commented on WSS-599: - If so, a possible workaround would be to use [https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME] would it? > Upgrade to Java 8 DateTime API > -- > > Key: WSS-599 > URL: https://issues.apache.org/jira/browse/WSS-599 > Project: WSS4J > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 2.2.0 > > > This task is to replace all java.util.Date, Calendar, XMLGregorianCalendar > plus the custom Date Formatter stuff with the new Java 8 DateTime API. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (WSCOMMONS-588) How can fetch the xml content from the HttpServletResponse?
[ https://issues.apache.org/jira/browse/WSCOMMONS-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved WSCOMMONS-588. --- Resolution: Invalid Please understand, that the ASF Jira is not a support forum. Your question is unrelated to any component in the ws.apache.org project, in particular not to WSCOMMONS. Please move your question to an appropriate platform, like the log4j2 users mailing list. (See https://logging.apache.org/log4j/2.x/mail-lists.html.) > How can fetch the xml content from the HttpServletResponse? > --- > > Key: WSCOMMONS-588 > URL: https://issues.apache.org/jira/browse/WSCOMMONS-588 > Project: WS-Commons > Issue Type: Wish > Components: General >Reporter: sivan > > PrintWriter pr = response.getWriter(); > code for processing the web service. > . > . > . > String url = "/" + page.getPath() + "/" + pagename; > sess.startPage(page, null, req, response); > RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(url); > dispatcher.include(req, response); > pr.close(); > This is the basic code we are using for processing the web service. > Here we are facing the difficulty of logging the response of the web service. > How we can retrieve the XML content from the response for logging? > We are using the log4j2 logger. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (XMLRPC-195) StringSerializer does not create string tag
[
https://issues.apache.org/jira/browse/XMLRPC-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501116#comment-13501116
]
Jochen Wiedmann commented on XMLRPC-195:
Quoting from the XML-RPC specification that you have referenced yourself below:
If no type is indicated, the type is string.
In other words: What Apache XML-RPC does, is a perfectly valid behaviour and
the error (if any) is on the side of the software which doesn't deal with that
properly.
A Google search for Apache XML RPC string tag quickly reveals possibly
workarounds, as detailed in the Apache XML RPC FAQ:
http://www.google.de/url?sa=trct=jq=esrc=ssource=webcd=3cad=rjaved=0CC8QFjACurl=http%3A%2F%2Fapache-xml.6118.n7.nabble.com%2FAdding-lt-string-gt-tag-in-XML-RPC-3-1-td29255.htmlei=hmmrUIWSB4nHswaqr4HoCgusg=AFQjCNFaJwfP155CYYU4xzFrtweumv_V1Q
Closing this as not a bug.
StringSerializer does not create string tag
-
Key: XMLRPC-195
URL: https://issues.apache.org/jira/browse/XMLRPC-195
Project: XML-RPC
Issue Type: Bug
Components: Source
Affects Versions: 3.1.3
Environment: Windows 7
Reporter: Gokulakrishnan
Priority: Critical
Consider a method call (API) named 'login' that takes in 4 parameters major
version (integer), minor version (integer), user name (string) and password
(string). Below code snippet explains how I invoke this remote API.
XmlRpcClient client = new XmlRpcClient();
Object[] loginParams = {new Integer(2), new Integer(0), new
String(u...@sample.com), new String(password)};
client.execute(login, loginParams);
The four parameters are wrapped as Object array to method call named 'login'.
Below is the XML generated and passed to server hosting login API:
methodCall
methodNamelogin/methodName
params
param
value
i42/i4
/value
/param
param
value
i40/i4
/value
/param
param
value
u...@sample.com
/value
/param
param
value
password
/value
/param
/params
/methodCall
As you notice the user name - u...@sample.com and password - password are
serialized without 'string' tag. Is this intentional. I referred the code
StringSerializer and noticed that 'string' tag is not passed to write
method. By XML-RPC specification http://xmlrpc.scripting.com/spec it should
have been:
:
value
string
u...@sample.com
/string
/value
:
Any specific reason for this change in behavior ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Closed] (XMLRPC-195) StringSerializer does not create string tag
[
https://issues.apache.org/jira/browse/XMLRPC-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann closed XMLRPC-195.
--
Resolution: Not A Problem
Assignee: Jochen Wiedmann
Works as specified, hence not a problem.
StringSerializer does not create string tag
-
Key: XMLRPC-195
URL: https://issues.apache.org/jira/browse/XMLRPC-195
Project: XML-RPC
Issue Type: Bug
Components: Source
Affects Versions: 3.1.3
Environment: Windows 7
Reporter: Gokulakrishnan
Assignee: Jochen Wiedmann
Priority: Critical
Consider a method call (API) named 'login' that takes in 4 parameters major
version (integer), minor version (integer), user name (string) and password
(string). Below code snippet explains how I invoke this remote API.
XmlRpcClient client = new XmlRpcClient();
Object[] loginParams = {new Integer(2), new Integer(0), new
String(u...@sample.com), new String(password)};
client.execute(login, loginParams);
The four parameters are wrapped as Object array to method call named 'login'.
Below is the XML generated and passed to server hosting login API:
methodCall
methodNamelogin/methodName
params
param
value
i42/i4
/value
/param
param
value
i40/i4
/value
/param
param
value
u...@sample.com
/value
/param
param
value
password
/value
/param
/params
/methodCall
As you notice the user name - u...@sample.com and password - password are
serialized without 'string' tag. Is this intentional. I referred the code
StringSerializer and noticed that 'string' tag is not passed to write
method. By XML-RPC specification http://xmlrpc.scripting.com/spec it should
have been:
:
value
string
u...@sample.com
/string
/value
:
Any specific reason for this change in behavior ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (XMLRPC-190) Cannot find XmlRpcServlet.properties file in war when packaged it in ear
[
https://issues.apache.org/jira/browse/XMLRPC-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105342#comment-13105342
]
Jochen Wiedmann commented on XMLRPC-190:
Try replacing
URL url = this.getServletContext().getResource(realPath);
with
URL url = Thread.currentThread().getContextClassLoader()getResource(realPath);
If this doesn't work either, please contact you application servers support
forum. This issue is not related to XML-RPC.
Cannot find XmlRpcServlet.properties file in war when packaged it in ear
Key: XMLRPC-190
URL: https://issues.apache.org/jira/browse/XMLRPC-190
Project: XML-RPC
Issue Type: Wish
Affects Versions: 3.1.3
Environment: linux / windows
Reporter: zappee
Priority: Minor
Labels: Failed, XmlRpcServlet.properties, locate, resource, to
Fix For: 3.0
Original Estimate: 1h
Remaining Estimate: 1h
Cannot find XmlRpcServlet.properties file in war when packaged it in ear.
Workaround:
---
You have to extend the original org.apache.xmlrpc.webserver.XmlRpcServlet
class and overwrite newXmlRpcHandlerMapping() method. After it you may use
your new class file in web.xml instead of the original
org.apache.xmlrpc.webserver.XmlRpcServlet class.
MyXmlRpcServlet.java:
public class MyXmlRpcServlet extends org.apache.xmlrpc.webserver.XmlRpcServlet
{
@Override
protected XmlRpcHandlerMapping newXmlRpcHandlerMapping() throws
XmlRpcException
{
String packageName =
this.getClass().getPackage().getName().replaceAll(\\., /);
String realPath = /WEB-INF/classes/ + packageName +
/XmlRpcServlet.properties;
try
{
URL url = this.getServletContext().getResource(realPath);
if (url == null)
{
throw new XmlRpcException(Failed to locate resource
XmlRpcServlet.properties);
}
return newPropertyHandlerMapping(url);
}
catch (IOException e)
{
throw new XmlRpcException(Failed to load resource + realPath +
: + e.getMessage(), e);
}
}
}
web.xml:
servlet
servlet-nameXmlRpcServlet/servlet-name
servlet-classcom.remal.xmlrpc.webserver.MyXmlRpcServlet/servlet-class
init-param
param-nameenabledForExtensions/param-name
param-valuetrue/param-value
description
Sets, whether the servlet supports vendor extensions for
XML-RPC.
/description
/init-param
/servlet
servlet-mapping
servlet-nameXmlRpcServlet/servlet-name
url-pattern/xmlrpc/url-pattern
/servlet-mapping
This solution is working in standalone war and/or war when packaged it in ear.
regards, Arnold Somogyi
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (XMLRPC-190) Cannot find XmlRpcServlet.properties file in war when packaged it in ear
[
https://issues.apache.org/jira/browse/XMLRPC-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved XMLRPC-190.
Resolution: Invalid
Not an XML-RPC issue.
Cannot find XmlRpcServlet.properties file in war when packaged it in ear
Key: XMLRPC-190
URL: https://issues.apache.org/jira/browse/XMLRPC-190
Project: XML-RPC
Issue Type: Wish
Affects Versions: 3.1.3
Environment: linux / windows
Reporter: zappee
Priority: Minor
Labels: Failed, XmlRpcServlet.properties, locate, resource, to
Fix For: 3.0
Original Estimate: 1h
Remaining Estimate: 1h
Cannot find XmlRpcServlet.properties file in war when packaged it in ear.
Workaround:
---
You have to extend the original org.apache.xmlrpc.webserver.XmlRpcServlet
class and overwrite newXmlRpcHandlerMapping() method. After it you may use
your new class file in web.xml instead of the original
org.apache.xmlrpc.webserver.XmlRpcServlet class.
MyXmlRpcServlet.java:
public class MyXmlRpcServlet extends org.apache.xmlrpc.webserver.XmlRpcServlet
{
@Override
protected XmlRpcHandlerMapping newXmlRpcHandlerMapping() throws
XmlRpcException
{
String packageName =
this.getClass().getPackage().getName().replaceAll(\\., /);
String realPath = /WEB-INF/classes/ + packageName +
/XmlRpcServlet.properties;
try
{
URL url = this.getServletContext().getResource(realPath);
if (url == null)
{
throw new XmlRpcException(Failed to locate resource
XmlRpcServlet.properties);
}
return newPropertyHandlerMapping(url);
}
catch (IOException e)
{
throw new XmlRpcException(Failed to load resource + realPath +
: + e.getMessage(), e);
}
}
}
web.xml:
servlet
servlet-nameXmlRpcServlet/servlet-name
servlet-classcom.remal.xmlrpc.webserver.MyXmlRpcServlet/servlet-class
init-param
param-nameenabledForExtensions/param-name
param-valuetrue/param-value
description
Sets, whether the servlet supports vendor extensions for
XML-RPC.
/description
/init-param
/servlet
servlet-mapping
servlet-nameXmlRpcServlet/servlet-name
url-pattern/xmlrpc/url-pattern
/servlet-mapping
This solution is working in standalone war and/or war when packaged it in ear.
regards, Arnold Somogyi
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Closed: (XMLRPC-172) CLONE -XML attribute issue for auto_unique ID auto_checksum with md5
[ https://issues.apache.org/jira/browse/XMLRPC-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann closed XMLRPC-172. -- Resolution: Invalid Assignee: Jochen Wiedmann CLONE -XML attribute issue for auto_unique ID auto_checksum with md5 -- Key: XMLRPC-172 URL: https://issues.apache.org/jira/browse/XMLRPC-172 Project: XML-RPC Issue Type: Wish Affects Versions: unspecified Environment: window xp, other thing i dont know because my background is not IT. Reporter: magnate Williams Assignee: Jochen Wiedmann Priority: Critical Fix For: unspecified Original Estimate: 504h Remaining Estimate: 504h I want to develop XML document with following DTD file with XML format. I have also XSL file as a externatl file to represent my xml in browser. my problem is i want to create AUTO unique ID checksum for each leaf element according to DTD. In my xml file there are more than 500 attachment each leaf have unique ID Checksum, and one more thing, after creating final XML, if i make any modification to original xml (i.e. operation (append | delete | new | replace) #REQUIRED ) i need to create cross reference (i.e. /AAA/00/index.xml#idMG1234 here previous attached file ID = MG1234 [means 'magnate-williams-1234] ) for new attached file. for life cycle of my xml, i want to create checksum for final index.xml file, that will be unique. main folder name = AAA sub foler to main = 00 new version folder = 01 next version folder = 02 and so on I need to all version folder create auto under main folder (AAA). Please help me out for the same. I am helpless for the same. Thanks in Advanced... DTD Part is: --- ?xml version=1.0 encoding=UTF-8? !ELEMENT root-root (element-1-1?, element-1-2?) !ATTLIST root-root xmlns:root CDATA #FIXED xmlns:xlink CDATA #FIXED xml:lang CDATA #IMPLIED dtd-version CDATA #FIXED !ELEMENT leaf (title, link-text?) !ATTLIST leaf ID ID #REQUIRED application-version CDATA #IMPLIED version CDATA #IMPLIED font-library CDATA #IMPLIED operation (append | delete | new | replace) #REQUIRED modified-file CDATA #IMPLIED checksum CDATA #REQUIRED checksum-type CDATA #REQUIRED keywords CDATA #IMPLIED xmlns:xlink CDATA #FIXED xlink:type CDATA #FIXED xlink:role CDATA #IMPLIED xlink:href CDATA #IMPLIED xlink:show (embed | none | other | new | replace) #IMPLIED xlink:actuate (onRequest | none | other | onLoad) #IMPLIED xml:lang CDATA #IMPLIED !ELEMENT title (#PCDATA) !ATTLIST title ID ID #IMPLIED !ELEMENT link-text (#PCDATA | xref)* !ATTLIST link-text ID ID #IMPLIED !ELEMENT xref EMPTY !ATTLIST xref ID ID #REQUIRED xmlns:xlink CDATA #FIXED xlink:type CDATA #FIXED xlink:role CDATA #IMPLIED xlink:title CDATA #REQUIRED xlink:href CDATA #REQUIRED xlink:show (embed | none | other | new | replace) #IMPLIED xlink:actuate (onRequest | none | other | onLoad) #IMPLIED !ELEMENT node-extension (title, (leaf | node-extension)+) !ATTLIST node-extension ID ID #IMPLIED xml:lang CDATA #IMPLIED !ELEMENT element-1-1 (leaf*) !ATTLIST element-1-1 ID ID #IMPLIED xml:lang CDATA #IMPLIED !ELEMENT element-1-2 (leaf*, element-1-2-1?, element-1-2-2?, ___?, __?, element-1-2-n?) !ATTLIST element-1-2 ID ID #IMPLIED xml:lang CDATA #IMPLIED !ELEMENT element-1-2-1 ((leaf | node-extension)*) !ATTLIST element-1-2-1 ID ID #IMPLIED xml:lang CDATA #IMPLIED . . . . !ELEMENT element-1-2-n ((leaf | node-extension)*) !ATTLIST element-1-2-n ID ID #IMPLIED xml:lang CDATA #IMPLIED _ - _ XML Part is : ?xml version=1.0 encoding=UTF-8? !DOCTYPE ectd:ectd SYSTEM ich-ectd-3-2.dtd root-root element-1-1 leaf operation= ID= checksum-type= checksum= title/ link-text xref xlink:title= xlink:href= ID=/ /link-text /leaf /element-1-1 element-1-2 leaf operation= ID= checksum-type= checksum= title/ link-text xref xlink:title= xlink:href= ID=/ /link-text /leaf
[jira] Resolved: (XMLRPC-135) intercept method calls (on the client and on the server side)
[
https://issues.apache.org/jira/browse/XMLRPC-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved XMLRPC-135.
Resolution: Won't Fix
Assignee: Jochen Wiedmann
After 3 years, noone interested in working on this. Closing.
intercept method calls (on the client and on the server side)
-
Key: XMLRPC-135
URL: https://issues.apache.org/jira/browse/XMLRPC-135
Project: XML-RPC
Issue Type: Improvement
Affects Versions: 3.0, 3.1
Reporter: Mario Linke
Assignee: Jochen Wiedmann
This extension is to integrate cross-cutting concerns (AOP), how stopping the
time, logging or transform args and return value.
public interface Interceptor {
public void beforeMethodInvocation (InterceptorContext
pInterceptorContext);
public void afterMethodInvocation (InterceptorContext
pInterceptorContext);
public void onError (Throwable pThrowable);
}
public final class InterceptorContext {
private Method method = null;
private Object[] args = null;
private Object result = null;
}
InterceptorContext is analog to the XmlRpcRequest, extended to the result
and the method object.
Extend the XmlRpcController to register the Interceptors:
- addInterceptor
- removeInterceptor
- getInterceptorByNumber
and delegate before and after event:
by the client to XmlRpcWorker
by the server to the XmlRpcHandler
Mario
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Resolved: (XMLRPC-182) PropertyHandlerMapping should allow unprefixed names
[ https://issues.apache.org/jira/browse/XMLRPC-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved XMLRPC-182. Resolution: Fixed Fix Version/s: 3.1.4 Assignee: Jochen Wiedmann Applied, thank you! PropertyHandlerMapping should allow unprefixed names Key: XMLRPC-182 URL: https://issues.apache.org/jira/browse/XMLRPC-182 Project: XML-RPC Issue Type: Improvement Components: Source Affects Versions: 3.1.3 Reporter: Oliver Wagner Assignee: Jochen Wiedmann Priority: Minor Fix For: 3.1.4 Currently PropertyHandlerMapping will always register method names with the form pKey.methodname, there is no way to create a method without prefix. Even when pKey is null, the name generated will be null.methodname. Similiar to the recent change on the client side, I propose to change name generation to not generate a prefix if pKey is null, e.g. in registerPublicMethods(): String name=(pKey!=null)?(pKey + . + method.getName()):method.getName(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Resolved: (JAXME-105) can't generate get list method with element has maxOccurs=unbounded
[ https://issues.apache.org/jira/browse/JAXME-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved JAXME-105. --- Assignee: Jochen Wiedmann Resolution: Invalid I assume, that you mean no corresponding set method generated? If so, that's perfectly as requested by the JAXB spec, thus an intentional behaviour. To set your elements, use object.getAddress().clear(); object.getAddress().addAll(myAddresses); can't generate get list method with element has maxOccurs=unbounded - Key: JAXME-105 URL: https://issues.apache.org/jira/browse/JAXME-105 Project: JaxMe Issue Type: Bug Components: JaxMe Core Affects Versions: current (nightly) Environment: wiindow xp, j2se 1.6 Reporter: chan tsz yeung Assignee: Jochen Wiedmann Fix For: current (nightly) Dear all, I have a xsd file. One of the element contains maxOccurs=unbounded tag. However, after running ant with default build.xml. The generated interface file only contains public java.util.List getAddress(); function but no corresponding get method generated. Could you please advise? Thanks. Stephen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: jaxme-dev-unsubscr...@ws.apache.org For additional commands, e-mail: jaxme-dev-h...@ws.apache.org
[jira] Resolved: (JAXME-104) wrong xsd:pattern handling
[ https://issues.apache.org/jira/browse/JAXME-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved JAXME-104. --- Resolution: Fixed Fix Version/s: 0.6 Assignee: Jochen Wiedmann Applied, thank you! wrong xsd:pattern handling -- Key: JAXME-104 URL: https://issues.apache.org/jira/browse/JAXME-104 Project: JaxMe Issue Type: Bug Components: JaxMe Core Affects Versions: 0.6 Reporter: Tobias Hühner Assignee: Jochen Wiedmann Fix For: 0.6 Attachments: TestMatches.patch, Types_StringSG.patch If an schema defines more then one xsd:pattern / type. The generated code shows not the correct behaviour. More then one pattern restriction means 'OR' . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: jaxme-dev-unsubscr...@ws.apache.org For additional commands, e-mail: jaxme-dev-h...@ws.apache.org
[jira] Resolved: (JAXME-102) No support for types of the same name in different namepaces
[
https://issues.apache.org/jira/browse/JAXME-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved JAXME-102.
---
Resolution: Won't Fix
Using jaxb:property is the way to resolve such conflicts that the specification
endorses. Everything else would violate the specification.
No support for types of the same name in different namepaces
Key: JAXME-102
URL: https://issues.apache.org/jira/browse/JAXME-102
Project: JaxMe
Issue Type: Bug
Components: JaxMeXS
Affects Versions: 0.5
Reporter: Christian Koppen
Attachments: testdata.zip
JAXME produces invalid Java source files when the input schemas contain types
with the same name in different namespaces.
Example:
First schema:
schema targetNamespace=http://a; xmlns=http://www.w3.org/2001/XMLSchema;
complexType abstract=true name=T /
/schema
Second schema:
schema targetNamespace=http://b; xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:a=http://a;
import namespace=http://a; schemaLocation=a.xsd /
complexType abstract=true name=T
complexContent
extension base=a:T /
/complexContent
/complexType
/schema
Generated java source file ObjectFactory.java contains:
public a.T createT() throws javax.xml.bind.JAXBException { ... }
public b.T createT() throws javax.xml.bind.JAXBException { ... }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: jaxme-dev-unsubscr...@ws.apache.org
For additional commands, e-mail: jaxme-dev-h...@ws.apache.org
[jira] Resolved: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error
[ https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved AXIS-2574. --- Resolution: Fixed Assignee: Jochen Wiedmann Applied to the Axis trunk. Reading an attachment (slowly) can cause resource deleted error --- Key: AXIS-2574 URL: https://issues.apache.org/jira/browse/AXIS-2574 Project: Axis Issue Type: Bug Components: Basic Architecture Affects Versions: 1.2.1 Reporter: Steve Sowerby Assignee: Jochen Wiedmann Attachments: axis-2574.patch, Call.diff, Call.diff, Call.java When reading the data from an attachment we periodically get the following error: java.io.IOException: Resource has been deleted. at org.apache.axis.attachments.ManagedMemoryDataSource$Instream.read(ManagedMemoryDataSource.java:688) Having run this throught a debugger and had a brief look at the code it seems to me there is a race condition of sorts. The MemoryManagedDataSource that provides the InputStream has been marked as deleted by the finalize method of AttachmentPart. So basically if the client doesn't read off the attachment fast enough then the writer will have finished and the AttachmentPart gets finalized and blam, you've got a deleted MemoryManagedDataSource. I'm not sure what the best fix is. Perhaps the deletion should actually be some reference count rather than a simple boolean. That way the MemoryManagedDataSource gets deleted once all the writers and readers are done? Although perhaps then there would be an issue if the client was very slow to even open the attachment? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error
[ https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated AXIS-2574: -- Attachment: axis-2574.patch Updated version of Rodrigos patch. Reading an attachment (slowly) can cause resource deleted error --- Key: AXIS-2574 URL: https://issues.apache.org/jira/browse/AXIS-2574 Project: Axis Issue Type: Bug Components: Basic Architecture Affects Versions: 1.2.1 Reporter: Steve Sowerby Attachments: axis-2574.patch, Call.diff, Call.diff, Call.java When reading the data from an attachment we periodically get the following error: java.io.IOException: Resource has been deleted. at org.apache.axis.attachments.ManagedMemoryDataSource$Instream.read(ManagedMemoryDataSource.java:688) Having run this throught a debugger and had a brief look at the code it seems to me there is a race condition of sorts. The MemoryManagedDataSource that provides the InputStream has been marked as deleted by the finalize method of AttachmentPart. So basically if the client doesn't read off the attachment fast enough then the writer will have finished and the AttachmentPart gets finalized and blam, you've got a deleted MemoryManagedDataSource. I'm not sure what the best fix is. Perhaps the deletion should actually be some reference count rather than a simple boolean. That way the MemoryManagedDataSource gets deleted once all the writers and readers are done? Although perhaps then there would be an issue if the client was very slow to even open the attachment? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAXME-100) Can't have attribute and element with the same name
[ https://issues.apache.org/jira/browse/JAXME-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved JAXME-100. --- Resolution: Invalid Assignee: Jochen Wiedmann Use jaxb:property name=SomeElement/ on either element or attribute. See http://java.sun.com/webservices/docs/1.5/tutorial/doc/JAXBUsing4.html for details. And, please, use the mailing list and not the bug tracking system for support. Can't have attribute and element with the same name --- Key: JAXME-100 URL: https://issues.apache.org/jira/browse/JAXME-100 Project: JaxMe Issue Type: Bug Components: JaxMe Core Affects Versions: 0.5 Reporter: Arnout Engelen Assignee: Jochen Wiedmann I'm describing a webservice containing an element that has an 'artist' attribute as well as an 'artist' child element. Is it possible to model that? When doing it the traditional way I get 'The class net.bzzt.lastfmlib.model.impl.SimilarartistsTypeImpl already has a field _artist.' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAXME-99) Generate 'Serializable' implementation classes
[ https://issues.apache.org/jira/browse/JAXME-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved JAXME-99. -- Resolution: Invalid Assignee: Jochen Wiedmann Use xjc:serializable. See http://java.sun.com/webservices/docs/1.6/jaxb/vendorCustomizations.html for details. And, please, don't use the issue tracking system for support. That's what the mailing lists are for. Generate 'Serializable' implementation classes -- Key: JAXME-99 URL: https://issues.apache.org/jira/browse/JAXME-99 Project: JaxMe Issue Type: Improvement Components: JaxMe Core Reporter: Arnout Engelen Assignee: Jochen Wiedmann In most simple cases, the generated Impl classes will be Serializable. It would be very nice if this was made explicit by making them implement java.io.Serializable -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAXME-95) JavaParser.parseObject() handles inner interfaces incorrectly
[ https://issues.apache.org/jira/browse/JAXME-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved JAXME-95. -- Resolution: Fixed Applied, thank you! JavaParser.parseObject() handles inner interfaces incorrectly - Key: JAXME-95 URL: https://issues.apache.org/jira/browse/JAXME-95 Project: JaxMe Issue Type: Bug Components: JaxMeJS Affects Versions: 0.5 Environment: N/A Reporter: David Karnok Assignee: Jochen Wiedmann Original Estimate: 0h Remaining Estimate: 0h In JavaParser.parseObject (468) the case JavaTokenTypes.INTERFACE_DEF: parseClassDefinition(pSource, JavaSource.CLASS, child); break; seems to be the copy-paste of the case JavaTokenTypes.CLASS_DEF: definition and therefore causes IllegalStateException when tries to parse an internal interface. The obvious correction would be to use JavaSource.INTERFACE instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-2676) Issues using two different implementations of JABX in Axis and WS
[ https://issues.apache.org/jira/browse/AXIS2-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved AXIS2-2676. Resolution: Won't Fix Issues using two different implementations of JABX in Axis and WS - Key: AXIS2-2676 URL: https://issues.apache.org/jira/browse/AXIS2-2676 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1.1 Environment: Reproduced on Mac OSX, Solaris 10, and Windows. Using Java 1.4.2 and 1.6 update 1. Reporter: Bruce Hitchcock Assignee: Jochen Wiedmann I believe there is a conflict issue when a client WS uses Apache JaxMe or JAXBI inside of Axis 2 1.1.1. My WS service successfully runs outside the container via junits. However, the following occurs when deployed inside Axis2 Here is a stack trace. The service operation is defined to take an xs:string and return an xs:string. Both are really XML however, the marshalling and unmarshalling is handled inside of XAOHelper. This is where the exception happens. I believe doesnt contain ObjectFactory.class or jaxb.index is particlular to the JAXB implementation inside the jar files include with Axis2 (Sun's impl ?) and not to Apache JaxMe. This might be and issue of not specifing and implementation at run time. Any help will be greatly appreciated. 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR com.comcast.cable.sams.tts.service.xao.XAOHelper - com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR com.comcast.cable.sams.tts.service.xao.XAOHelper - com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR org.apache.axis2.rpc.receivers.RPCMessageReceiver - javax.xml.bind.JAXBException: com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:118) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:497) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:328) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:254) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.Exception: javax.xml.bind.JAXBException: com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index at com.comcast.cable.sams.tts.service.xao.XAOHelper.marshall(Unknown Source) at com.comcast.cable.sams.tts.service.xao.handler.GetCustomerTicketResponseXAOHandler.beanToXml(Unknown Source) at
[jira] Commented: (JAXME-94) startElement method larger than 64KB when using a large amount of complexType's
[ https://issues.apache.org/jira/browse/JAXME-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524019 ] Jochen Wiedmann commented on JAXME-94: -- Had some time yesterday to inspect it. My first impressions: - This won't make it into the maintenance branch. Although the test suite runs fine, I would still consider this as a disruptive change. Such changes are reserved for the unstable branch. - I have a couple of performance issues. Some of them are basically nitpicks, but at least two of them are serious: * The regular expression pattern can be generated by the generator. It doesn't need to be generated at runtime. * The map and the compiled pattern can be static and created when the class is loaded. Question to Jose: Do you prefer to fix this for yourself or do you want me to change this? startElement method larger than 64KB when using a large amount of complexType's --- Key: JAXME-94 URL: https://issues.apache.org/jira/browse/JAXME-94 Project: JaxMe Issue Type: Improvement Components: JaxMe Core Affects Versions: 0.5, 0.6 Environment: All Reporter: Robert Eric Reeves Assignee: Jochen Wiedmann Priority: Critical Fix For: 0.5, 0.6 Attachments: test.xsd, veryLongSequences-patch-0.5.2.diff, veryLongSequences-patch-0.6-SNAPSHOT.diff Using an XSD that has a complexType with ~50 child complexTypes in a sequence, the generate Java code has a method startElement that is too large for javac. Jose Luis Huertas Fernández has created a patch to fix this error. I will be attaching it to this issue. There are two patches. One for 5.2 and the other for 6.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-2676) Issues using two different implementations of JABX in Axis and WS
[ https://issues.apache.org/jira/browse/AXIS2-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507272 ] Jochen Wiedmann commented on AXIS2-2676: As indicated, I suppose the problem is on the users side. So far no response. I'll close the issue in the next two weeks, should I still receive no reply. Issues using two different implementations of JABX in Axis and WS - Key: AXIS2-2676 URL: https://issues.apache.org/jira/browse/AXIS2-2676 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1.1 Environment: Reproduced on Mac OSX, Solaris 10, and Windows. Using Java 1.4.2 and 1.6 update 1. Reporter: Bruce Hitchcock Assignee: Jochen Wiedmann I believe there is a conflict issue when a client WS uses Apache JaxMe or JAXBI inside of Axis 2 1.1.1. My WS service successfully runs outside the container via junits. However, the following occurs when deployed inside Axis2 Here is a stack trace. The service operation is defined to take an xs:string and return an xs:string. Both are really XML however, the marshalling and unmarshalling is handled inside of XAOHelper. This is where the exception happens. I believe doesnt contain ObjectFactory.class or jaxb.index is particlular to the JAXB implementation inside the jar files include with Axis2 (Sun's impl ?) and not to Apache JaxMe. This might be and issue of not specifing and implementation at run time. Any help will be greatly appreciated. 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR com.comcast.cable.sams.tts.service.xao.XAOHelper - com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR com.comcast.cable.sams.tts.service.xao.XAOHelper - com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR org.apache.axis2.rpc.receivers.RPCMessageReceiver - javax.xml.bind.JAXBException: com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:118) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:497) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:328) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:254) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.Exception: javax.xml.bind.JAXBException: com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index at com.comcast.cable.sams.tts.service.xao.XAOHelper.marshall(Unknown Source) at
[jira] Commented: (AXIS2-2676) Issues using two different implementations of JABX in Axis and WS
[ https://issues.apache.org/jira/browse/AXIS2-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502081 ] Jochen Wiedmann commented on AXIS2-2676: First of all, let me recapitulate my understanding of the issue: Please verify whether I get this right so far. The user has generated classes using JaxMe. At runtime, the wrong implementation of JAXBContext is loaded. This implementation is looking for a file jaxb.index or an ObjectFactory class in the package com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse. At least the file isn't found, because JaxMe uses a file called Configuration.xml. The actual issue is the instantiation of the wrong JAXBContext. Basically, the classpath may safely contain as many JAXB implementations as you like as long as the proper implementation of JAXBContext is choosen. Choosing this implementation is controlled by a file com/comcast/cable/sams/tts/service/xao/getcustomerticketresponse/jaxb.properties with a property javax.xml.bind.context.factory So, my guess is that there's have another jaxb.properties file in the classpath.Perhaps you have experimented with the sun implementation and did not clean the path? Issues using two different implementations of JABX in Axis and WS - Key: AXIS2-2676 URL: https://issues.apache.org/jira/browse/AXIS2-2676 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1.1 Environment: Reproduced on Mac OSX, Solaris 10, and Windows. Using Java 1.4.2 and 1.6 update 1. Reporter: Bruce Hitchcock Assignee: Jochen Wiedmann Fix For: 1.1.1 I believe there is a conflict issue when a client WS uses Apache JaxMe or JAXBI inside of Axis 2 1.1.1. My WS service successfully runs outside the container via junits. However, the following occurs when deployed inside Axis2 Here is a stack trace. The service operation is defined to take an xs:string and return an xs:string. Both are really XML however, the marshalling and unmarshalling is handled inside of XAOHelper. This is where the exception happens. I believe doesnt contain ObjectFactory.class or jaxb.index is particlular to the JAXB implementation inside the jar files include with Axis2 (Sun's impl ?) and not to Apache JaxMe. This might be and issue of not specifing and implementation at run time. Any help will be greatly appreciated. 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR com.comcast.cable.sams.tts.service.xao.XAOHelper - com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR com.comcast.cable.sams.tts.service.xao.XAOHelper - com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index 2007-05-15 22:27:49,651 [http-8080-Processor25] ERROR org.apache.axis2.rpc.receivers.RPCMessageReceiver - javax.xml.bind.JAXBException: com.comcast.cable.sams.tts.service.xao.getcustomerticketresponse doesnt contain ObjectFactory.class or jaxb.index java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:118) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:497) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:328) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:254) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at
[jira] Resolved: (JAXME-92) JavaSource has at least two NPE sources
[ https://issues.apache.org/jira/browse/JAXME-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved JAXME-92. -- Resolution: Won't Fix This is obviously a matter of programming style and taste. The JavaJS framework is following a strict approach, where the user is responsible for passing meaningful parameters. Null isn't a meaningful parameter. JavaSource has at least two NPE sources --- Key: JAXME-92 URL: https://issues.apache.org/jira/browse/JAXME-92 Project: JaxMe Issue Type: Bug Components: JaxMeJS Affects Versions: 0.5 Environment: GNU/Linux 2.6.18-3-686 java-1.5.0-sun-1.5.0.10 Reporter: Marcel Patzlaff Priority: Minor The JavaSource methods isImplementing(Class pClass) and isExtending(Class pClass) should be protected against NPEs. They just have to return null if the requested fields (myImplements orextendedClasses) are null-references. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-2633) axis2-wsdl2code-maven-plugin missing extension option bindingfile for JiBX
[ https://issues.apache.org/jira/browse/AXIS2-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann reassigned AXIS2-2633: -- Assignee: Jochen Wiedmann axis2-wsdl2code-maven-plugin missing extension option bindingfile for JiBX Key: AXIS2-2633 URL: https://issues.apache.org/jira/browse/AXIS2-2633 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Affects Versions: 1.2 Environment: all platforms Reporter: Armin Ehrenfels Assigned To: Jochen Wiedmann axis2-wsdl2code-maven-plugin doesn't support extension options such as -Ebindingfile for JiBX. SUGGESTION: 1. in the plugin configuration, introducing an additional option extensionOptions, similar to namespaceURIs, like this: extensionOptions extensionOption namexxx/name valueyyy/value /extensionOption ... /extensionOptions 2. in the mojo, for each extension option adding the name/value pair to optionsMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-2429) Wrong dependency in axis2-wsdl2code-maven-plugin
[ https://issues.apache.org/jira/browse/AXIS2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann reassigned AXIS2-2429: -- Assignee: Jochen Wiedmann Wrong dependency in axis2-wsdl2code-maven-plugin Key: AXIS2-2429 URL: https://issues.apache.org/jira/browse/AXIS2-2429 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Affects Versions: 1.1.1 Environment: w2ksp4 jvm1.4.2_06 Reporter: Sergey Bespalov Assigned To: Jochen Wiedmann Priority: Critical First of all I have java.lang.NoClassDefFoundError: javax/wsdl/WSDLException when try to use it. Second I was really upset when I saw axiom-api-SNAPSHOT and axiom-parent-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-2128) Wrong type mapping in java2wsdl for java.math.BigDecimal
[
https://issues.apache.org/jira/browse/AXIS2-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann reassigned AXIS2-2128:
--
Assignee: Jochen Wiedmann
Wrong type mapping in java2wsdl for java.math.BigDecimal
Key: AXIS2-2128
URL: https://issues.apache.org/jira/browse/AXIS2-2128
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.1
Reporter: Mirko Zeibig
Assigned To: Jochen Wiedmann
Java2Wsdl generates 'xs:int' for 'java.math.BigDecimal' instead of
'xs:decimal'. This is wrong because of:
[Definition:] integer is - derived- from decimal by fixing the value of -
fractionDigits- to be 0and disallowing the trailing decimal point. This
results in the standard mathematical concept of the integer numbers. The -
value space- of integer is the infinite set {...,-2,-1,0,1,2,...}. The -
base type- of integer is decimal.
It is easy to fix in 'org.apache.ws.java2wsdl.utils.TypeTable' by adding this
line of code:
simpleTypetoxsd.put(java.math.BigDecimal, new
QName(Java2WSDLConstants.URI_2001_SCHEMA_XSD, decimal, xs));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-2128) Wrong type mapping in java2wsdl for java.math.BigDecimal
[
https://issues.apache.org/jira/browse/AXIS2-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved AXIS2-2128.
Resolution: Fixed
Already fixed in the trunk with revision 529296.
Wrong type mapping in java2wsdl for java.math.BigDecimal
Key: AXIS2-2128
URL: https://issues.apache.org/jira/browse/AXIS2-2128
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: Tools
Affects Versions: 1.1.1
Reporter: Mirko Zeibig
Assigned To: Jochen Wiedmann
Java2Wsdl generates 'xs:int' for 'java.math.BigDecimal' instead of
'xs:decimal'. This is wrong because of:
[Definition:] integer is - derived- from decimal by fixing the value of -
fractionDigits- to be 0and disallowing the trailing decimal point. This
results in the standard mathematical concept of the integer numbers. The -
value space- of integer is the infinite set {...,-2,-1,0,1,2,...}. The -
base type- of integer is decimal.
It is easy to fix in 'org.apache.ws.java2wsdl.utils.TypeTable' by adding this
line of code:
simpleTypetoxsd.put(java.math.BigDecimal, new
QName(Java2WSDLConstants.URI_2001_SCHEMA_XSD, decimal, xs));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-2429) Wrong dependency in axis2-wsdl2code-maven-plugin
[ https://issues.apache.org/jira/browse/AXIS2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved AXIS2-2429. Resolution: Fixed Looking at the current code (revision 533822), I note: - there are no direct dependencies on Axiom. Dependencies are inherited from exis2-kernel, etc. In other words: No need to change anything. - The NoClassDefFoundError cannot be reproduced. This is most possibly caused by the use of SNAPSHOT versions. Wrong dependency in axis2-wsdl2code-maven-plugin Key: AXIS2-2429 URL: https://issues.apache.org/jira/browse/AXIS2-2429 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Affects Versions: 1.1.1 Environment: w2ksp4 jvm1.4.2_06 Reporter: Sergey Bespalov Assigned To: Jochen Wiedmann Priority: Critical First of all I have java.lang.NoClassDefFoundError: javax/wsdl/WSDLException when try to use it. Second I was really upset when I saw axiom-api-SNAPSHOT and axiom-parent-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1301) axis2-wsdl2code-maven-plugin pom.xml missing dependencies
[ https://issues.apache.org/jira/browse/AXIS2-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved AXIS2-1301. Resolution: Fixed As of revision 526955, this is already fixed. axis2-wsdl2code-maven-plugin pom.xml missing dependencies - Key: AXIS2-1301 URL: https://issues.apache.org/jira/browse/AXIS2-1301 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Affects Versions: nightly Reporter: Terry Cox Assigned To: Jochen Wiedmann Priority: Minor The axis2-wsdl2code-maven-plugin project pom needs the following dependencies added to support xmlbeans data binding: dependency groupIdxmlbeans/groupId artifactIdxbean/artifactId version2.1.0/version scopecompile/scope /dependency dependency groupIdaxis2/groupId artifactIdaxis2-xmlbeans/artifactId versionSNAPSHOT/version /dependency /dependencies In addition, the following goalPrefix should be declared to permit users to start the plugin with the command 'mvn wsdl2code:wsdl2code' build plugins plugin artifactIdmaven-plugin-plugin/artifactId configuration goalPrefixwsdl2code/goalPrefix /configuration /plugin /plugins /build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1302) axis2-aar-maven-plugin/axis2-wsdl2code-maven-plugin combination creates aar file with services.xml in wrong location
[
https://issues.apache.org/jira/browse/AXIS2-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492762
]
Jochen Wiedmann commented on AXIS2-1302:
The problem here is, that the target layout (directories resources, src, test)
isn't specified by the Maven plugin, but by the general WSDL2Code component of
Axis 2.
Nevertheless, it is also not required to have the requested layout. The
maven-resources-plugin can very well be configured to put the services.xml file
into the right location, for example like this:
resource
directory${project.build.directory}/generated-resources/wsdl2code/directory
excludes
excludeservices.xml/exclude
/excludes
/resource
resource
directory${project.build.directory}/generated-resources/wsdl2code/directory
includes
includeservices.xml/include
/includes
targetPathMETA-INF/targetPath
/resource
axis2-aar-maven-plugin/axis2-wsdl2code-maven-plugin combination creates aar
file with services.xml in wrong location
Key: AXIS2-1302
URL: https://issues.apache.org/jira/browse/AXIS2-1302
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: Tools
Affects Versions: nightly
Reporter: Terry Cox
Assigned To: Jochen Wiedmann
Priority: Minor
If you create source code from a WSDL file using the
axis2-wsdl2code-maven-plugin, the services.xml file is created in a resources
folder, along with a copy of the WSDL.
If you now build the source using Maven2 and then package using
axis2-aar-maven-plugin, the services.xml file ends up in the root of the aar
when it should be in META-INF. The correct solution would probably be to have
axis2-wsdl2code-maven-plugin put the original files into resources/META-INF
so the Maven build copies them correctly.
Similarly, the following problem occurs during code generation:
Say we have an outputDirectory of 'src/main'. After generation, we get the
following heirarchy:
src / main / resources
src / main / src
src / main / test
however, Maven2 expects to find java source in a folder called 'java', so it
would be better to output the code into a folder that matches the language
selected:
src / main / resources
src / main / resources/META-INF
src / main / java
src / main / test
By doing this, a single Maven2 POM file can be used to generate, compile and
package the service, as shown below:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
groupIdcom.foo.bar/groupId
artifactIdecho_service/artifactId
version1.0-SNAPSHOT/version
nameCode generation from WSDL/name
dependencies
dependency
groupIdxmlbeans/groupId
artifactIdxbean/artifactId
version2.1.0/version
scopecompile/scope
/dependency
dependency
groupIdstax/groupId
artifactIdstax-api/artifactId
version1.0.1/version
/dependency
dependency
groupIdaxis2/groupId
artifactIdaxis2-kernel/artifactId
versionSNAPSHOT/version
/dependency
dependency
groupIdws-commons/groupId
artifactIdaxiom-api/artifactId
version1.1.1/version
/dependency
dependency
groupIdws-commons/groupId
artifactIdaxiom-impl/artifactId
versionSNAPSHOT/version
/dependency
dependency
groupIdws-commons/groupId
artifactIdneethi/artifactId
version1.0.1/version
/dependency
dependency
groupIdorg.apache.ws.commons/groupId
artifactIdneethi/artifactId
versionSNAPSHOT/version
/dependency
dependency
groupIdwsdl4j/groupId
artifactIdwsdl4j/artifactId
version1.5.3/version
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.axis2.maven2/groupId
artifactIdaxis2-wsdl2code-maven-plugin/artifactId
version1.0-SNAPSHOT/version
executions
execution
phasewsdl2code/phase
goals
goalwsdl2code/goal
/goals
/execution
/executions
configuration
generateServerSidetrue/generateServerSide
generateServerSideInterfacetrue/generateServerSideInterface
generateAllClassestrue/generateAllClasses
generateServiceXmltrue/generateServiceXml
generateTestcasetrue/generateTestcase
packageNamecom.foo.bar.echo/packageName
wsdlFilewsdl/Echo.wsdl/wsdlFile
[jira] Commented: (AXIS2-1130) Build with Maven 2
[ https://issues.apache.org/jira/browse/AXIS2-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487377 ] Jochen Wiedmann commented on AXIS2-1130: Would a sample implementation help? If so, give me a pointer. Build with Maven 2 -- Key: AXIS2-1130 URL: https://issues.apache.org/jira/browse/AXIS2-1130 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: samples, build,site Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann Attachments: axis2-maven2.patch This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WSCOMMONS-127) StAXUtils XMLInputFactory instantiation
[
http://issues.apache.org/jira/browse/WSCOMMONS-127?page=comments#action_12457481
]
Jochen Wiedmann commented on WSCOMMONS-127:
---
No, this is not in Axis 2 1.1. However, there's a change that you don't need to
wait for Axis 2 1.2, because it is quite likely that another release of Axiom
will appeare before. However, I cannot predict, whether such a release will
appear and whether it will be upwards compatible.
StAXUtils XMLInputFactory instantiation
---
Key: WSCOMMONS-127
URL: http://issues.apache.org/jira/browse/WSCOMMONS-127
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Environment: Java 1.6 beta 1, Java 1.6 RC1, not Java 1.6 beta 2
Reporter: Tim Putnam
Assigned To: Jochen Wiedmann
I'm using Axiom 1.2 in the context of the latest Axis 2 v1.1 snapshots. I've
twice in two months had issues with a particular part of the source, that
being in org.apache.axiom.om.util.StAXUtils:
synchronized public static XMLInputFactory getXMLInputFactory() {
if (!xmlInputFactoryPool.empty()) {
return (XMLInputFactory) xmlInputFactoryPool.pop();
}
return
XMLInputFactory.newInstance(javax.xml.stream.XMLInputFactory,
StAXUtils.class.getClassLoader());
}
When I run my application on either Java 1.6 beta ONE, or the recent Java
1.6 RC 1, it fails when attempting to create the new instance. I have no
idea why, but I get an InstantiationException (exactly the same thing worked
perfectly on Java 1.6 beta TWO).
I've currently got around the issue by replacing the above instantiation in
StAXUtils with the line:
return XMLInputFactory.newInstance();
..which works perfectly. Could anybody shed any light on what the issue is
that I'm experiencing and why its changing with the Java versions? Also, why
is StAXUtils using the parameterised version of this interface when its just
passing in defaults?
Many thanks,
Tim
--- Response from mailing list---
Please log a bug. we need to add a try/catch and fall back to (return
XMLInputFactory.newInstance();). looks like the stax api inside your
jdk version has a problem. (try dropping the stax 1.0.1 api jar in
lib/endorsed) if you want to run w/o a code fix.
thanks,
dims
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAXME-89) Multiple implements clauses are not supported
[
http://issues.apache.org/jira/browse/JAXME-89?page=comments#action_12455301 ]
Jochen Wiedmann commented on JAXME-89:
--
I haven't yet worked out why, but the AntLRTest fails after applying your patch:
The class name must not be null or empty.
java.lang.NullPointerException: The class name must not be null or empty.
at
org.apache.ws.jaxme.js.JavaQNameImpl.getInstance(JavaQNameImpl.java:231)
at org.apache.ws.jaxme.js.util.JavaParser.getQName(JavaParser.java:334)
at
org.apache.ws.jaxme.js.util.JavaParser.parseImplementsOrExtends(JavaParser.java:348)
at
org.apache.ws.jaxme.js.util.JavaParser.parseClassDefinition(JavaParser.java:492)
at org.apache.ws.jaxme.js.util.JavaParser.parseAST(JavaParser.java:509)
at org.apache.ws.jaxme.js.util.JavaParser.parse(JavaParser.java:112)
at org.apache.ws.jaxme.js.util.JavaParser.parse(JavaParser.java:82)
at org.apache.ws.jaxme.js.util.JavaParser.parse(JavaParser.java:74)
at org.apache.ws.jaxme.js.util.JavaParser.main(JavaParser.java:521)
at org.apache.ws.jaxme.js.junit.AntlrTest.test(AntlrTest.java:40)
at
org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32)
at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:423)
at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:137)
Also, could you please consider handling the case extends I1, I2, ... as
well, because that is valid for interfaces?
Multiple implements clauses are not supported
---
Key: JAXME-89
URL: http://issues.apache.org/jira/browse/JAXME-89
Project: JaxMe
Issue Type: Bug
Components: JaxMeJS
Affects Versions: 0.5
Environment: Win XP, J2SE 1.5_09
Reporter: Andreas Neumann
If you want to parse a java source file which implements more than one
interface, the parser recognizes them as a single interface. I.e.:
public class TestClass implements AnInterface {
works fine, but
public class TestClass implements AnInterface, ASecondInterface,
AThirdInterface {
fails. If you call JavaSource.getImplements() on the second example, you'll
get a String like AnInterfaceASecondInterfaceAThirdInterface.
The problem is in the JavaParser.class in the method
parseImplementsOrExtends, where the implements clause is handled like the
extends clause and expecting only one interface.
Replace the method with something like this to make it work:
private void parseImplementsOrExtends(JavaSource pSource, AST pAST, int
pType) {
AST implementsAST = findChild(pAST, pType);
if (implementsAST == null) {
throw new IllegalStateException(AST implements not found);
}
if (implementsAST.getFirstChild() != null) {
if (pType == JavaRecognizer.IMPLEMENTS_CLAUSE) {
for (AST child = implementsAST.getFirstChild(); child !=
null; child = child.getNextSibling()) {
String ident = parseIdentifier(child);
JavaQName qName = getQName(ident);
pSource.addImplements(qName);
}
} else {
String ident = parseIdentifier(implementsAST);
JavaQName qName = getQName(ident);
pSource.addExtends(qName);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAXME-89) Multiple implements clauses are not supported
[ http://issues.apache.org/jira/browse/JAXME-89?page=all ]
Jochen Wiedmann resolved JAXME-89.
--
Fix Version/s: 0.6
Resolution: Fixed
Assignee: Jochen Wiedmann
Applied to 0.5 branch and trunk.
Multiple implements clauses are not supported
---
Key: JAXME-89
URL: http://issues.apache.org/jira/browse/JAXME-89
Project: JaxMe
Issue Type: Bug
Components: JaxMeJS
Affects Versions: 0.5
Environment: Win XP, J2SE 1.5_09
Reporter: Andreas Neumann
Assigned To: Jochen Wiedmann
Fix For: 0.6
If you want to parse a java source file which implements more than one
interface, the parser recognizes them as a single interface. I.e.:
public class TestClass implements AnInterface {
works fine, but
public class TestClass implements AnInterface, ASecondInterface,
AThirdInterface {
fails. If you call JavaSource.getImplements() on the second example, you'll
get a String like AnInterfaceASecondInterfaceAThirdInterface.
The problem is in the JavaParser.class in the method
parseImplementsOrExtends, where the implements clause is handled like the
extends clause and expecting only one interface.
Replace the method with something like this to make it work:
private void parseImplementsOrExtends(JavaSource pSource, AST pAST, int
pType) {
AST implementsAST = findChild(pAST, pType);
if (implementsAST == null) {
throw new IllegalStateException(AST implements not found);
}
if (implementsAST.getFirstChild() != null) {
if (pType == JavaRecognizer.IMPLEMENTS_CLAUSE) {
for (AST child = implementsAST.getFirstChild(); child !=
null; child = child.getNextSibling()) {
String ident = parseIdentifier(child);
JavaQName qName = getQName(ident);
pSource.addImplements(qName);
}
} else {
String ident = parseIdentifier(implementsAST);
JavaQName qName = getQName(ident);
pSource.addExtends(qName);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (WSCOMMONS-127) StAXUtils XMLInputFactory instantiation
[ http://issues.apache.org/jira/browse/WSCOMMONS-127?page=all ]
Jochen Wiedmann resolved WSCOMMONS-127.
---
Resolution: Fixed
Assignee: Jochen Wiedmann
Fixed in the trunk.
StAXUtils XMLInputFactory instantiation
---
Key: WSCOMMONS-127
URL: http://issues.apache.org/jira/browse/WSCOMMONS-127
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Environment: Java 1.6 beta 1, Java 1.6 RC1, not Java 1.6 beta 2
Reporter: Tim Putnam
Assigned To: Jochen Wiedmann
I'm using Axiom 1.2 in the context of the latest Axis 2 v1.1 snapshots. I've
twice in two months had issues with a particular part of the source, that
being in org.apache.axiom.om.util.StAXUtils:
synchronized public static XMLInputFactory getXMLInputFactory() {
if (!xmlInputFactoryPool.empty()) {
return (XMLInputFactory) xmlInputFactoryPool.pop();
}
return
XMLInputFactory.newInstance(javax.xml.stream.XMLInputFactory,
StAXUtils.class.getClassLoader());
}
When I run my application on either Java 1.6 beta ONE, or the recent Java
1.6 RC 1, it fails when attempting to create the new instance. I have no
idea why, but I get an InstantiationException (exactly the same thing worked
perfectly on Java 1.6 beta TWO).
I've currently got around the issue by replacing the above instantiation in
StAXUtils with the line:
return XMLInputFactory.newInstance();
..which works perfectly. Could anybody shed any light on what the issue is
that I'm experiencing and why its changing with the Java versions? Also, why
is StAXUtils using the parameterised version of this interface when its just
passing in defaults?
Many thanks,
Tim
--- Response from mailing list---
Please log a bug. we need to add a try/catch and fall back to (return
XMLInputFactory.newInstance();). looks like the stax api inside your
jdk version has a problem. (try dropping the stax 1.0.1 api jar in
lib/endorsed) if you want to run w/o a code fix.
thanks,
dims
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAXME-77) Java parser chokes on import packagename.*
[ http://issues.apache.org/jira/browse/JAXME-77?page=all ]
Jochen Wiedmann resolved JAXME-77.
--
Fix Version/s: 0.6
Resolution: Fixed
Assignee: Jochen Wiedmann
Applied to 0.5 and 0.6 branch.
Java parser chokes on import packagename.*
--
Key: JAXME-77
URL: http://issues.apache.org/jira/browse/JAXME-77
Project: JaxMe
Issue Type: Bug
Components: JaxMeJS
Affects Versions: 0.5
Environment: WinXP Pro, Java 1.5.0_03
Reporter: Jonathan Tang
Assigned To: Jochen Wiedmann
Fix For: 0.6
Attachments: JAXME-77.patch
When I use JavaParser to parse a class containing imports of the form import
package.name.*, the parser fails on an IllegalStateException(Unknown token:
87). Full test case below:
File: JaxmeTest.java
import java.io.FileReader;
import org.apache.ws.jaxme.js.*;
import org.apache.ws.jaxme.js.util.JavaParser;
public class JaxmeTest {
public static void main(String[] args) {
JavaSourceFactory jsf = new JavaSourceFactory();
JavaParser parser = new JavaParser(jsf);
try {
parser.parse(new FileReader(JaxmeTest.java));
} catch(Exception e) {
e.printStackTrace();
}
}
}
Command line transcript:
C:\workspace\EventMonitor3.0 javac JaxmeTest.java -cp
lib\jaxmejs-0.5.jar;lib\antlr.jar
C:\workspace\EventMonitor3.0 java -cp .;lib\jaxmejs-0.5.jar;lib\antlr.jar
JaxmeTest
java.lang.IllegalStateException: Unknown token: 87
at
org.apache.ws.jaxme.js.util.JavaParser.parseIdentifier(JavaParser.java:177)
at
org.apache.ws.jaxme.js.util.JavaParser.parseIdentifier(JavaParser.java:166)
at
org.apache.ws.jaxme.js.util.JavaParser.parseIdentifier(JavaParser.java:128)
at
org.apache.ws.jaxme.js.util.JavaParser.parseImportStatement(JavaParser.java:122)
at
org.apache.ws.jaxme.js.util.JavaParser.parseAST(JavaParser.java:457)
at org.apache.ws.jaxme.js.util.JavaParser.parse(JavaParser.java:108)
at org.apache.ws.jaxme.js.util.JavaParser.parse(JavaParser.java:80)
at JaxmeTest.main(JaxmeTest.java:10)
Looking through the source, it looks like the JavaParser.parseIdentifier()
method called by parseImportStatement() expects the identifier to be a
primitive or ordinary dotted identifier, but the grammar production used in
java15.g is:
identifierStar
: IDENT
( DOT^ IDENT )*
( DOT^ STAR )?
;
This may also have a STAR token, which falls through to the exception case.
For my purposes, I'd be happy if it just ignored the * and didn't choke on
the file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1140) Axis2 AAR Plugin should allow dependencies to be added to the lib directory in the aar file
[ http://issues.apache.org/jira/browse/AXIS2-1140?page=all ] Jochen Wiedmann resolved AXIS2-1140. Fix Version/s: 1.1 Resolution: Fixed Assignee: Jochen Wiedmann Applied to the 1.1 branch. Axis2 AAR Plugin should allow dependencies to be added to the lib directory in the aar file --- Key: AXIS2-1140 URL: http://issues.apache.org/jira/browse/AXIS2-1140 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Environment: All Reporter: John Pfeifer Assigned To: Jochen Wiedmann Fix For: 1.1 Attachments: AbstractAarMojo.java Axis2 AAR files are supposed to include their dependencies in the lib file of the .aar archive. When the .aar file is deployed, any libraries in the lib directory of the aar file are included in the classpath for the web service. This feature should probably be optional since some users may not want to include the dependencies inside the .aar file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAXME-83) Element references are referencing the global elements type interface and not the element itself
Element references are referencing the global elements type interface and not the element itself Key: JAXME-83 URL: http://issues.apache.org/jira/browse/JAXME-83 Project: JaxMe Issue Type: Bug Components: JaxMe Core Affects Versions: 0.5 Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann If the following schema is parsed to the generator: xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns=http://ws.apache.org/jaxme/test/jira/elementref; targetNamespace=http://ws.apache.org/jaxme/test/jira/elementref; elementFormDefault=qualified xs:element name=Dcr xs:complexType xs:attribute name=id/ /xs:complexType /xs:element xs:element name=DcrLoadResult xs:complexType xs:sequence xs:element ref=Dcr/ /xs:sequence /xs:complexType /xs:element /xs:schema then the interface of DcrLoadResultType contains the following type signature: public org.apache.ws.jaxme.test.jira.elementref.DcrType getDcr(); public void setDcr(org.apache.ws.jaxme.test.jira.elementref.DcrType pDcr); The signature should reference org.apache.ws.jaxme.test.jira.elementref.Dcr instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAXME-84) minOccurs=0 not recognized in choice, if the choice is within an extension
minOccurs=0 not recognized in choice, if the choice is within an extension
Key: JAXME-84
URL: http://issues.apache.org/jira/browse/JAXME-84
Project: JaxMe
Issue Type: Bug
Affects Versions: 0.5
Reporter: Jochen Wiedmann
Assigned To: Jochen Wiedmann
Using the following schema
xs:schema
xmlns:xs=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://namespaces.softwareag.com/de/s/xDWS/soap-api;
xmlns:xdws=http://namespaces.softwareag.com/de/s/xDWS/soap-api;
elementFormDefault=qualified
attributeFormDefault=unqualified
xs:complexType name=xdwsResultInfo
xs:attribute name=rc type=xs:int use=required/
xs:attribute name=message type=xs:string use=optional/
xs:attribute name=details type=xs:string use=optional/
/xs:complexType
xs:element name=xdwsResponse
xs:complexType
xs:sequence
xs:element name=response minOccurs=0 maxOccurs=unbounded
xs:complexType
xs:complexContent
xs:extension base=xdws:xdwsResultInfo
xs:choice minOccurs=0
xs:element name=a type=xs:string/
xs:element name=b type=xs:string/
/xs:choice
/xs:extension
/xs:complexContent
/xs:complexType
/xs:element
xs:element name=result type=xdws:xdwsResultInfo/
/xs:sequence
xs:attribute name=version type=xs:int use=required /
/xs:complexType
/xs:element
/xs:schema
and the following test
/** Test for a
href=http://issues.apache.org/jira/browse/JAXME-84;JAXME-84/a.
*/
public void testJAXME84() throws JAXBException {
final String xml =
xdwsResponse
xmlns='http://namespaces.softwareag.com/de/s/xDWS/soap-api' version='1'\n
+ response rc='4'/\n
+ result rc='4'/\n
+ /xdwsResponse\n;
unmarshalMarshalUnmarshal(XdwsResponse.class, xml);
}
causes an error Unexpected end element:
'{http://namespaces.softwareag.com/de/s/xDWS/soap-api}response']
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAXME-84) minOccurs=0 not recognized in choice, if the choice is within an extension
[ http://issues.apache.org/jira/browse/JAXME-84?page=all ]
Jochen Wiedmann resolved JAXME-84.
--
Resolution: Fixed
The problem turned out to be, in fact, in the XS layer.
If an extended element has empty content, then the resulting content is
actually the content of the extension element. However, when lifting this
content up, the minOccurs and maxOccurs properties haven't been passed on.
minOccurs=0 not recognized in choice, if the choice is within an extension
Key: JAXME-84
URL: http://issues.apache.org/jira/browse/JAXME-84
Project: JaxMe
Issue Type: Bug
Affects Versions: 0.5
Reporter: Jochen Wiedmann
Assigned To: Jochen Wiedmann
Using the following schema
xs:schema
xmlns:xs=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://namespaces.softwareag.com/de/s/xDWS/soap-api;
xmlns:xdws=http://namespaces.softwareag.com/de/s/xDWS/soap-api;
elementFormDefault=qualified
attributeFormDefault=unqualified
xs:complexType name=xdwsResultInfo
xs:attribute name=rc type=xs:int use=required/
xs:attribute name=message type=xs:string use=optional/
xs:attribute name=details type=xs:string use=optional/
/xs:complexType
xs:element name=xdwsResponse
xs:complexType
xs:sequence
xs:element name=response minOccurs=0 maxOccurs=unbounded
xs:complexType
xs:complexContent
xs:extension base=xdws:xdwsResultInfo
xs:choice minOccurs=0
xs:element name=a type=xs:string/
xs:element name=b type=xs:string/
/xs:choice
/xs:extension
/xs:complexContent
/xs:complexType
/xs:element
xs:element name=result type=xdws:xdwsResultInfo/
/xs:sequence
xs:attribute name=version type=xs:int use=required /
/xs:complexType
/xs:element
/xs:schema
and the following test
/** Test for a
href=http://issues.apache.org/jira/browse/JAXME-84;JAXME-84/a.
*/
public void testJAXME84() throws JAXBException {
final String xml =
xdwsResponse
xmlns='http://namespaces.softwareag.com/de/s/xDWS/soap-api' version='1'\n
+ response rc='4'/\n
+ result rc='4'/\n
+ /xdwsResponse\n;
unmarshalMarshalUnmarshal(XdwsResponse.class, xml);
}
causes an error Unexpected end element:
'{http://namespaces.softwareag.com/de/s/xDWS/soap-api}response']
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-1301) axis2-wsdl2code-maven-plugin pom.xml missing dependencies
[ http://issues.apache.org/jira/browse/AXIS2-1301?page=all ] Jochen Wiedmann reassigned AXIS2-1301: -- Assignee: Jochen Wiedmann axis2-wsdl2code-maven-plugin pom.xml missing dependencies - Key: AXIS2-1301 URL: http://issues.apache.org/jira/browse/AXIS2-1301 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Affects Versions: nightly Reporter: Terry Cox Assigned To: Jochen Wiedmann Priority: Minor The axis2-wsdl2code-maven-plugin project pom needs the following dependencies added to support xmlbeans data binding: dependency groupIdxmlbeans/groupId artifactIdxbean/artifactId version2.1.0/version scopecompile/scope /dependency dependency groupIdaxis2/groupId artifactIdaxis2-xmlbeans/artifactId versionSNAPSHOT/version /dependency /dependencies In addition, the following goalPrefix should be declared to permit users to start the plugin with the command 'mvn wsdl2code:wsdl2code' build plugins plugin artifactIdmaven-plugin-plugin/artifactId configuration goalPrefixwsdl2code/goalPrefix /configuration /plugin /plugins /build -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-1302) axis2-aar-maven-plugin/axis2-wsdl2code-maven-plugin combination creates aar file with services.xml in wrong location
[ http://issues.apache.org/jira/browse/AXIS2-1302?page=all ] Jochen Wiedmann reassigned AXIS2-1302: -- Assignee: Jochen Wiedmann axis2-aar-maven-plugin/axis2-wsdl2code-maven-plugin combination creates aar file with services.xml in wrong location Key: AXIS2-1302 URL: http://issues.apache.org/jira/browse/AXIS2-1302 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Affects Versions: nightly Reporter: Terry Cox Assigned To: Jochen Wiedmann Priority: Minor If you create source code from a WSDL file using the axis2-wsdl2code-maven-plugin, the services.xml file is created in a resources folder, along with a copy of the WSDL. If you now build the source using Maven2 and then package using axis2-aar-maven-plugin, the services.xml file ends up in the root of the aar when it should be in META-INF. The correct solution would probably be to have axis2-wsdl2code-maven-plugin put the original files into resources/META-INF so the Maven build copies them correctly. Similarly, the following problem occurs during code generation: Say we have an outputDirectory of 'src/main'. After generation, we get the following heirarchy: src / main / resources src / main / src src / main / test however, Maven2 expects to find java source in a folder called 'java', so it would be better to output the code into a folder that matches the language selected: src / main / resources src / main / resources/META-INF src / main / java src / main / test By doing this, a single Maven2 POM file can be used to generate, compile and package the service, as shown below: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdcom.foo.bar/groupId artifactIdecho_service/artifactId version1.0-SNAPSHOT/version nameCode generation from WSDL/name dependencies dependency groupIdxmlbeans/groupId artifactIdxbean/artifactId version2.1.0/version scopecompile/scope /dependency dependency groupIdstax/groupId artifactIdstax-api/artifactId version1.0.1/version /dependency dependency groupIdaxis2/groupId artifactIdaxis2-kernel/artifactId versionSNAPSHOT/version /dependency dependency groupIdws-commons/groupId artifactIdaxiom-api/artifactId version1.1.1/version /dependency dependency groupIdws-commons/groupId artifactIdaxiom-impl/artifactId versionSNAPSHOT/version /dependency dependency groupIdws-commons/groupId artifactIdneethi/artifactId version1.0.1/version /dependency dependency groupIdorg.apache.ws.commons/groupId artifactIdneethi/artifactId versionSNAPSHOT/version /dependency dependency groupIdwsdl4j/groupId artifactIdwsdl4j/artifactId version1.5.3/version /dependency /dependencies build plugins plugin groupIdorg.apache.axis2.maven2/groupId artifactIdaxis2-wsdl2code-maven-plugin/artifactId version1.0-SNAPSHOT/version executions execution phasewsdl2code/phase goals goalwsdl2code/goal /goals /execution /executions configuration generateServerSidetrue/generateServerSide generateServerSideInterfacetrue/generateServerSideInterface generateAllClassestrue/generateAllClasses generateServiceXmltrue/generateServiceXml generateTestcasetrue/generateTestcase packageNamecom.foo.bar.echo/packageName wsdlFilewsdl/Echo.wsdl/wsdlFile outputDirectorysrc/main/outputDirectory syncModeboth/syncMode databindingNamexmlbeans/databindingName languagejava/language /configuration /plugin plugin groupIdorg.apache.axis2.maven2/groupId artifactIdaxis2-aar-maven-plugin/artifactId version1.0-SNAPSHOT/version executions execution phasepackage/phase goals goalaar/goal /goals /execution /executions configuration outputDirectorytarget/outputDirectory aarNameecho/aarName /configuration /plugin /plugins /build /project -- This message is
[jira] Commented: (AXIS2-1111) Add Maven 2 Plugins
[ http://issues.apache.org/jira/browse/AXIS2-?page=comments#action_12434074 ] Jochen Wiedmann commented on AXIS2-: John, please be so kind to file separate issues under component tools. If possible, please assign them to me, otherwise let me know via private mail so that I can take them. Reusing this issue isn't a good idea. Add Maven 2 Plugins --- Key: AXIS2- URL: http://issues.apache.org/jira/browse/AXIS2- Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: Tools Reporter: Jochen Wiedmann Attachments: axis2-maven-tools.jar.bz2 Attached you find a first implementation of Maven 2 plugins for Axis 2: axis2-aar-maven-pluginCreates an aar file axis2-wsdl2code-maven-plugin Runs the wsdl2code generator axis2-java2wsdl-maven-plugin Runs the java2wsdl generator I'd like to contribute this to the Axis 2 project. Maintaining them would work best as soon as Axis 2 is itself built with Maven. The project needs more work. In particular, it lacks documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1128) Layout of axis2/modules/tool
[ http://issues.apache.org/jira/browse/AXIS2-1128?page=comments#action_12433576 ] Jochen Wiedmann commented on AXIS2-1128: But, Dims, isn't that just another argument to break up the eclipse specific stuff into a separate directory? At least, I find it quite inconvenient to work with compiler excludes. Layout of axis2/modules/tool Key: AXIS2-1128 URL: http://issues.apache.org/jira/browse/AXIS2-1128 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Reporter: Jochen Wiedmann Hello, while working on the Maven 2 build of Axis 2, I detected a problem in the layout of the directory axis2/modules/tool. This directory contains, among others, a directory src and several directories with Maven 2 plugins. The src subdirectory means, that the directory is meant to produce artifacts, for example axis2-tools.jar. In other words, the axis2-tool project should have packaging jar. On the other hand, the presence of maven plugins below means, that the directory is a parent directory. In other words, it should have packaging pom. I see no other possibility to resolve the problem, apart from changing the directory layout. Suggested new layout: axis2 +-- modules +-- tool (I'd personally consider tools a better name.) +-- maven2 |+-- axis2-aar-maven-plugin |+-- axis2-idea-plugin |+-- axis2-java2wsdl-maven-plugin |+-- axis2-wsdl2code-maven-plugin |+-- pom.xml +-- general | +-- src | +-- conf | +-- script | +-- test | +-- pom.xml | +-- project.xml +-- pom.xml I do personally believe, that the directory general should be splitted into more subprojects. However, that could as well be done at a later point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1130) Build with Maven 2
Build with Maven 2 -- Key: AXIS2-1130 URL: http://issues.apache.org/jira/browse/AXIS2-1130 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Work started: (AXIS2-1130) Build with Maven 2
[ http://issues.apache.org/jira/browse/AXIS2-1130?page=all ] Work on AXIS2-1130 started by Jochen Wiedmann. Build with Maven 2 -- Key: AXIS2-1130 URL: http://issues.apache.org/jira/browse/AXIS2-1130 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann Attachments: axis2-maven2.patch This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1130) Build with Maven 2
[ http://issues.apache.org/jira/browse/AXIS2-1130?page=all ] Jochen Wiedmann updated AXIS2-1130: --- Attachment: axis2-maven2.patch Current state Build with Maven 2 -- Key: AXIS2-1130 URL: http://issues.apache.org/jira/browse/AXIS2-1130 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann Attachments: axis2-maven2.patch This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1128) Layout of axis2/modules/tool
Layout of axis2/modules/tool Key: AXIS2-1128 URL: http://issues.apache.org/jira/browse/AXIS2-1128 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Reporter: Jochen Wiedmann Hello, while working on the Maven 2 build of Axis 2, I detected a problem in the layout of the directory axis2/modules/tool. This directory contains, among others, a directory src and several directories with Maven 2 plugins. The src subdirectory means, that the directory is meant to produce artifacts, for example axis2-tools.jar. In other words, the axis2-tool project should have packaging jar. On the other hand, the presence of maven plugins below means, that the directory is a parent directory. In other words, it should have packaging pom. I see no other possibility to resolve the problem, apart from changing the directory layout. Suggested new layout: axis2 +-- modules +-- tool (I'd personally consider tools a better name.) +-- maven2 |+-- axis2-aar-maven-plugin |+-- axis2-idea-plugin |+-- axis2-java2wsdl-maven-plugin |+-- axis2-wsdl2code-maven-plugin |+-- pom.xml +-- general | +-- src | +-- conf | +-- script | +-- test | +-- pom.xml | +-- project.xml +-- pom.xml I do personally believe, that the directory general should be splitted into more subprojects. However, that could as well be done at a later point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (WSCOMMONS-87) SchemaBuilder handleSimpleType does not find default namespace which gives a NPE
[ http://issues.apache.org/jira/browse/WSCOMMONS-87?page=all ]
Jochen Wiedmann resolved WSCOMMONS-87.
--
Resolution: Duplicate
Test case applied
SchemaBuilder handleSimpleType does not find default namespace which gives a
NPE
Key: WSCOMMONS-87
URL: http://issues.apache.org/jira/browse/WSCOMMONS-87
Project: WS-Commons
Issue Type: Bug
Components: XmlSchema
Environment: WinXP home, jdk 1.5.0_06,
also reported as xfire-617
Reporter: Marc Gagnon
Attachments: XmlSchemaTestInclude.zip
This issue was reported on axis2's user list and later in xfire as issue
xfire-617.
I've been able to reproduce the issue in XmlSchema independently of xfire
(see attached files).
To reproduce, get XmlSchema (I used 1.0.3, same behavior as 1.0.1) and unzip
IncludeTest.java in the tests directory, unzip the xsd files in
test-resources and run the unit tests.
One test case is ok: the one which defines a default namespace in the
included file.
The other test case fails because there is no default namespace defined, just
like in OTA_SimpleTypes.xsd
Sample xsd from the attachement:
schema targetNamespace=http://soapinterop.org/xsd;
xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsd1=http://soapinterop.org/xsd;
xmlns:xsd2=http://soapinterop.org/xsd2;
elementFormDefault=qualified
include schemaLocation=includeAux.xsd/
/schema
includeAux=
schema
xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:xsd1=http://soapinterop.org/xsd2;
elementFormDefault=qualified
xs:simpleType name=PaymentCardCodeType
xs:union
xs:simpleType
xs:restriction base=UpperCaseAlphaLength1to2/
/xs:simpleType
/xs:union
/xs:simpleType
xs:simpleType name=UpperCaseAlphaLength1to2
xs:restriction base=xs:string
xs:pattern value=[A-Z]{1,2}/
/xs:restriction
/xs:simpleType
/schema
This example is ok, remove line xmlns=http://www.w3.org/2001/XMLSchema;
in the file above and it will fail. It seems to me that this declaration
should be considered implicit and this should be handled in
ShemaBuilder.handleSimpleType
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1111) Add Maven 2 Plugins
[ http://issues.apache.org/jira/browse/AXIS2-?page=comments#action_12433218 ] Jochen Wiedmann commented on AXIS2-: Eran, I am not an Axis 2 developer. Don't know the Axis projects policies or whether I am nitpicking, but this is how I am used to behave from other projects. Add Maven 2 Plugins --- Key: AXIS2- URL: http://issues.apache.org/jira/browse/AXIS2- Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: Tools Reporter: Jochen Wiedmann Attachments: axis2-maven-tools.jar.bz2 Attached you find a first implementation of Maven 2 plugins for Axis 2: axis2-aar-maven-pluginCreates an aar file axis2-wsdl2code-maven-plugin Runs the wsdl2code generator axis2-java2wsdl-maven-plugin Runs the java2wsdl generator I'd like to contribute this to the Axis 2 project. Maintaining them would work best as soon as Axis 2 is itself built with Maven. The project needs more work. In particular, it lacks documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1111) Add Maven 2 Plugins
[ http://issues.apache.org/jira/browse/AXIS2-?page=comments#action_12432778 ] Jochen Wiedmann commented on AXIS2-: I hope Axis2 project itself will move to maven2 as its build system. Gimme time. :-) As a first step, you could be so kind to pull this stuff in, for example into the modules directory. (It wouldn't need to be configured into the build system.) Add Maven 2 Plugins --- Key: AXIS2- URL: http://issues.apache.org/jira/browse/AXIS2- Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: Tools Reporter: Jochen Wiedmann Attachments: axis2-maven-tools.jar.bz2 Attached you find a first implementation of Maven 2 plugins for Axis 2: axis2-aar-maven-pluginCreates an aar file axis2-wsdl2code-maven-plugin Runs the wsdl2code generator axis2-java2wsdl-maven-plugin Runs the java2wsdl generator I'd like to contribute this to the Axis 2 project. Maintaining them would work best as soon as Axis 2 is itself built with Maven. The project needs more work. In particular, it lacks documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1111) Add Maven 2 Plugins
[ http://issues.apache.org/jira/browse/AXIS2-?page=comments#action_12432816 ] Jochen Wiedmann commented on AXIS2-: I believe, that modules inside modules are fine in this particular case: Obviously, it makes sense to use a special parent POM in this case. (As soon as Axis 2 is built with Maven 2 itself, this POM should be derived from the Axis 2 parent POM itself.) However, I understand your concern. So, if you don't like the layout, I can change this and replace the parent folder on top with a separate module, for example axis2-tools-parent, or something like that. On the other hand, one should keep in mind, that most probably many more Maven 2 plugins will arise in the future: For example deployment modules, c2wsdl, or whatever. Doing this will be much more convenient, if we accept the concept of modules inside this very special module. As for ws-commons: I do not view these plugins as a shareable component. IMO, these are depending on Axis 2 and should be maintained together with the Axis 2 kernel, just like the Ant generators. However, if the final decision should be to reject the plugins from Axis 2, I could them to ws-commons, of course. Add Maven 2 Plugins --- Key: AXIS2- URL: http://issues.apache.org/jira/browse/AXIS2- Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: Tools Reporter: Jochen Wiedmann Attachments: axis2-maven-tools.jar.bz2 Attached you find a first implementation of Maven 2 plugins for Axis 2: axis2-aar-maven-pluginCreates an aar file axis2-wsdl2code-maven-plugin Runs the wsdl2code generator axis2-java2wsdl-maven-plugin Runs the java2wsdl generator I'd like to contribute this to the Axis 2 project. Maintaining them would work best as soon as Axis 2 is itself built with Maven. The project needs more work. In particular, it lacks documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1111) Add Maven 2 Plugins
Add Maven 2 Plugins --- Key: AXIS2- URL: http://issues.apache.org/jira/browse/AXIS2- Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: Tools Reporter: Jochen Wiedmann Attachments: axis2-maven-tools.jar.bz2 Attached you find a first implementation of Maven 2 plugins for Axis 2: axis2-aar-maven-pluginCreates an aar file axis2-wsdl2code-maven-plugin Runs the wsdl2code generator axis2-java2wsdl-maven-plugin Runs the java2wsdl generator I'd like to contribute this to the Axis 2 project. Maintaining them would work best as soon as Axis 2 is itself built with Maven. The project needs more work. In particular, it lacks documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[
http://issues.apache.org/jira/browse/WSCOMMONS-78?page=comments#action_12432572
]
Jochen Wiedmann commented on WSCOMMONS-78:
--
In the meantime, I have detected that Axis 2 depends much, much more on these
deprecated API's than I had expected. Unfortunately that means, that the
serialization stuff in Axis 2 is most likely broken, at least if it depends on
the same assumptions, which are implicit in the API. (Basically, it is assumed
that all namespaces are declared in the top level elements, which is of course
recommendable, but cannot be trusted.)
I'll try to understand the serialization framework in Axis 2 first, before I'll
continue my work.
Including a schema without namespace into a schema with namespace is not
possible
-
Key: WSCOMMONS-78
URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
Project: WS-Commons
Issue Type: Bug
Components: XmlSchema
Reporter: Jochen Wiedmann
Attachments: XmlSchema-include-handling.patch,
XmlSchema-Include-Without-Namespace.patch
The XML Schema specification states in 4.2.1 Assembling a schema for a
single target namespace from multiple schema definition documents:
2 One of the following must be true:
...
2.3 SII has no targetNamespace [attribute] (but SII' does).
3 The appropriate case among the following must be true:
...
3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
included item's parent schema must include not only definitions
or declarations corresponding to the appropriate members of its own
[children], but also components identical to all the - schema components- of
I,
except that anywhere the - absent- target namespace name would have
appeared, the - actual value- of the targetNamespace [attribute] of SII' is
used.
In particular, it replaces - absent- in the following places:
3.2.1 The {target namespace} of named schema components, both at the top
level and (in the case of nested type definitions and nested attribute and
element declarations whose code was qualified) nested within definitions;
3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
In other words, it is possible to include a schema without namespace, as if
it had the namespace of the including schema.
Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
The patch includes a simple test case and could be applied, if this bug is
fixed.
Suggested resolution, as realized in JaxMeXS: If such a schema is being
parsed, then mutable instances of QName should be created, which would always
return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[ http://issues.apache.org/jira/browse/WSCOMMONS-78?page=all ]
Jochen Wiedmann updated WSCOMMONS-78:
-
Attachment: XmlSchema-include-handling2.patch
Ok, Dims, as requested, here's the updated patch.
Including a schema without namespace into a schema with namespace is not
possible
-
Key: WSCOMMONS-78
URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
Project: WS-Commons
Issue Type: Bug
Components: XmlSchema
Reporter: Jochen Wiedmann
Attachments: XmlSchema-include-handling.patch,
XmlSchema-include-handling2.patch, XmlSchema-Include-Without-Namespace.patch
The XML Schema specification states in 4.2.1 Assembling a schema for a
single target namespace from multiple schema definition documents:
2 One of the following must be true:
...
2.3 SII has no targetNamespace [attribute] (but SII' does).
3 The appropriate case among the following must be true:
...
3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
included item's parent schema must include not only definitions
or declarations corresponding to the appropriate members of its own
[children], but also components identical to all the - schema components- of
I,
except that anywhere the - absent- target namespace name would have
appeared, the - actual value- of the targetNamespace [attribute] of SII' is
used.
In particular, it replaces - absent- in the following places:
3.2.1 The {target namespace} of named schema components, both at the top
level and (in the case of nested type definitions and nested attribute and
element declarations whose code was qualified) nested within definitions;
3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
In other words, it is possible to include a schema without namespace, as if
it had the namespace of the including schema.
Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
The patch includes a simple test case and could be applied, if this bug is
fixed.
Suggested resolution, as realized in JaxMeXS: If such a schema is being
parsed, then mutable instances of QName should be created, which would always
return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[
http://issues.apache.org/jira/browse/WSCOMMONS-78?page=comments#action_12432522
]
Jochen Wiedmann commented on WSCOMMONS-78:
--
Did you apply the patch for WSCOMMONS-81 in advance? In either case, we should
resolve that one first.
Including a schema without namespace into a schema with namespace is not
possible
-
Key: WSCOMMONS-78
URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
Project: WS-Commons
Issue Type: Bug
Components: XmlSchema
Reporter: Jochen Wiedmann
Attachments: XmlSchema-include-handling.patch,
XmlSchema-Include-Without-Namespace.patch
The XML Schema specification states in 4.2.1 Assembling a schema for a
single target namespace from multiple schema definition documents:
2 One of the following must be true:
...
2.3 SII has no targetNamespace [attribute] (but SII' does).
3 The appropriate case among the following must be true:
...
3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
included item's parent schema must include not only definitions
or declarations corresponding to the appropriate members of its own
[children], but also components identical to all the - schema components- of
I,
except that anywhere the - absent- target namespace name would have
appeared, the - actual value- of the targetNamespace [attribute] of SII' is
used.
In particular, it replaces - absent- in the following places:
3.2.1 The {target namespace} of named schema components, both at the top
level and (in the case of nested type definitions and nested attribute and
element declarations whose code was qualified) nested within definitions;
3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
In other words, it is possible to include a schema without namespace, as if
it had the namespace of the including schema.
Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
The patch includes a simple test case and could be applied, if this bug is
fixed.
Suggested resolution, as realized in JaxMeXS: If such a schema is being
parsed, then mutable instances of QName should be created, which would always
return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (WSCOMMONS-7) Make an assembly descriptor which deploys XmlSchema sources automagically
[ http://issues.apache.org/jira/browse/WSCOMMONS-7?page=all ] Jochen Wiedmann resolved WSCOMMONS-7. - Resolution: Fixed Fixed in pom.xml. Make an assembly descriptor which deploys XmlSchema sources automagically - Key: WSCOMMONS-7 URL: http://issues.apache.org/jira/browse/WSCOMMONS-7 Project: WS-Commons Issue Type: Task Components: XmlSchema Reporter: Dan Diephouse Make an assembly descriptor which deploys XmlSchema sources automagically -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
Including a schema without namespace into a schema with namespace is not
possible
-
Key: WSCOMMONS-78
URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
Project: WS-Commons
Issue Type: Bug
Components: XmlSchema
Reporter: Jochen Wiedmann
Attachments: XmlSchema-Include-Without-Namespace.patch
The XML Schema specification states in 4.2.1 Assembling a schema for a single
target namespace from multiple schema definition documents:
2 One of the following must be true:
...
2.3 SII has no targetNamespace [attribute] (but SII' does).
3 The appropriate case among the following must be true:
...
3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
included item's parent schema must include not only definitions
or declarations corresponding to the appropriate members of its own
[children], but also components identical to all the - schema components- of I,
except that anywhere the - absent- target namespace name would have
appeared, the - actual value- of the targetNamespace [attribute] of SII' is
used.
In particular, it replaces - absent- in the following places:
3.2.1 The {target namespace} of named schema components, both at the top
level and (in the case of nested type definitions and nested attribute and
element declarations whose code was qualified) nested within definitions;
3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
In other words, it is possible to include a schema without namespace, as if it
had the namespace of the including schema.
Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
The patch includes a simple test case and could be applied, if this bug is
fixed.
Suggested resolution, as realized in JaxMeXS: If such a schema is being parsed,
then mutable instances of QName should be created, which would always
return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1038) Removing an unnecessary statement
Removing an unnecessary statement - Key: AXIS2-1038 URL: http://issues.apache.org/jira/browse/AXIS2-1038 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Reporter: Jochen Wiedmann Priority: Trivial The patch below removes an unnecessary statement: Index: modules/core/src/org/apache/axis2/receivers/RawXMLINOutMessageReceiver.java === --- modules/core/src/org/apache/axis2/receivers/RawXMLINOutMessageReceiver.java(revision 431324) +++ modules/core/src/org/apache/axis2/receivers/RawXMLINOutMessageReceiver.java(working copy) @@ -99,7 +99,6 @@ result = (OMElement) method.invoke(obj, args); AxisService service = msgContext.getAxisService(); -service.getTargetNamespace(); result.declareNamespace(service.getTargetNamespace(), service.getTargetNamespacePrefix()); OMElement bodyContent; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1038) Removing an unnecessary statement
[ http://issues.apache.org/jira/browse/AXIS2-1038?page=comments#action_12428375 ] Jochen Wiedmann commented on AXIS2-1038: Dims, I might have the necessary permissions in terms of SVN and Unix. Nevertheless, I am no voted member of the Axis2 project and I would personally consider it to be abusing my privileges. Removing an unnecessary statement - Key: AXIS2-1038 URL: http://issues.apache.org/jira/browse/AXIS2-1038 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Reporter: Jochen Wiedmann Priority: Trivial The patch below removes an unnecessary statement: Index: modules/core/src/org/apache/axis2/receivers/RawXMLINOutMessageReceiver.java === --- modules/core/src/org/apache/axis2/receivers/RawXMLINOutMessageReceiver.java(revision 431324) +++ modules/core/src/org/apache/axis2/receivers/RawXMLINOutMessageReceiver.java(working copy) @@ -99,7 +99,6 @@ result = (OMElement) method.invoke(obj, args); AxisService service = msgContext.getAxisService(); -service.getTargetNamespace(); result.declareNamespace(service.getTargetNamespace(), service.getTargetNamespacePrefix()); OMElement bodyContent; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1020) WSDL location service.wsdl is unsupported
WSDL location service.wsdl is unsupported - Key: AXIS2-1020 URL: http://issues.apache.org/jira/browse/AXIS2-1020 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: deployment Reporter: Jochen Wiedmann Attachments: axis2-service-wsdl-location.patch By reading the method DeploymentEngine.populateService, one might come to the conclusion, that it should be possible to deploy the WSDL as META-INF/service.wsdl. Of course, being able to use such a generic location might make quite some sense, at least for the simple case, where only one WSDL is involved. Unfortunately that location doesn't work, because of an obvious programming bug. Patch file attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (WSCOMMONS-72) Create docs for building with Maven 2
Create docs for building with Maven 2 - Key: WSCOMMONS-72 URL: http://issues.apache.org/jira/browse/WSCOMMONS-72 Project: WS-Commons Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann See http://ws.apache.org/axis2/faq.html#d3 for a Maven 1 example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-101) Possibility to subclass XmlRpcSunHttpTransport for added functionality
[ http://issues.apache.org/jira/browse/XMLRPC-101?page=comments#action_12425005 ] Jochen Wiedmann commented on XMLRPC-101: Ok, I'll apply this patch (most possibly with slight modifications) after 3.0 is out. Possibility to subclass XmlRpcSunHttpTransport for added functionality -- Key: XMLRPC-101 URL: http://issues.apache.org/jira/browse/XMLRPC-101 Project: XML-RPC Issue Type: Improvement Components: Source Affects Versions: 3.0rc1 Reporter: Julio Francisco Veronelli Assigned To: Jochen Wiedmann Priority: Trivial Attachments: ssl.patch, sunhttp.zip Could it be possible to make the URLConnection in class org.apache.xmlrpc.client.XmlRpcSunHttpTransport protected instead of private? That is: protected URLConnection conn; REASON: That way is much easier to subclass for added functionality. In particular, i'm subclassing it to set a java.net.Proxy or a java.security.KeyStore used for setting a SSL connection. In XML-RPC 3.0a1 it was easy to do, all that was needed was to subclass method newConnection(). In 3.0RC1 that method is gone, and overwriting sendRequest(XmlRpcRequest) is not possible, since conn is private. I tried also extending XmlRpcHttpTransport, but it is not possible, because org.apache.xmlrpc.client.XmlRpcStreamTransport.RequestWriter is protected and cannot be accessed. Thanks in advance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (XMLRPC-99) Maven repository on ibiblio seems to be invalid for 3.0rc1
[ http://issues.apache.org/jira/browse/XMLRPC-99?page=all ] Jochen Wiedmann reassigned XMLRPC-99: - Assignee: Jochen Wiedmann Please retry Maven repository on ibiblio seems to be invalid for 3.0rc1 -- Key: XMLRPC-99 URL: http://issues.apache.org/jira/browse/XMLRPC-99 Project: XML-RPC Issue Type: Bug Affects Versions: unspecified Environment: Maven 2.0.5 XMLRPC-3.0rc1 Reporter: Jimisola Laursen Assigned To: Jochen Wiedmann The repository for 3.0rc1 on ibiblio doesn't seem to be complete. The pom for the packing (artifactId: xmlrpc) seems to be missing. In fact the directory doesn't exist at all - which it does for 3.0b1. Also, version 3.0rc1 doesn't exist as a version in Jira so I left this as unspecified. Feel free to change it. Downloading: http://repo1.maven.org/maven2/org/apache/xmlrpc/xmlrpc/3.0rc1/xmlrpc-3.0rc1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.xmlrpc ArtifactId: xmlrpc Version: 3.0rc1 Reason: Unable to download the artifact from any repository org.apache.xmlrpc:xmlrpc:pom:3.0rc1 from the specified remote repositories: central (http://repo1.maven.org/maven2), -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-101) Possibility to subclass XmlRpcSunHttpTransport for added functionality
[
http://issues.apache.org/jira/browse/XMLRPC-101?page=comments#action_12424645 ]
Jochen Wiedmann commented on XMLRPC-101:
I see two completely different topics here:
- The use of a proxy server is definitely of general interest and a common
requirement.
It can be easily picked up by the commons and the lite http transport as
well. In
other words, I suggest that we change this into a configurable property of
the
XmlRpcHttpClient. For example, the property might take an instance of the
following class:
public class HttpProxy {
URL proxyURL;
String user, password;
}
Are you ready to provide a patch for that?
- The use of an SSLSocketFactory is slightly different from
http://ws.apache.org/xmlrpc/ssl.html
As far as I can tell the basic difference is that you are setting the trust
manager
per connection, which is of course recommendable over a static setting. I am
considering how this might be integrated, too. One more patch?
Possibility to subclass XmlRpcSunHttpTransport for added functionality
--
Key: XMLRPC-101
URL: http://issues.apache.org/jira/browse/XMLRPC-101
Project: XML-RPC
Issue Type: Improvement
Components: Source
Affects Versions: 3.0rc1
Reporter: Julio Francisco Veronelli
Priority: Trivial
Could it be possible to make the URLConnection in class
org.apache.xmlrpc.client.XmlRpcSunHttpTransport protected instead of private?
That is:
protected URLConnection conn;
REASON:
That way is much easier to subclass for added functionality. In particular,
i'm subclassing it to set a java.net.Proxy or a java.security.KeyStore used
for setting a SSL connection.
In XML-RPC 3.0a1 it was easy to do, all that was needed was to subclass
method newConnection(). In 3.0RC1 that method is gone, and overwriting
sendRequest(XmlRpcRequest) is not possible, since conn is private.
I tried also extending XmlRpcHttpTransport, but it is not possible, because
org.apache.xmlrpc.client.XmlRpcStreamTransport.RequestWriter is protected and
cannot be accessed.
Thanks in advance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-101) Possibility to subclass XmlRpcSunHttpTransport for added functionality
[ http://issues.apache.org/jira/browse/XMLRPC-101?page=comments#action_12424752 ] Jochen Wiedmann commented on XMLRPC-101: There's nothing wrong with using Java 1.4 (or even 1.5 features), as long as the respective code is clearly separated. Take, for example, the CharSetXmlWriter. That's one important reason for using the factory approach: The factory allows you to check, which Java version you are running. Based on the check, the proper implementation will be returned. In other words, please be so kind to modify your patch in the following manner: - First of all, for now forget about the lite and commons classes. Sorry, that I haven't mentioned this earlier. It simplifies and reduces your work and may well be deferred until we agree on the interface. - In the XmlRpcSunHttpTransportFactory, check whether one is running 1.4 or 1.5. The check should be implemented by validating the existence of appropriate classes. - Create 1.4 and 1.5 specific subclasses of XmlRpcSunHttpTransportFactory. These are the proper locations for your patches. Possibility to subclass XmlRpcSunHttpTransport for added functionality -- Key: XMLRPC-101 URL: http://issues.apache.org/jira/browse/XMLRPC-101 Project: XML-RPC Issue Type: Improvement Components: Source Affects Versions: 3.0rc1 Reporter: Julio Francisco Veronelli Priority: Trivial Attachments: ssl.patch Could it be possible to make the URLConnection in class org.apache.xmlrpc.client.XmlRpcSunHttpTransport protected instead of private? That is: protected URLConnection conn; REASON: That way is much easier to subclass for added functionality. In particular, i'm subclassing it to set a java.net.Proxy or a java.security.KeyStore used for setting a SSL connection. In XML-RPC 3.0a1 it was easy to do, all that was needed was to subclass method newConnection(). In 3.0RC1 that method is gone, and overwriting sendRequest(XmlRpcRequest) is not possible, since conn is private. I tried also extending XmlRpcHttpTransport, but it is not possible, because org.apache.xmlrpc.client.XmlRpcStreamTransport.RequestWriter is protected and cannot be accessed. Thanks in advance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (XMLRPC-101) Possibility to subclass XmlRpcSunHttpTransport for added functionality
[ http://issues.apache.org/jira/browse/XMLRPC-101?page=all ] Jochen Wiedmann reassigned XMLRPC-101: -- Assignee: Jochen Wiedmann Possibility to subclass XmlRpcSunHttpTransport for added functionality -- Key: XMLRPC-101 URL: http://issues.apache.org/jira/browse/XMLRPC-101 Project: XML-RPC Issue Type: Improvement Components: Source Affects Versions: 3.0rc1 Reporter: Julio Francisco Veronelli Assigned To: Jochen Wiedmann Priority: Trivial Attachments: ssl.patch Could it be possible to make the URLConnection in class org.apache.xmlrpc.client.XmlRpcSunHttpTransport protected instead of private? That is: protected URLConnection conn; REASON: That way is much easier to subclass for added functionality. In particular, i'm subclassing it to set a java.net.Proxy or a java.security.KeyStore used for setting a SSL connection. In XML-RPC 3.0a1 it was easy to do, all that was needed was to subclass method newConnection(). In 3.0RC1 that method is gone, and overwriting sendRequest(XmlRpcRequest) is not possible, since conn is private. I tried also extending XmlRpcHttpTransport, but it is not possible, because org.apache.xmlrpc.client.XmlRpcStreamTransport.RequestWriter is protected and cannot be accessed. Thanks in advance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-98) Serious problem with method selection in ReflectiveXmlRpcHandler
[ http://issues.apache.org/jira/browse/XMLRPC-98?page=all ]
Jochen Wiedmann closed XMLRPC-98.
-
Resolution: Duplicate
Serious problem with method selection in ReflectiveXmlRpcHandler
Key: XMLRPC-98
URL: http://issues.apache.org/jira/browse/XMLRPC-98
Project: XML-RPC
Issue Type: Bug
Components: Source
Affects Versions: 3.0b1
Reporter: Aleksey Gureev
Priority: Critical
There's a trouble with loop indexes in the code preventing normal selection
of methods to execute. Please examine this code:
---
for (int i = 0; i methods.length; i++) {
MethodData methodData = methods[i];
TypeConverter[] converters = methodData.typeConverters;
if (args.length == converters.length) {
boolean matching = true;
for (int j = 0; j args.length; j++) {
if (!converters[j].isConvertable(args[i])) {
matching = false;
break;
}
}
if (matching) {
for (int j = 0; j args.length; j++) {
args[i] = converters[i].convert(args[i]);
}
return invoke(instance, methodData.method, args);
}
}
}
---
It should be (insignificant parts skipped):
---
for (int i = 0; i methods.length; i++) {
...
if (!converters[j].isConvertable(args[j])) {
...
args[j] = converters[j].convert(args[j]);
...
}
---
Please notice the change in indexes:
* in isConvertable() call it's 'j' as we loop through args
* in the line with convert() call there are three 'j' instead of three 'i'
Frankly speaking, such mistakes look very scary. I'm moving our server from
xmlrpc-1.2 to 3.0 and this makes me think and think if it's worth the effort
even though the version 1.2 has a terrible bug with exception handling and
threads leak. Sorry for telling this.
Anyway, keep up good work and thanks for a good open-source project!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-97) [documentation] XML-RPC Data Types page lacks information on long/Long
[ http://issues.apache.org/jira/browse/XMLRPC-97?page=all ] Jochen Wiedmann closed XMLRPC-97. - Resolution: Fixed Fixed, thank you! [documentation] XML-RPC Data Types page lacks information on long/Long -- Key: XMLRPC-97 URL: http://issues.apache.org/jira/browse/XMLRPC-97 Project: XML-RPC Issue Type: Improvement Affects Versions: 3.0b1 Reporter: Jimisola Laursen Priority: Trivial The XML-RPC Data Types page (http://ws.apache.org/xmlrpc/types.html) lacks information on long/Long. It is said to be supported on the overview page (http://ws.apache.org/xmlrpc/index.html) and the class TypeConverterFactoryImpl seem to handle it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-95) Client hangs on execute
[ http://issues.apache.org/jira/browse/XMLRPC-95?page=all ]
Jochen Wiedmann closed XMLRPC-95.
-
Resolution: Invalid
Ok, here is your fault:
The class you give to the DynamicHandlerMapping is no other than your own
RpcServer(). Now, when a request comes in, an instance of RpcServer is created,
in order to call its method loginUser. In other words: The constructor of
RpcServer is executed before the loginUser method. In particular, a new
instance of WebServer with port 3099 is created.
However, this port is no longer free: A first instance of WebServer was already
created (the instance, which is currently accepting the request), thus the port
3099 is blocked and the constructor waits ... and waits ... until the port
might be free or a timeout occurs.
Fix: Create a new class (for example LoginHandler) with a default
constructor, move the loginUser method to that class and replace the
RpcServer.class in the handler mapping with LoginHandler. That's all.
Client hangs on execute
---
Key: XMLRPC-95
URL: http://issues.apache.org/jira/browse/XMLRPC-95
Project: XML-RPC
Issue Type: Bug
Components: Releases
Affects Versions: 3.0b1
Environment: Win XP
Java 1.5.0_06
Reporter: Bit Buzzer
Problem description:
When this server is running and the client is executed, nothing happens.
The client hangs on the execute statement, and neither of them throws
any exception or message.
No indication what goes wrong or were the problem exists.
Server code:
###
import java.io.IOException;
import org.apache.xmlrpc.XmlRpcException;
import org.apache.xmlrpc.common.TypeConverterFactoryImpl;
import org.apache.xmlrpc.server.DynamicHandlerMapping;
import org.apache.xmlrpc.server.XmlRpcServerConfigImpl;
import org.apache.xmlrpc.webserver.WebServer;
public class RpcServer {
static int port = 3099;
private WebServer server;
public static void main(String[] args) {
new RpcServer();
}
public RpcServer(){
try {
server = new WebServer(port);
XmlRpcServerConfigImpl config = new
XmlRpcServerConfigImpl();
config.setEnabledForExtensions(true);
config.setContentLengthOptional(true);
DynamicHandlerMapping dhm = new
DynamicHandlerMapping(new TypeConverterFactoryImpl(), false);
dhm.addHandler(Start, this.getClass());
server.getXmlRpcServer().setConfig(config);
server.getXmlRpcServer().setHandlerMapping(dhm);
server.start();
System.out.println(RPC server running. );
}
catch (XmlRpcException e) {
System.out.println(RPC EXcep);
e.printStackTrace();
}
catch (IOException e) {
System.out.println(IO EXcep);
e.printStackTrace();
}
}
public int loginUser(String userId ) {
System.out.println(In de method);
return 0;
}
}
###
Server includes following jars:
- commons-logging-1.1.jar
- ws-commons-util-1.0-SNAPSHOT.jar
- xmlrpc-common-3.0b1.jar
- xmlrpc-server-3.0b1.jar
Client code:
###
import java.net.URL;
import java.util.List;
import java.util.Vector;
import org.apache.xmlrpc.client.XmlRpcClient;
import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;
public class RpcClient {
static XmlRpcClient xmlrpc;
public static void main( String args[] ) {
try {
ListString params = new VectorString();
params.add( 48504852 );
XmlRpcClientConfigImpl config = new
XmlRpcClientConfigImpl();
config.setServerURL(new
URL(http://192.168.1.1:3099/;));
config.setEnabledForExtensions(true);
config.setContentLengthOptional(true);
[jira] Resolved: (XMLRPC-94) ReflectiveXmlRpcHandler.execute fails to properly lookup method
[ http://issues.apache.org/jira/browse/XMLRPC-94?page=all ] Jochen Wiedmann resolved XMLRPC-94: --- Resolution: Fixed Applied, thank you! ReflectiveXmlRpcHandler.execute fails to properly lookup method --- Key: XMLRPC-94 URL: http://issues.apache.org/jira/browse/XMLRPC-94 Project: XML-RPC Type: Bug Components: Releases Versions: 3.0b1 Reporter: Chris Conrad Attachments: ReflectiveXmlRpcHandler.diff In the 3.0b1 and a current SVN checkout, ReflectiveXmlRpcHandler.execute fails to properly lookup a method. A patch which fixes the issue for me is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-94) ReflectiveXmlRpcHandler.execute fails to properly lookup method
[ http://issues.apache.org/jira/browse/XMLRPC-94?page=all ] Jochen Wiedmann closed XMLRPC-94: - ReflectiveXmlRpcHandler.execute fails to properly lookup method --- Key: XMLRPC-94 URL: http://issues.apache.org/jira/browse/XMLRPC-94 Project: XML-RPC Type: Bug Components: Releases Versions: 3.0b1 Reporter: Chris Conrad Attachments: ReflectiveXmlRpcHandler.diff In the 3.0b1 and a current SVN checkout, ReflectiveXmlRpcHandler.execute fails to properly lookup a method. A patch which fixes the issue for me is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-93) About SSL
[ http://issues.apache.org/jira/browse/XMLRPC-93?page=all ] Jochen Wiedmann closed XMLRPC-93. - Resolution: Invalid You did not configure your client properly. I have added a document, which describes proper client configuration. See https://svn.apache.org/repos/asf/webservices/xmlrpc/trunk/src/site/apt/ssl.apt About SSL - Key: XMLRPC-93 URL: http://issues.apache.org/jira/browse/XMLRPC-93 Project: XML-RPC Issue Type: Bug Affects Versions: 3.0b1 Environment: any Reporter: Zhou Jing The SSL support is a important issue in the XML-RPC, that is concerned by many people, but by now it seems that there is NOT a satisfied answer:-(... When I simply use an https URL and the default client, that is: XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl(); URL url = new URL( https://123.456.789.100:12345/xmlrpc_servlet/xmlrpc;); config.setServerURL(url); client = new XmlRpcClient(); client.setConfig(config); I get the erros like this: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source) at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.writeRequest(XmlRpcSunHttpTransport.java:67) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(Unknown Source) at sun.security.validator.PKIXValidator.engineValidate(Unknown Source) at sun.security.validator.Validator.validate(Unknown Source) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(Unknown Source) ... 19 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source) at java.security.cert.CertPathBuilder.build(Unknown Source) ... 24 more can anyone help me? and I wnat to know whether the client need get the certificate? thanks very much! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-92) The mismatch between request type and response type
[ http://issues.apache.org/jira/browse/XMLRPC-92?page=all ] Jochen Wiedmann closed XMLRPC-92: - Resolution: Won't Fix Won't fix; this behaviour is intentional, because using unsynchronized objects (like ArrayList or HashMap) is preferrable over the slow synchronized versions (like Vector or Hashtable). As I already wrote in XMLRPC-89, it is possible to install an automatic workaround for the parameters. This is not possible, though, for return values. Currently you have two options: - Use the ClientFactory, which is able to detect the requested return values. - Change your code to expect List or Map as return value. The mismatch between request type and response type --- Key: XMLRPC-92 URL: http://issues.apache.org/jira/browse/XMLRPC-92 Project: XML-RPC Type: Bug Versions: 3.0b1 Environment: any Reporter: Zhou Jing The request is like this: Vector params = new Vector(); Vector req = new Vector(); req.add(new Hashtable); params.add(req); so, in the client side, the req contains a Hashtable, but after invoking the execute method, the server will get another request, namely the req contains a HashMap NOT a Hashtable. on the other hand, about the response, if the response contains a Hashtable, that is: Vector response = new Vector(); response .add(new Hashtable); then, the client will get a response, that contains a HashMap NOT a Hashtable. BUT, I find that the package 2.1 doesn't have this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-93) About SSL
[ http://issues.apache.org/jira/browse/XMLRPC-93?page=comments#action_12420534 ] Jochen Wiedmann commented on XMLRPC-93: --- The information you are providing is insufficient. What web server are you using? What configuration on the web server? ... About SSL - Key: XMLRPC-93 URL: http://issues.apache.org/jira/browse/XMLRPC-93 Project: XML-RPC Type: Bug Versions: 3.0b1 Environment: any Reporter: Zhou Jing The SSL support is a important issue in the XML-RPC, that is concerned by many people, but by now it seems that there is NOT a satisfied answer:-(... When I simply use an https URL and the default client, that is: XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl(); URL url = new URL( https://123.456.789.100:12345/xmlrpc_servlet/xmlrpc;); config.setServerURL(url); client = new XmlRpcClient(); client.setConfig(config); I get the erros like this: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source) at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.writeRequest(XmlRpcSunHttpTransport.java:67) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(Unknown Source) at sun.security.validator.PKIXValidator.engineValidate(Unknown Source) at sun.security.validator.Validator.validate(Unknown Source) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(Unknown Source) ... 19 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source) at java.security.cert.CertPathBuilder.build(Unknown Source) ... 24 more can anyone help me? and I wnat to know whether the client need get the certificate? thanks very much! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-91) MinML does not handle XML encoding properly
[ http://issues.apache.org/jira/browse/XMLRPC-91?page=all ] Jochen Wiedmann closed XMLRPC-91: - Resolution: Won't Fix As indicated by the user, there is no need to change this. MinML does not handle XML encoding properly --- Key: XMLRPC-91 URL: http://issues.apache.org/jira/browse/XMLRPC-91 Project: XML-RPC Type: Bug Versions: 2.0 Reporter: Jochen Schwarze When you implement your own XML-RPC transport layer and call XmlRpcServer.execute(InputStream in, XmlRpcContext context); the following happens: First, XmlRpc.parse(InputStream is) calls MinML.parse(new InputSource(is). Then, MinML.parse(...) calls parse(new InputStreamReader(source.getByteStream())); which is wrong: this parses the stream with the platform default encoding, regardless of the actual encoding used in the XML stream, destroying, eg, UTF-8 encoded characters on Windows. Together with #XMLRPC-90, XmlRpc could be changed to use the Java 1.4 oder 1.5 platform XML parser which respect handle streams correctly and use any encoding declaration embedded in the XML stream. Workaround: Use XmlRpc.setDriver(xerces) and add xercesImpl.jar to the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-90) org.apache.xmlrpc.XmlRpc uses deprecated parser interface
[ http://issues.apache.org/jira/browse/XMLRPC-90?page=all ] Jochen Wiedmann closed XMLRPC-90: - Resolution: Won't Fix Use XML-RPC version 3. org.apache.xmlrpc.XmlRpc uses deprecated parser interface - Key: XMLRPC-90 URL: http://issues.apache.org/jira/browse/XMLRPC-90 Project: XML-RPC Type: Bug Versions: 2.0 Reporter: Jochen Schwarze The XmlRpc class uses the deprecated org.xml.sax.Parser API. Thus, you cannot use a current parser with the XmlRpc.setDriver(...) method. Should be upgraded to SAX2's org.xml.sax.XMLReader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-91) MinML does not handle XML encoding properly
[ http://issues.apache.org/jira/browse/XMLRPC-91?page=comments#action_12418023 ] Jochen Wiedmann commented on XMLRPC-91: --- Another workaround might be to ensure that the server doesn't use Non-ASCII characters by using the ASCII encoding when sending the documents. Given the fact that MinML is practically obsolete with version 3, I'd like to close this issue with WONTFIX. I'll leave the request open for some weeks in case some other developer steps forward and volunteers to create a patch. MinML does not handle XML encoding properly --- Key: XMLRPC-91 URL: http://issues.apache.org/jira/browse/XMLRPC-91 Project: XML-RPC Type: Bug Versions: 2.0 Reporter: Jochen Schwarze When you implement your own XML-RPC transport layer and call XmlRpcServer.execute(InputStream in, XmlRpcContext context); the following happens: First, XmlRpc.parse(InputStream is) calls MinML.parse(new InputSource(is). Then, MinML.parse(...) calls parse(new InputStreamReader(source.getByteStream())); which is wrong: this parses the stream with the platform default encoding, regardless of the actual encoding used in the XML stream, destroying, eg, UTF-8 encoded characters on Windows. Together with #XMLRPC-90, XmlRpc could be changed to use the Java 1.4 oder 1.5 platform XML parser which respect handle streams correctly and use any encoding declaration embedded in the XML stream. Workaround: Use XmlRpc.setDriver(xerces) and add xercesImpl.jar to the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-89) cannot use Vector, Hashtable, etc as arguments of metheds in handler
[ http://issues.apache.org/jira/browse/XMLRPC-89?page=all ]
Jochen Wiedmann closed XMLRPC-89:
-
Resolution: Fixed
Ok, I have committed a partial solution.
First of all, let me explain what the problem is. The XML-RPC library is
working internally with certain classes only. For example, an object array, a
list, and a vector are all internally mapped to an object array. Likewise, a
Hashtable, and Properties, are mapped to a Map.
Now, when we call a method, we are checking the method parameters. If, for
example, the method has a vector as first parameter, then we convert the object
array to a vector. No problem here. The situation is quite different, if we
return a value: We do not now, whether the caller wants an object array, or a
vector.
In short, if the client calls a method
Vector method(Vector);
then the result will be an object array. (Although everything works fine on the
server.) The recommended solution is to use the ClientFactory: An
implementation, which is created by the ClientFactory, knows about the return
type and can apply the same conversion. See
http://svn.apache.org/repos/asf/webservices/xmlrpc/trunk/src/site/apt/advanced.apt
for details on the ClientFactory.
cannot use Vector, Hashtable, etc as arguments of metheds in handler
Key: XMLRPC-89
URL: http://issues.apache.org/jira/browse/XMLRPC-89
Project: XML-RPC
Type: Bug
Environment: xmlrpc3.0b1 nightlybuild
Reporter: Zhi Han
Assignee: Jochen Wiedmann
Attachments: Req2.xml
In handler, I have methods like
public Vector getData(Vector req)
{
}
public Vector pingHandler()
{
}
On client side, I have code like:
Vector req = new Vector();
req.add(user);
Vector params = new Vector(1);
params.add(req);
client.execute(handler.getData, params);
I always got exception
Jun 22, 2006 7:34:37 AM org.apache.xmlrpc.server.XmlRpcStreamServer execute
SEVERE: execute: Error while performing request
org.apache.xmlrpc.XmlRpcException: Illegal argument for method getData in
class test.servlet.XMLRPCHandler
at
org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:71)
at
org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:43)
at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:67)
at
org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:196)
at
org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:91)
at
org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:99)
at test.servlet.XMLRPCServlet.doPost(XMLRPCServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
[jira] Closed: (XMLRPC-47) Add option to XmlRpcClient to ignore SSL certificate validation
[ http://issues.apache.org/jira/browse/XMLRPC-47?page=all ]
Jochen Wiedmann closed XMLRPC-47:
-
Resolution: Incomplete
No response, closing.
Add option to XmlRpcClient to ignore SSL certificate validation
---
Key: XMLRPC-47
URL: http://issues.apache.org/jira/browse/XMLRPC-47
Project: XML-RPC
Type: Bug
Components: Source
Versions: 1.1
Environment: Operating System: All
Platform: All
Reporter: Andriy Rozeluk
Assignee: Jochen Wiedmann
When using XML-RPC with SSL, and the server is using a self-signed certificate
(say on a staging server), the Java net libraries throw an exception.
As a suggestion, it should be possible to add a method, something like static
setIgnoreSSLCerts(boolean) to XmlRpcClient and XmlRpcClientLite, which will
override the TrustManager for the SSL connects. Thus, the user will have the
benefit of SSL encryption, without the hassle of having to have that
certificate
signed by a CA.
For example, before connect you can simply:
javax.net.ssl.SSLSocketFactory.getDefault();
X509TrustManager tm = new IgnoreSSLCertTrustManager();
KeyManager[] km = null;
TrustManager[] tma = {tm};
SSLContext sc = SSLContext.getInstance(SSL);
sc.init( km, tma, new java.security.SecureRandom() );
SSLSocketFactory sf1 = sc.getSocketFactory();
... then when you get your URLConnection:
URLConnection con = target.openConnection();
if ( con instanceof HttpsURLConnection ){
HttpsURLConnection secconn = (HttpsURLConnection)con;
secconn.setSSLSocketFactory( sf1 );
}
The IgnoreSSLCertTrustManager simply implements X509TrustManager and returns
true for both 'isClientTrusted' methods and does nothing for
'checkServerTrusted', then returns null for 'getAcceptedIssuers'.
My apologies for not submitting this as a patch, but unfortunately I don't
have
those tools available to me at present.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-85) CLONE -Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient
[ http://issues.apache.org/jira/browse/XMLRPC-85?page=all ] Jochen Wiedmann closed XMLRPC-85: - Resolution: Won't Fix As discussed on the mailing list, I do not like this feature. I have recommended that you ask other developers, but noone else has volunteered to pull the patch in. Consequently, I am closing the issue. CLONE -Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient -- Key: XMLRPC-85 URL: http://issues.apache.org/jira/browse/XMLRPC-85 Project: XML-RPC Type: Bug Components: Source Versions: 1.2 Environment: Operating System: Other Platform: Other Reporter: Danny Angus I submitted a patch to the dev list in december, it appears to have been forgotten. See: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=rpc- [EMAIL PROTECTED]msgNo=530 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-89) cannot use Vector, Hashtable, etc as arguments of metheds in handler
[
http://issues.apache.org/jira/browse/XMLRPC-89?page=comments#action_12417299 ]
Jochen Wiedmann commented on XMLRPC-89:
---
Please try the following: Does it work, if you change the use of Vector on the
server side to List? (Using a List is recommended anyways, for reasons of
performance.)
cannot use Vector, Hashtable, etc as arguments of metheds in handler
Key: XMLRPC-89
URL: http://issues.apache.org/jira/browse/XMLRPC-89
Project: XML-RPC
Type: Bug
Environment: xmlrpc3.0b1 nightlybuild
Reporter: Zhi Han
In handler, I have methods like
public Vector getData(Vector req)
{
}
public Vector pingHandler()
{
}
On client side, I have code like:
Vector req = new Vector();
req.add(user);
Vector params = new Vector(1);
params.add(req);
client.execute(handler.getData, params);
I always got exception
Jun 22, 2006 7:34:37 AM org.apache.xmlrpc.server.XmlRpcStreamServer execute
SEVERE: execute: Error while performing request
org.apache.xmlrpc.XmlRpcException: Illegal argument for method getData in
class test.servlet.XMLRPCHandler
at
org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:71)
at
org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:43)
at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:67)
at
org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:196)
at
org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:91)
at
org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:99)
at test.servlet.XMLRPCServlet.doPost(XMLRPCServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:536)
Caused by:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:65)
at
org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:43)
at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:67)
at
[jira] Assigned: (XMLRPC-89) cannot use Vector, Hashtable, etc as arguments of metheds in handler
[ http://issues.apache.org/jira/browse/XMLRPC-89?page=all ]
Jochen Wiedmann reassigned XMLRPC-89:
-
Assign To: Jochen Wiedmann
Preliminary inspection: This is a serious bug, because it will be a problem for
backwards compatibility. We can handle it for parameters by automatically
converting them. A possible solution for the return value might be to make the
type of return value for arrays configurable.
A workaround is to use object arrays, rather than lists, or vectors. In other
words, change the client code to
Object[] value = new Object[]{new Integer(0), abc};
Object[] parms = new Object[]{value};
Object[] result = (Object[]) client.execute(methodName, parms);
and the server methods signature to
public Object[] methodName(Object[] values) {
...
}
A fix should be available within the next days. I'll defer 3.0b1 until that.
cannot use Vector, Hashtable, etc as arguments of metheds in handler
Key: XMLRPC-89
URL: http://issues.apache.org/jira/browse/XMLRPC-89
Project: XML-RPC
Type: Bug
Environment: xmlrpc3.0b1 nightlybuild
Reporter: Zhi Han
Assignee: Jochen Wiedmann
Attachments: Req2.xml
In handler, I have methods like
public Vector getData(Vector req)
{
}
public Vector pingHandler()
{
}
On client side, I have code like:
Vector req = new Vector();
req.add(user);
Vector params = new Vector(1);
params.add(req);
client.execute(handler.getData, params);
I always got exception
Jun 22, 2006 7:34:37 AM org.apache.xmlrpc.server.XmlRpcStreamServer execute
SEVERE: execute: Error while performing request
org.apache.xmlrpc.XmlRpcException: Illegal argument for method getData in
class test.servlet.XMLRPCHandler
at
org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:71)
at
org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:43)
at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:67)
at
org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:196)
at
org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:91)
at
org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:99)
at test.servlet.XMLRPCServlet.doPost(XMLRPCServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:536)
Caused by:
java.lang.IllegalArgumentException: argument type mismatch
at
[jira] Closed: (XMLRPC-88) org.apache.xml.security.encryption.XMLCipher.removeContent
[ http://issues.apache.org/jira/browse/XMLRPC-88?page=all ]
Jochen Wiedmann closed XMLRPC-88:
-
Resolution: Invalid
I cannot see, why this would be an issue for Apache XML-RPC. I suggest using a
forum on java.sun.com, or a mailing list related to encryption.
org.apache.xml.security.encryption.XMLCipher.removeContent
--
Key: XMLRPC-88
URL: http://issues.apache.org/jira/browse/XMLRPC-88
Project: XML-RPC
Type: Bug
Components: Releases
Versions: unspecified
Environment: OS:Windows 2000
J2SE:1.5
JRE:1.5.0_06
Hardware: P-4 2.4 Ghz CPU, 2GB RAM.
Reporter: Arpit Doshi
Priority: Blocker
Hello,
I am trying to encrypt a XML file using XMLCipher class. The size of the file
is almost 35 MB, while encrypting the XML file it throws this error after
around 3 minutes.
The program works perfectly fine for file size of less than 5 MB. This is
very critical for our project and has to work as soon as possible.
Eventually we are going to port the application on AIX5.3
The piece of code I am using is:
public void encryptData() throws EncryptionException
{
final String methodName = encryptData;
XMLCipher keyCipher,xmlCipher = null;
Document document = null;
String encryptedFileName = null;
Key symmetricKey = null;
Key keyEncryptKey = null;
boolean exceptionOccured = false;
try
{
System.out.println(now parsing document);
document=parseFile( fileToBeEncrypted );
// generate symmetric key
symmetricKey = GenerateSymmetricKey();
// Get a key to be used for encrypting the symmetric key
keyEncryptKey = GenerateKeyEncryptionKey();
// Write the key to a file
//and pass the key and the name of file in which it has
to store the Key
storeKeyFile(keyEncryptKey,getKeyFileName(fileToBeEncrypted.toString()));
// initialize cipher and operation mode is to wrap a key
keyCipher
=XMLCipher.getInstance(XMLCipher.TRIPLEDES_KeyWrap);
keyCipher.init(XMLCipher.WRAP_MODE, keyEncryptKey);
// encrypt symmetric key
EncryptedKey encryptedKey =
keyCipher.encryptKey(document, symmetricKey);
// specify the element to encrypt, ideally it will be
root element
Element rootElement = document.getDocumentElement();
Element elementToEncrypt = rootElement;
if (elementToEncrypt == null)
{
throw new EncryptionException(Element to Encrypt is
null since the filename may not be correct +
or the file to be
encrypted may not be well formed +
Please check in File
+ AMLFeederConfiguration.properties);
}
// initialize cipher for encrypting XML data using
operation mode of ENCRYPT_MODE
xmlCipher = XMLCipher.getInstance(XMLCipher.TRIPLEDES);
xmlCipher.init(XMLCipher.ENCRYPT_MODE, symmetricKey);
// add key info to encrypted data element, so that
within the encrypted data,
// there is also information about the key, that should
be used to decrypt the data
EncryptedData encryptedDataElement =
xmlCipher.getEncryptedData();
KeyInfo keyInfo = new KeyInfo(document);
keyInfo.add(encryptedKey);
encryptedDataElement.setKeyInfo(keyInfo);
Problem is caused while calling doFinal() // do the actual encryption
boolean encryptContentsOnly = true;
xmlCipher.doFinal(document, elementToEncrypt,
encryptContentsOnly);
//this will return x_e.xml
encryptedFileName =
getEncryptedFileNameToWrite(fileToBeEncrypted.toString());
// write the results to a file
writeEncryptedDocToFile(document, encryptedFileName);
[jira] Created: (AXIS2-813) Automatically generated WSDL fails to generate complex type for inner classes
Automatically generated WSDL fails to generate complex type for inner classes - Key: AXIS2-813 URL: http://issues.apache.org/jira/browse/AXIS2-813 Project: Apache Axis 2.0 (Axis2) Type: Bug Components: wsdl Reporter: Jochen Wiedmann Priority: Minor I have created a class AddressManager, which uses an inner class Address. The inner class is used as a parameter and result type in AddressManager. As a next step, I have created a services.xml, in order to make the AddressManager available as a web service. I followed the descriptions in the section on Use Axis2's primary interfaces (APIs) and implement the business logic. from userguide2.html. Deploying this web service works fine. The automatically generated WSDL looks good at first glance. However, closer inspection shows that the complexType, which is created for Address doesn't contain any elements, or attributes. This is caused by the fact that Address is an inner class: If you refactor the inner class as an outer class, then everything works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-83) Problems with Date
[ http://issues.apache.org/jira/browse/XMLRPC-83?page=all ] Jochen Wiedmann closed XMLRPC-83: - Resolution: Cannot Reproduce See my comments on the attached sample project. Problems with Date -- Key: XMLRPC-83 URL: http://issues.apache.org/jira/browse/XMLRPC-83 Project: XML-RPC Type: Bug Versions: 3.0a1 Environment: xmlrpc-*-3.0b1-SNAPSHOT Reporter: Alexander Sydorenko Priority: Critical Attachments: XMLRPC-83.tar.bz2 I'm getting this error: org.apache.xmlrpc.common.XmlRpcExtensionException: Serializable objects aren't supported, if isEnabledForExtensions() == false at org.apache.xmlrpc.common.TypeFactoryImpl.getSerializer(TypeFactoryImpl.java:155) when trying to return Calendar and this error: java.lang.ClassCastException: java.util.Date at org.apache.ws.commons.util.XsDateTimeFormat.format(XsDateTimeFormat.java:238) at java.text.Format.format(Format.java:133) at org.apache.xmlrpc.serializer.DateSerializer.write(DateSerializer.java:31) at org.apache.xmlrpc.serializer.XmlRpcWriter.writeValue(XmlRpcWriter.java:144) at org.apache.xmlrpc.serializer.XmlRpcWriter.write(XmlRpcWriter.java:99) at org.apache.xmlrpc.server.XmlRpcStreamServer.writeResponse(XmlRpcStreamServer.java:89) at org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:221) at org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:91) at org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:99) for java.util.Date. org.apache.ws.commons.util.XsDateTimeFormat.format() works only with Calendar... and org.apache.xmlrpc.common.TypeFactoryImpl.getSerializer treats Calendar as Serializable... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-66) Throwing exception to create RPC fault results in exception name transmitted over the wire
[ http://issues.apache.org/jira/browse/XMLRPC-66?page=all ] Jochen Wiedmann closed XMLRPC-66: - Resolution: Fixed No reply, closing. Throwing exception to create RPC fault results in exception name transmitted over the wire -- Key: XMLRPC-66 URL: http://issues.apache.org/jira/browse/XMLRPC-66 Project: XML-RPC Type: Bug Versions: 2.0 Reporter: Oliver Cole Assignee: Jochen Wiedmann If you throw an exception at any point in or below the named method in the handler object registered with the XmlRpcServer object, like so, throw new IllegalArgumentException(foobar); then the name of the exception is returned in the RPC fault sent over the wire, like so: value java.lang.Exception: java.lang.IllegalArgumentException: foobar /value This is of course, bad, as this is not implementation independant. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-81) Failed to parse servers response:Unexpected non-whitespace character data
[ http://issues.apache.org/jira/browse/XMLRPC-81?page=all ] Jochen Wiedmann closed XMLRPC-81: - Resolution: Invalid The servers response is invalid: membernameurl/namevaluestringhttp://jnn.blogbus.com/index.rdflt;/stringgt;lt;/valuegt;lt;/member This should obviously be membernameurl/namevaluestringhttp://jnn.blogbus.com/index.rdf/string/value/member Failed to parse servers response:Unexpected non-whitespace character data - Key: XMLRPC-81 URL: http://issues.apache.org/jira/browse/XMLRPC-81 Project: XML-RPC Type: Bug Components: Releases Versions: 3.0a1 Environment: Windows 2000 | JDK1.5 | ANT 1.6.5 Reporter: maomaode Priority: Critical The server is PHP XML-RPC, the client used XMLRPC 3.0a, but i got the following exception: [java] Exception in thread main org.apache.xmlrpc.client.XmlRpcClientException: Failed to parse servers response: Unexpecte d non-whitespace character data [java] at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(XmlRpcStreamTransport.java:267) [java] at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:216) [java] at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:53) [java] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:166) [java] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:136) [java] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:125) [java] at com.bokeland.imports.web.XmlRpcService.displayImporters(XmlRpcService.java:17) [java] at com.bokeland.imports.web.XmlRpcService.main(XmlRpcService.java:24) [java] Caused by: [java] org.xml.sax.SAXParseException: Unexpected non-whitespace character data [java] at org.apache.xmlrpc.parser.TypeParserImpl.characters(TypeParserImpl.java:79) [java] at org.apache.xmlrpc.parser.RecursiveTypeParserImpl.characters(RecursiveTypeParserImpl.java:139) [java] at org.apache.xmlrpc.parser.MapParser.characters(MapParser.java:79) [java] at org.apache.xmlrpc.parser.RecursiveTypeParserImpl.characters(RecursiveTypeParserImpl.java:142) [java] at org.apache.xmlrpc.parser.RecursiveTypeParserImpl.characters(RecursiveTypeParserImpl.java:142) [java] at org.apache.xerces.parsers.AbstractSAXParser.characters(Unknown Source) [java] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source) [java] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) [java] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [java] at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(XmlRpcStreamTransport.java:265) [java] at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:216) [java] at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:53) [java] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:166) [java] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:136) [java] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:125) [java] at com.bokeland.imports.web.XmlRpcService.displayImporters(XmlRpcService.java:17) [java] at com.bokeland.imports.web.XmlRpcService.main(XmlRpcService.java:24) [java] Java Result: 1 The request message is: ?xml version=1.0 encoding=UTF-8?methodCallmethodNameblogger.getImporters/methodNameparamsparamvaluemyname/value/paramparamvaluemyname/value/param/params/methodCall The response message is: ?xml version=1.0 encoding=UTF-8? methodResponse params param value arraydata valuestruct membernameblog_id/namevaluestring333/string/value/member membernameuser_id/namevaluestring333/string/value/member membernameurl/namevaluestringhttp://jnn.blogbus.com/index.rdf/string/value/member membernamecategory_ids/namevaluearraydata valuestring905/string/value /data/array/value/member membernameexternal_category_ids/namevalueboolean0/boolean/value/member membernamecomments/namevalueint0/int/value/member membernamestatus/namevaluestring1/string/value/member
[jira] Closed: (XMLRPC-82) Unknown type: string
[ http://issues.apache.org/jira/browse/XMLRPC-82?page=all ] Jochen Wiedmann closed XMLRPC-82: - Resolution: Fixed This is fixed in svn since some time. Try one of the nightly builds, which are available from http://cvs.apache.org/dist/ws/xmlrpc/nightly/ Unknown type: string Key: XMLRPC-82 URL: http://issues.apache.org/jira/browse/XMLRPC-82 Project: XML-RPC Type: Bug Versions: 3.0a1 Reporter: Alexander Sydorenko Priority: Critical This request methodCall methodNameserver.ClientJoin/methodName params param valuestringfsdf4wtr45/string/value /param /params /methodCall doesn't work. I've got this message Failed to parse XML-RPC request: Unknown type: string -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (XMLRPC-18) Secure functionality is poorly documented, and difficult to get working.
[ http://issues.apache.org/jira/browse/XMLRPC-18?page=all ] Jochen Wiedmann closed XMLRPC-18: - Resolution: Won't Fix Assign To: (was: rpc-dev mailing list) I am honestly respecting Martin's work. Nevertheless, this is still incomplete, after almost four years. I am closing this now. For version 3, I really suggest to use an SSL implementation like java.net or org.apache.httpclient on the client side and a serious servlet engine like Tomcat or Jetty on the server side, Secure functionality is poorly documented, and difficult to get working. Key: XMLRPC-18 URL: http://issues.apache.org/jira/browse/XMLRPC-18 Project: XML-RPC Type: Bug Components: Source Versions: unspecified Environment: Operating System: Other Platform: All Reporter: Martin Redington Attachments: SECURE_README.txt, TestSecureClient.java, TestSecureServer.java, list_archive_info.txt, original_post.txt Secure functionality (e.g. using the SecureWebServer and SecureXMLRPCClient classes is poorly documented, and very difficult for a naive user to get to work correctly. The non-obviousness of the correct approach is illustrated by the failure of queries to rpc-users on how to get the attached sample code to work to generate any response. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (XMLRPC-47) Add option to XmlRpcClient to ignore SSL certificate validation
[ http://issues.apache.org/jira/browse/XMLRPC-47?page=all ]
Jochen Wiedmann reassigned XMLRPC-47:
-
Assign To: Jochen Wiedmann (was: rpc-dev mailing list)
Add option to XmlRpcClient to ignore SSL certificate validation
---
Key: XMLRPC-47
URL: http://issues.apache.org/jira/browse/XMLRPC-47
Project: XML-RPC
Type: Bug
Components: Source
Versions: 1.1
Environment: Operating System: All
Platform: All
Reporter: Andriy Rozeluk
Assignee: Jochen Wiedmann
When using XML-RPC with SSL, and the server is using a self-signed certificate
(say on a staging server), the Java net libraries throw an exception.
As a suggestion, it should be possible to add a method, something like static
setIgnoreSSLCerts(boolean) to XmlRpcClient and XmlRpcClientLite, which will
override the TrustManager for the SSL connects. Thus, the user will have the
benefit of SSL encryption, without the hassle of having to have that
certificate
signed by a CA.
For example, before connect you can simply:
javax.net.ssl.SSLSocketFactory.getDefault();
X509TrustManager tm = new IgnoreSSLCertTrustManager();
KeyManager[] km = null;
TrustManager[] tma = {tm};
SSLContext sc = SSLContext.getInstance(SSL);
sc.init( km, tma, new java.security.SecureRandom() );
SSLSocketFactory sf1 = sc.getSocketFactory();
... then when you get your URLConnection:
URLConnection con = target.openConnection();
if ( con instanceof HttpsURLConnection ){
HttpsURLConnection secconn = (HttpsURLConnection)con;
secconn.setSSLSocketFactory( sf1 );
}
The IgnoreSSLCertTrustManager simply implements X509TrustManager and returns
true for both 'isClientTrusted' methods and does nothing for
'checkServerTrusted', then returns null for 'getAcceptedIssuers'.
My apologies for not submitting this as a patch, but unfortunately I don't
have
those tools available to me at present.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (XMLRPC-47) Add option to XmlRpcClient to ignore SSL certificate validation
[
http://issues.apache.org/jira/browse/XMLRPC-47?page=comments#action_12383281 ]
Jochen Wiedmann commented on XMLRPC-47:
---
I understand the issues value. However, I haven't got sufficient knowledge to
deal with it myself.
If you can come up with a patch against 2.0.1 in the next two weeks, I am ready
to pull it in. Otherwise, I'd close the issue after almost two years.
Add option to XmlRpcClient to ignore SSL certificate validation
---
Key: XMLRPC-47
URL: http://issues.apache.org/jira/browse/XMLRPC-47
Project: XML-RPC
Type: Bug
Components: Source
Versions: 1.1
Environment: Operating System: All
Platform: All
Reporter: Andriy Rozeluk
Assignee: Jochen Wiedmann
When using XML-RPC with SSL, and the server is using a self-signed certificate
(say on a staging server), the Java net libraries throw an exception.
As a suggestion, it should be possible to add a method, something like static
setIgnoreSSLCerts(boolean) to XmlRpcClient and XmlRpcClientLite, which will
override the TrustManager for the SSL connects. Thus, the user will have the
benefit of SSL encryption, without the hassle of having to have that
certificate
signed by a CA.
For example, before connect you can simply:
javax.net.ssl.SSLSocketFactory.getDefault();
X509TrustManager tm = new IgnoreSSLCertTrustManager();
KeyManager[] km = null;
TrustManager[] tma = {tm};
SSLContext sc = SSLContext.getInstance(SSL);
sc.init( km, tma, new java.security.SecureRandom() );
SSLSocketFactory sf1 = sc.getSocketFactory();
... then when you get your URLConnection:
URLConnection con = target.openConnection();
if ( con instanceof HttpsURLConnection ){
HttpsURLConnection secconn = (HttpsURLConnection)con;
secconn.setSSLSocketFactory( sf1 );
}
The IgnoreSSLCertTrustManager simply implements X509TrustManager and returns
true for both 'isClientTrusted' methods and does nothing for
'checkServerTrusted', then returns null for 'getAcceptedIssuers'.
My apologies for not submitting this as a patch, but unfortunately I don't
have
those tools available to me at present.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Kommentiert: (XMLRPC-80) XML-RPC server not conforming to spec
[ http://issues.apache.org/jira/browse/XMLRPC-80?page=comments#action_12378878 ] Jochen Wiedmann commented on XMLRPC-80: --- You did not specify a version of XML-RPC? XML-RPC server not conforming to spec - Key: XMLRPC-80 URL: http://issues.apache.org/jira/browse/XMLRPC-80 Project: XML-RPC Type: Bug Components: Source Reporter: M. van Cuijk Priority: Critical The XML-RPC spec specifies: If the procedure call has parameters, the methodCall must contain a params sub-item. The params sub-item can contain any number of params, each of which has a value. So when there are no parameters, no params sub-item is required. The current implementation of the XML-RPC server throws an exception when a message with no params sub-item is received. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Geschlossen: (XMLRPC-51) XmlWriter.writeObject doesn't enclose Strings params in string tags
[ http://issues.apache.org/jira/browse/XMLRPC-51?page=all ]
Jochen Wiedmann closed XMLRPC-51:
-
Assign To: (was: rpc-dev mailing list)
Made the XmlWriter public and added an faq entry which describes how to achieve
getting string tags in the FAQ.
XmlWriter.writeObject doesn't enclose Strings params in string tags
-
Key: XMLRPC-51
URL: http://issues.apache.org/jira/browse/XMLRPC-51
Project: XML-RPC
Type: Bug
Components: Source
Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Olivier Lagache
The bug 10689 is with Status:RESOLVED and Resolution:INVALID.
I don't undestand why.
If I add the startElementend and the endElement(string) in source file all
is
ok. When I called a XML-RPC server (not mine) without this modification I
obtained an XmlRpcException:malformed xml: Parsing failed
else if (obj instanceof String)
{
startElement(string); //ADD
chardata(obj.toString());
endElement(string); //ADD
}
I don't know if it's the best solution but is good in my case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Geschlossen: (XMLRPC-10) XmlRpc$XmlWriter.writeObject() doesn't enclose Strings params in string tags
[ http://issues.apache.org/jira/browse/XMLRPC-10?page=all ]
Jochen Wiedmann closed XMLRPC-10:
-
Resolution: Duplicate
Duplicate of XMLRPC-51 which was fixed today.
XmlRpc$XmlWriter.writeObject() doesn't enclose Strings params in string tags
--
Key: XMLRPC-10
URL: http://issues.apache.org/jira/browse/XMLRPC-10
Project: XML-RPC
Type: Bug
Components: Source
Versions: unspecified
Environment: Operating System: All
Platform: All
Reporter: Ralf Müller
As far as I'm up to date with it the XML-RPC spec says that paramters of type
String have to be enclosed in string tags. At least when talking to the
Skyrix
skyxmlrpcd this is mandatory.
Fix:
*** XmlRpc.java.origThu Jul 11 16:13:16 2002
--- XmlRpc.java Thu Jul 11 16:13:44 2002
***
*** 695,701
--- 695,703
}
else if (obj instanceof String)
{
+ startElement(string);
chardata(obj.toString());
+ endElement(string);
}
else if (obj instanceof Integer)
{
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (XMLRPC-66) Throwing exception to create RPC fault results in exception name transmitted over the wire
[ http://issues.apache.org/jira/browse/XMLRPC-66?page=all ] Jochen Wiedmann reassigned XMLRPC-66: - Assign To: Jochen Wiedmann Throwing exception to create RPC fault results in exception name transmitted over the wire -- Key: XMLRPC-66 URL: http://issues.apache.org/jira/browse/XMLRPC-66 Project: XML-RPC Type: Bug Versions: 2.0 Reporter: Oliver Cole Assignee: Jochen Wiedmann If you throw an exception at any point in or below the named method in the handler object registered with the XmlRpcServer object, like so, throw new IllegalArgumentException(foobar); then the name of the exception is returned in the RPC fault sent over the wire, like so: value java.lang.Exception: java.lang.IllegalArgumentException: foobar /value This is of course, bad, as this is not implementation independant. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (XMLRPC-56) An asynchronous callback object that manages timeouts
[ http://issues.apache.org/jira/browse/XMLRPC-56?page=all ]
Jochen Wiedmann reassigned XMLRPC-56:
-
Assign To: Jochen Wiedmann
An asynchronous callback object that manages timeouts
-
Key: XMLRPC-56
URL: http://issues.apache.org/jira/browse/XMLRPC-56
Project: XML-RPC
Type: New Feature
Reporter: Ken Weiner
Assignee: Jochen Wiedmann
Attachments: TimingOutAsyncCallback.java
I have created an object that helps clients to XmlRpcClient impose a timeout
value onto a call to send an XML-RPC message.
I want to propose that this callback object be added to the XML-RPC codebase.
Feel free to change the name of the class or any of its variables or methods.
Here is example client code for the class:
TimingOutAsyncCallback callback = new TimingOutAsyncCallback(1);
XmlRpcClient client = new XmlRpcClient(url);
client.executeAsync(methodName, aVector, callback);
callback.waitForResponse();
if (callback.getException() != null) {
throw callback.getException();
}
Object result = callback.getResult();
Here is the code for TimingOutAsyncCallback:
/**
* A callback object that can wait up to a specified amount
* of time for the XML-RPC response.
*/
protected class TimingOutAsyncCallback implements AsyncCallback {
private long timeout = 10 * 1000; // default to 10 seconds
private Object result;
private Exception exception;
public TimingOutAsyncCallback() {
super();
}
public TimingOutAsyncCallback(long timeout) {
this.timeout = timeout;
}
public void setTimeout(long timeout) {
this.timeout = timeout;
}
public long getTimeout() {
return this.timeout;
}
public Object getResult() {
return this.result;
}
public Exception getException() {
return this.exception;
}
public synchronized void handleError(Exception exception, URL url, String
method) {
this.exception = exception;
this.notify();
}
public synchronized void handleResult(Object result, URL url, String
method) {
this.result = result;
this.notify();
}
public synchronized void waitForResponse() throws InterruptedException {
this.wait(timeout);
}
}
Please comment if you have any questions or comments.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Geschlossen: (XMLRPC-10) XmlRpc$XmlWriter.writeObject() doesn't enclose Strings params in string tags
[ http://issues.apache.org/jira/browse/XMLRPC-10?page=all ]
Jochen Wiedmann closed XMLRPC-10:
-
Resolution: Fixed
Assign To: (was: rpc-dev mailing list)
In version 3, this can be done by overwriting TypeFactoryImpl and return a
custom subclass of StringSerializer.
XmlRpc$XmlWriter.writeObject() doesn't enclose Strings params in string tags
--
Key: XMLRPC-10
URL: http://issues.apache.org/jira/browse/XMLRPC-10
Project: XML-RPC
Type: Bug
Components: Source
Versions: unspecified
Environment: Operating System: All
Platform: All
Reporter: Ralf Müller
As far as I'm up to date with it the XML-RPC spec says that paramters of type
String have to be enclosed in string tags. At least when talking to the
Skyrix
skyxmlrpcd this is mandatory.
Fix:
*** XmlRpc.java.origThu Jul 11 16:13:16 2002
--- XmlRpc.java Thu Jul 11 16:13:44 2002
***
*** 695,701
--- 695,703
}
else if (obj instanceof String)
{
+ startElement(string);
chardata(obj.toString());
+ endElement(string);
}
else if (obj instanceof Integer)
{
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Geschlossen: (XMLRPC-25) Authenticated handler
[ http://issues.apache.org/jira/browse/XMLRPC-25?page=all ]
Jochen Wiedmann closed XMLRPC-25:
-
Resolution: Fixed
Assign To: (was: rpc-dev mailing list)
In version 3, it is possible to provide custom authentication by supplying an
instance of AuthenticationHandler.
Authenticated handler
-
Key: XMLRPC-25
URL: http://issues.apache.org/jira/browse/XMLRPC-25
Project: XML-RPC
Type: Bug
Components: Source
Versions: unspecified
Environment: Operating System: Other
Platform: All
Reporter: Dejan Bosanac
Attachments: authenticated.patch, authenticated.patch
Enable to expose any business object as a handler that performs basic HTTP
authentication, but not to be forced to call only execute() method of the
handler.
If AuthenticatedXmlRpcHandler is used you are forced to call only execute
method. The problem with this approach is that we are responsible for
determining what action should be used. This could be a easy task in most
cases,
but it could be a big challenge in a complex handler.
Idea is to make your object implement AuthenticatedHandler interface and only
write authenticate method:
public boolean authenticate(String username, String password);
Method should do whatever it takes to check if a username and password belongs
to a valid user. It could connect to a relational database, LDAP or any other
user storage and return true if user is permitted for a call or false
otherwise.
After authorization, client can make a call to any public method of your
handler.
XmlRpcClient client = new XmlRpcClient(url);
try
{
client.setBasicAuthentication(username, password);
client.execute(authenticated.test, params);
}
catch(Exception ex)
{
System.err.println(Error: + ex.getMessage());
}
The actual test method will be called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Geschlossen: (XMLRPC-43) LiteXmlRpcTransport throws IOExcpetion 'socket closed'
[ http://issues.apache.org/jira/browse/XMLRPC-43?page=all ] Jochen Wiedmann closed XMLRPC-43: - Resolution: Fixed Assign To: (was: rpc-dev mailing list) Version 1 is no longer supported. It is unknown, whether this problem does still apply to version 2, not to mention version 3. If it does, please reopen the issue. LiteXmlRpcTransport throws IOExcpetion 'socket closed' -- Key: XMLRPC-43 URL: http://issues.apache.org/jira/browse/XMLRPC-43 Project: XML-RPC Type: Bug Components: Source Versions: 1.2 Environment: Operating System: All Platform: All Reporter: Spencer Proffit When receiveing a response that isn't loaded into the input stream buffer, you will get an IOException caused by socket closed. This is caused in sendXmlRpc where closeConnection is called (unless keepalive is on) before 'in' is returned. This means that 'close' is called on the socket before the caller of 'sendXmlRpc' ever gets the InputStream. If the response is already loaded in the BufferedInputStream there is no problem, but for slower, larger responses, you will get the Exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Geschlossen: (XMLRPC-44) Handling whitespace in XML-RPC call arguments
[ http://issues.apache.org/jira/browse/XMLRPC-44?page=all ] Jochen Wiedmann closed XMLRPC-44: - Resolution: Won't Fix Assign To: (was: rpc-dev mailing list) Version 1 is no longer supported. It is unknown, whether the problem still applies to version 2. If it does: It doesn't seem to make sense to introduce a very incompatible change at this point of the maintenance. It is recommended to use another XML parser than MinML. Version 3 uses another XML parser anyways. Handling whitespace in XML-RPC call arguments -- Key: XMLRPC-44 URL: http://issues.apache.org/jira/browse/XMLRPC-44 Project: XML-RPC Type: Bug Components: Source Versions: 1.1 Environment: Operating System: All Platform: PC Reporter: Simon Miles I've got an application that performs an XML-RPC call that contains an argument that is an array of strings. I encountered a problem when a string in the array is set to all spaces, when the actual method call is invoked the string is empty. It no longer contains the spaces. I did a little debugging and found that the removal of the spaces occured within the default XML parser, MinML. Using a test program and running MinML outside of XML-RPC I found that the parser was not emiting characters if an element contained only spaces. Running my simple test file through other parsers (xerces and Piccolo), these programs did emit the spaces. Example file contained t1/t1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
