from:"Thilo Frotscher"

When engaging a module with a service, the module is engaged with each 
operation twice
--

 Key: AXIS2-1541
 URL: http://issues.apache.org/jira/browse/AXIS2-1541
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
 Environment: Axis2 1.1 Snapshot of 29 Oct
Reporter: Thilo Frotscher
Priority: Critical


Not sure about the priority of this bug, but I think it might be critical...

I created a module that contains a module class. For testing purposes, method 
engageNotify log a message every time it is invoked. The logging message 
provides information about the kind of engagement. When I use the admin 
frontend to engage the module with a service, the logging messages indicate 
that the module is engaged twice with every service operation (engageNotify 
invoked twice per operation):

LogModule was engaged with service: MyService
LogModule was engaged with operation: Op1
LogModule was engaged with operation: Op1
LogModule was engaged with operation: Op2
LogModule was engaged with operation: Op2
LogModule was engaged with operation: Op3
LogModule was engaged with operation: Op3
LogModule was engaged with operation: Op4
LogModule was engaged with operation: Op4

Here's the implementation of engageNotify:

public void engageNotify(AxisDescription axisDescription) throws 
AxisFault {
StringBuilder msg = new StringBuilder();
msg.append("LogModule was engaged with");

if (axisDescription instanceof AxisServiceGroup) {
msg.append(" service group: ");

msg.append(((AxisServiceGroup)axisDescription).getServiceGroupName());
} else if (axisDescription instanceof AxisService) {
msg.append(" service: ");
msg.append(((AxisService)axisDescription).getName());
} else if (axisDescription instanceof AxisOperation) {
msg.append(" operation: ");
msg.append(((AxisOperation)axisDescription).getName());
}

System.out.println(msg);
}


-- 
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-1540) Typos / usability of web admin console

[ 
http://issues.apache.org/jira/browse/AXIS2-1540?page=comments#action_12445429 ] 

Thilo Frotscher commented on AXIS2-1540:


Some more... :-)

Available services:
- "epr" should be changed to "EPR" for REST services

Engage module...For an operation
- "Select an Axis service from the combo and click on the 'View Operations' 
button to view operation specific Chains".
   >> It's Axis2, isn't it :-)
   >> Clicking the button does NOT take the user to an overview of 
operation-specific chains! The text should be something like: 
" Select a service and click on "View Operations" to select a module 
and an operation"

- next step: "Engage Module for an Operation": 
  -  "To engage a module for an axis operation" - should be: "To engage a 
module for a service operation"
  -  "2. select the axis operation you like the module to be engaged." should 
be  "2. select the service operation you like the module to be engaged for"

Global Chains:
- "In Flow Up To and Including Dispatcher" should be " In Flow up to Dispatch"
   BTW: why "up to Dispatch" at all? For the other three flows there is no 
indication that there are additional phases

Available phases:
- why is "soapmonitorPhase" the only phase that starts with a character in 
lower case?
- "User Defined Phases" should be "User-defined Phases"
 



> Typos / usability of web admin console
> --
>
> Key: AXIS2-1540
> URL: http://issues.apache.org/jira/browse/AXIS2-1540
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
> Environment: Axis2 1.1 Snapshot of 29 Oct
>Reporter: Thilo Frotscher
>Priority: Trivial
>
> Admin login:
> - Warning: Please note that configuration changes done though the 
> administration console will be lost when the server is restarted.
>   >> th_r_ough
> - Why was the login form moved to the right??
> Deactivate services
> - What's the purpose of the checkbox "Deactivate" and the "Clear" button? 
> They don't seem to make any sense. If I want to deactivate a service, I'd 
> just select the service and click the "deactivate" button.   
> - Same issue with activation of services

-- 
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-1540) Typos / usability of web admin console

[ 
http://issues.apache.org/jira/browse/AXIS2-1540?page=comments#action_12445428 ] 

Thilo Frotscher commented on AXIS2-1540:


One more...

Available services:
- The service status (active / inactive) should be displayed in a more 
eye-catching way. 

   Suggestion: get rid of the line "Service status:...", display status behind 
the service name (i.e. the link to the WSDL) instead, but only if service is 
inactive 
   - for inactive services: MyService (deactivated)
   - for active services: MyService

  

> Typos / usability of web admin console
> --
>
> Key: AXIS2-1540
> URL: http://issues.apache.org/jira/browse/AXIS2-1540
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
> Environment: Axis2 1.1 Snapshot of 29 Oct
>Reporter: Thilo Frotscher
>Priority: Trivial
>
> Admin login:
> - Warning: Please note that configuration changes done though the 
> administration console will be lost when the server is restarted.
>   >> th_r_ough
> - Why was the login form moved to the right??
> Deactivate services
> - What's the purpose of the checkbox "Deactivate" and the "Clear" button? 
> They don't seem to make any sense. If I want to deactivate a service, I'd 
> just select the service and click the "deactivate" button.   
> - Same issue with activation of services

-- 
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-1540) Typos / usability of web admin console

Typos / usability of web admin console
--

 Key: AXIS2-1540
 URL: http://issues.apache.org/jira/browse/AXIS2-1540
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
 Environment: Axis2 1.1 Snapshot of 29 Oct
Reporter: Thilo Frotscher
Priority: Trivial


Admin login:
- Warning: Please note that configuration changes done though the 
administration console will be lost when the server is restarted.
  >> th_r_ough
- Why was the login form moved to the right??

Deactivate services
- What's the purpose of the checkbox "Deactivate" and the "Clear" button? They 
don't seem to make any sense. If I want to deactivate a service, I'd just 
select the service and click the "deactivate" button.   
- Same issue with activation of services

-- 
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]

[Axis2] Unexpected message when requesting ?policy

2006-10-28 Thread Thilo Frotscher



Hi,

I am using the snapshot of 29 Oct. After starting the Axis2 web app,
I entered the following URL into my browser:

http://localhost:8080/axis2/services/version?policy

I know the Version service doesn't use WS-Policy, however the message
that appeared on the screen was quite surprising:

Please enable REST support in WEB-INF/conf/axis2.xml and WEB-INF/web.xml

I thought the ?policy option would deliver a service's policy. Is that
still the case? If yes, and if there's no such policy for a given service,
I think a different message should be displayed... Is that a new JIRA?

Cheers,
Thilo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2-1346) Provide a way to expose interface to client instead of concrete class

2006-10-20 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-1346?page=comments#action_12443784 ] 

Thilo Frotscher commented on AXIS2-1346:



- This parameter should be called "objectSupplier", not "objectSuppler"... an 
_i_ is missing. The same applies to the name of the new class.

- Why does "ServiceClass" start with a capital "S" while "objectSupplier" 
starts with a lower "o"? If there was a common spelling policy across all 
configuration files, I would make life a lot easier.

Thanks,
Thilo




> Provide a way to expose interface to client instead of concrete class
> -
>
> Key: AXIS2-1346
> URL: http://issues.apache.org/jira/browse/AXIS2-1346
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: deployment
>Reporter: Deepal Jayasinghe
> Assigned To: Deepal Jayasinghe
>Priority: Blocker
>
> There may be instance where service author has interface that he need to 
> generate wsdl , while he has separate service impl class. With current Axis2 
> impl there is no way to achieve this goal. 
> I think we can solve this problem by adding one more optional parameter to 
> services.xml
> qualified name of the service interface 
>  
> in addition to 
> qualified name of the service class 
>  

-- 
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]

JAXB-RI, JaxMe support in Axis2 1.1?

2006-10-19 Thread Thilo Frotscher



Hi,

just for clarification: will there be support for JAXB-RI and JaxMe in Axis2 1.1
or were these two deferred to later releases?

Thanks,
Thilo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2] Distribution packaging restructuring

2006-10-19 Thread Thilo Frotscher




Thilo Frotscher wrote:
I couldn't agress less :-) 


Sorry, I  meant "agree" .

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2] Distribution packaging restructuring

2006-10-18 Thread Thilo Frotscher



Sanjiva Weerawarana wrote:

The war we ship is useless for *any* user except to run the sample
services. That's it. NOTHING else. Do you agree with that assessment?


I couldn't agress less :-) I find the WAR very useful. Especially for
beginners and first time users. They can just copy that file into their
web container and start playing with the new framework. They will find
out that there are some new concepts like modules or upload mechanisms,
and they will get a good first impression within minutes. It's also a
very nice show case to see the service upload button work. It'd be nice
to have a sample AAR for download somewhere, as well as a sample client,
so that you can just upload the AAR with a few clicks, start the client
and... it works.

On the other hand, if the first impression of Axis2 1.1 will be, that
there is no WAR anymore and that you first have to build it yourself,
many users will be disappointed and won't understand why it was removed
(as I wouldn't understand it). It doesn't hurt to offer it for download,
it's just a file on a web server, that can be created automatically in
the build process for the release.

Personally, I use the WAR file very often just to test some stuff. I
have a collection of AAR files, which I can copy into the WARs and
start testing.

Also, please don't forget that not every person who is potentially
interested in Axis2 has Ant installed on their machine! Sure, they can
install it, but that's just an annoying, additional step.

I agree with Deepal: don't remove the WAR.

PS: Why does it work with Tomcat only?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2-1406) Link "Engage Modules" - "For a Service" causes exception

Link "Engage Modules" - "For a Service" causes exception 
-

 Key: AXIS2-1406
 URL: http://issues.apache.org/jira/browse/AXIS2-1406
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: admin console
Affects Versions: 1.1
 Environment: Axis2 1.1 RC1
    Reporter: Thilo Frotscher
Priority: Blocker


When clicking the link "For a Service" under "Engage Modules" the following 
exception is logged in the server log:

WARNING: Error dispatching request /axis2/axis2-admin/engageToService
java.lang.reflect.InvocationTargetException
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:585)
at 
org.apache.axis2.transport.http.AbstractAgent.handle(AbstractAgent.java:77)
at 
org.apache.axis2.transport.http.AdminAgent.handle(AdminAgent.java:104)
at 
org.apache.axis2.transport.http.AxisAdminServlet.doGet(AxisAdminServlet.java:43)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at 
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java
:664)
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at 
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.jasper.JasperException: 
/axis2-web/engagingtoaservice.jsp(9,0) Expecting "jsp:param" standard acti
on with "name" and "value" attributes
at 
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at 
org.apache.axis2.transport.http.AbstractAgent.renderView(AbstractAgent.java:116)
at 
org.apache.axis2.transport.http.AdminAgent.processEngageToService(AdminAgent.java:350)
... 23 more

-- 
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-1404) Admin console should "warn" the user that configuration changes are transient

Admin console should "warn" the user that configuration changes are transient
-

 Key: AXIS2-1404
 URL: http://issues.apache.org/jira/browse/AXIS2-1404
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: admin console
Affects Versions: 1.1
 Environment: Axis2 1.1 RC1
Reporter: Thilo Frotscher
Priority: Minor


The admin console should display a "warning" message on the welcome page that 
all configuration changes made using the console are transient and lost after a 
restart of the web container.

-- 
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-1403) Link "Disengage" doesn't work anymore

Link "Disengage" doesn't work anymore 
--

 Key: AXIS2-1403
 URL: http://issues.apache.org/jira/browse/AXIS2-1403
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: admin console
Affects Versions: 1.1
 Environment: Axis2 1.1 RC1
    Reporter: Thilo Frotscher
Priority: Critical



The "Disengage" links don't work anymore, whether for single operations, nor 
for complete services.
When I click on them to disengabe the addressing-1.09 module, I am forwarded to 
a blank page.
When going back manually to the admin console, nothing has changed: the 
service/operation is still engaged with the addressing module

-- 
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-1402) WSDL2Java: format generated files

[ 
http://issues.apache.org/jira/browse/AXIS2-1402?page=comments#action_12442539 ] 

Thilo Frotscher commented on AXIS2-1402:


One more thing:

- The folder "test" is always created, regardless of whether test classes are 
generated or not. This is a bit annoying sometimes.


> WSDL2Java: format generated files
> -
>
> Key: AXIS2-1402
> URL: http://issues.apache.org/jira/browse/AXIS2-1402
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>Affects Versions: 1.1
> Environment: Axis2 1.1 RC1
>Reporter: Thilo Frotscher
>Priority: Minor
>
> - the generated build.xml contains the tasks make.repo and start.server even 
> if there was only client code created...
> - it would be nice if the build.xml file was formatted (i.e. indented), the 
> same applies for all generated WSDLs, XMLs, XSDs...
> - build.xml depends on  environment variable AXIS2_HOME... is this documented 
> anywhere?
> - generated services.xml contains the following line
>
>   replacement of #axisVersion# and #today# with real values doesn't seem to 
> work...

-- 
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]

[Axis2] MTOM enabled by default since RC1

2006-10-16 Thread Thilo Frotscher



Hi,

Since 1.1 RC1 the web app comes with the parameter enableMTOM=true by default.
Did that happen intentionally or by accident? I wonder if it's really necessary
to set this parameter to true by default.

Thanks,
Thilo



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2-1402) WSDL2Java: format generated files

WSDL2Java: format generated files
-

 Key: AXIS2-1402
 URL: http://issues.apache.org/jira/browse/AXIS2-1402
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: Axis2 1.1 RC1
Reporter: Thilo Frotscher
Priority: Minor



- the generated build.xml contains the tasks make.repo and start.server even if 
there was only client code created...

- it would be nice if the build.xml file was formatted (i.e. indented), the 
same applies for all generated WSDLs, XMLs, XSDs...

- build.xml depends on  environment variable AXIS2_HOME... is this documented 
anywhere?

- generated services.xml contains the following line

   

  replacement of #axisVersion# and #today# with real values doesn't seem to 
work...

-- 
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-1401) Eclipse Code Generator Wizard: checkbox doesn't make sense / option missing

Eclipse Code Generator Wizard: checkbox doesn't make sense / option missing
---

 Key: AXIS2-1401
 URL: http://issues.apache.org/jira/browse/AXIS2-1401
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: Tools
 Environment: Axis2 1.1 RC1
Reporter: Thilo Frotscher


Three issues...

1) The checkbox "Generate Client Code" doesn't make any sense under "Generate 
server side code". Just recently the command-line options for WSDL2Java were 
changed in a very senseful way. Let's do the same for the Wizard, i.e. have one 
checkbox to turn on/off the client-side code generation and another checkbox to 
turn on/off server side code generation. If one of these checkboxes is 
selected, then activate the according configuration options (client: 
sync/async, server: service.xml/interface)

2) The wizard should allow the user to specify the destination folder for 
resources (WSDL2Java option -R)

3) There's a language/spelling mistake: "Add the Axis2 codegen jars to the 
codegen reulted 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] Created: (AXIS2-1400) Eclipse Code Generator Wizard displays wrong error message

Eclipse Code Generator Wizard displays wrong error message
--

 Key: AXIS2-1400
 URL: http://issues.apache.org/jira/browse/AXIS2-1400
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: Tools
Affects Versions: 1.1
 Environment: Axis 1.1 RC1
Reporter: Thilo Frotscher
Priority: Minor


If an invalid WSDL is selected on the first wizard page (i.e. the message 
elements reference elements using wrong namespaces) then the wizard displays 
the following error message on the second page:

specified WSDL is not found!

Actually, the error message should be something like

Specified WSDL is invalid.

-- 
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]

[Axis2] Axis2, Axis 2 or Axis 2.0?

2006-10-16 Thread Thilo Frotscher



Hello,

This might be a minor issue at this stage but I think the name of this project
should generally be clarified. At several different places (articles, code,
documentation, JIRA, Eclipse plugins etc) at least three different names can
be found:

- Axis2 (definitely the most frequent one, so I assume that's the right one)
- Axis 2
- Axis 2.0 (this rises questions concerning the release version 1.1 :-)

The project name should be consistent *everywhere*.

Thanks,
Thilo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2-1311) WSDL2Java removes fault information from WSDL file

[ 
http://issues.apache.org/jira/browse/AXIS2-1311?page=comments#action_12442501 ] 

Thilo Frotscher commented on AXIS2-1311:



Yes, it's fixed. Thanks.


> WSDL2Java removes fault information from WSDL file
> --
>
> Key: AXIS2-1311
> URL: http://issues.apache.org/jira/browse/AXIS2-1311
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of 02 Oct 2006
>Reporter: Thilo Frotscher
>Priority: Blocker
> Attachments: hotel.wsdl, hotel.xsd
>
>
> This bug relates to the resources files that are created by WSDL2Java.
> First of all, I wonder why WSDL2Java generates a completely new WSDL file at 
> all. If it's just for adding bindings, these could be inserted into a copied 
> source WSDL. I also don't understand why the filenames of WSDL and XSDs are 
> changed.
> The actual bug I'd like to report is as follows: 
> When generating code using WSDL2Java from a WSDL that contains 
> - fault messages
> -  elements as children of 
> -  elements as children of 
> all these elements related to faults are missing in the generated WSDL file 
> which can be found in the resources folder. This is a severe problem, because 
> it is this generated WSDL file that is delivered in case of requests to 
> htp://...?wsdl.
> The generated code works fine though, including the exceptions that are 
> raised etc.
>  

-- 
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-1291) WSDL2Java should not create ExtensionMapper in package axis2.apache.org

[ 
http://issues.apache.org/jira/browse/AXIS2-1291?page=comments#action_12442494 ] 

Thilo Frotscher commented on AXIS2-1291:



Uploaded WSDL and XSD. Problem still exists in Axis2 1.1 RC1.


> WSDL2Java should not create ExtensionMapper in package axis2.apache.org
> ---
>
> Key: AXIS2-1291
> URL: http://issues.apache.org/jira/browse/AXIS2-1291
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of  02 Oct 2006
>Reporter: Thilo Frotscher
> Attachments: hotel.wsdl, hotel.xsd
>
>
> WSDL2Java creates a class called ExtensionMapper which belongs to the package 
> axis2.apache.org. Can this please be changed so that it is created in the 
> same package as the classes for the types, aka in an application-specific 
> package? 
> Or, at the very least, change the package to org.apache.axis2 instead of 
> axis2.apache.org. However, I can't think of a reason why ExtensionMapper 
> should not belong to an application-specific package, because the class 
> actually is specific to the application for which it was created.
> Thanx!

-- 
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-1291) WSDL2Java should not create ExtensionMapper in package axis2.apache.org

 [ http://issues.apache.org/jira/browse/AXIS2-1291?page=all ]

Thilo Frotscher updated AXIS2-1291:
---

Attachment: hotel.xsd

> WSDL2Java should not create ExtensionMapper in package axis2.apache.org
> ---
>
> Key: AXIS2-1291
> URL: http://issues.apache.org/jira/browse/AXIS2-1291
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of  02 Oct 2006
>Reporter: Thilo Frotscher
> Attachments: hotel.wsdl, hotel.xsd
>
>
> WSDL2Java creates a class called ExtensionMapper which belongs to the package 
> axis2.apache.org. Can this please be changed so that it is created in the 
> same package as the classes for the types, aka in an application-specific 
> package? 
> Or, at the very least, change the package to org.apache.axis2 instead of 
> axis2.apache.org. However, I can't think of a reason why ExtensionMapper 
> should not belong to an application-specific package, because the class 
> actually is specific to the application for which it was created.
> Thanx!

-- 
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-1291) WSDL2Java should not create ExtensionMapper in package axis2.apache.org

 [ http://issues.apache.org/jira/browse/AXIS2-1291?page=all ]

Thilo Frotscher updated AXIS2-1291:
---

Attachment: hotel.wsdl

> WSDL2Java should not create ExtensionMapper in package axis2.apache.org
> ---
>
> Key: AXIS2-1291
> URL: http://issues.apache.org/jira/browse/AXIS2-1291
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of  02 Oct 2006
>Reporter: Thilo Frotscher
> Attachments: hotel.wsdl, hotel.xsd
>
>
> WSDL2Java creates a class called ExtensionMapper which belongs to the package 
> axis2.apache.org. Can this please be changed so that it is created in the 
> same package as the classes for the types, aka in an application-specific 
> package? 
> Or, at the very least, change the package to org.apache.axis2 instead of 
> axis2.apache.org. However, I can't think of a reason why ExtensionMapper 
> should not belong to an application-specific package, because the class 
> actually is specific to the application for which it was created.
> Thanx!

-- 
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]

Re: [Axis2] Axis2 1.1-RC1 Release

2006-10-15 Thread Thilo Frotscher

Hi!

Where's the Eclipse Service Archiver Wizard? It's not in the below mentioned
folder. Does that mean it won't be part of Axis2 1.1?

Cheers,
Thilo

Thilina Gunarathne wrote:

Hi all,

I uploaded the Axis2 1.1 RC1 release artifacts to the following
locations. Please help us by downloading and reviewing them.

Download locations :
* binary and source distributions -
http://people.apache.org/~thilina/axis2/1.1-RC1/

* jars
http://people.apache.org/~thilina/maven/org.apache.axis2/jars/

* mars (addressing and SOAP monitor)
http://people.apache.org/~thilina/maven/org.apache.axis2/mars/

* Tools
http://people.apache.org/~thilina/axis2/1.1-RC1/eclipse_codegen_plugin_1.1-RC1http://people.apache.org/~thilina/axis2/1.1-RC1/idea_codegen_plugin_1.1-RC1/

I uploaded a subset of Axis2 docs (preview versions) for the benefit
of the folks who are going to try out Axis2 1.1-RC1. Some links may
not work. Constructive feedback on the docs are welcome.

* Docs
http://people.apache.org/~thilina/axis2/docs/

According to the release plan, I'm expecting to release the Axis2 1.1
RC2 on 15th October, 2006.

Please note that these releases do not include xdocs but will be
available with 1.1 release as usual.

Thanks,
Thilina

PS: This release includes SNAPSHOT dependencies of several libraries,
which will be replaced with their released versions in the 1.1
release.
Axiom r453852
XmlSchema r453792
Neethi r453887

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend

2006-10-10 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-1334?page=comments#action_12441104 ] 

Thilo Frotscher commented on AXIS2-1334:


I investigated further... Sandesha2 1.0 works fine with Axis2 1.0 but not with 
Axis2 1.1 RC1. But I don't know whether this is an issue with Axis2 1.1 or 
whether there is just a new Sandesha2 release needed. In the latter case, it 
should be documented in the Sandesha2 user guide which Sandesha release works 
with which Axis2 release.
 

> Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend
> 
>
> Key: AXIS2-1334
> URL: http://issues.apache.org/jira/browse/AXIS2-1334
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1
> Environment: Axis2 1.1 RC1
> Sandesha2 1.0
>Reporter: Thilo Frotscher
>Priority: Blocker
>
> - deploy a fresh Axis2 1.1 RC1 into Tomcat
> - startup Tomcat
> - check out Axis2 Web Admin Frontend with browser - works fine!
> - shut down Tomcat
> - copy sandesha2-1.0.mar into WEB-INF/modules
> - add name of module archive to modules.list (not sure if this step is 
> needed, but bug occurs with or without this step!)
> - add RMPhase to all four flows, according to Sandesha2 user guide: 
> http://ws.apache.org/sandesha/sandesha2/userGuide.html
> - start up Tomcat
> - check out Axis2 Web Admin Frontend with browser - Exception!
> TOMCAT's LOG FILE
> =
> java.lang.NoSuchMethodError: 
> org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy;
>   at 
> org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158)
>   at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50)
>   at 
> org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217)
>   at 
> org.apache.axis2.context.ConfigurationContextFactory.init(ConfigurationContextFactory.java:193)
>   at 
> org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70)
>   at 
> org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:366)
>   at 
> org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304)
>   at 
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
>   at 
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
>   at 
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917)
>   at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4197)
>   at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
>   at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
>   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
>   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
>   at 
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698)
>   at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472)
>   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112)
>   at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
>   at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
>   at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
>   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
>   at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
>   at 
> org.apache.catalina.core.StandardService.start(StandardService.java:450)
>   at 
> org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
>   at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
>   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:585)
>   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
>   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
> BROWSER
> ===
> org.apache.jasper.JasperException
>

[jira] Created: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend

2006-10-10 Thread Thilo Frotscher (JIRA)

Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend


 Key: AXIS2-1334
 URL: http://issues.apache.org/jira/browse/AXIS2-1334
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: core
Affects Versions: 1.1
 Environment: Axis2 1.1 RC1
Sandesha2 1.0
Reporter: Thilo Frotscher
Priority: Blocker


- deploy a fresh Axis2 1.1 RC1 into Tomcat
- startup Tomcat
- check out Axis2 Web Admin Frontend with browser - works fine!
- shut down Tomcat
- copy sandesha2-1.0.mar into WEB-INF/modules
- add name of module archive to modules.list (not sure if this step is needed, 
but bug occurs with or without this step!)
- add RMPhase to all four flows, according to Sandesha2 user guide: 
http://ws.apache.org/sandesha/sandesha2/userGuide.html
- start up Tomcat
- check out Axis2 Web Admin Frontend with browser - Exception!



TOMCAT's LOG FILE
=
java.lang.NoSuchMethodError: 
org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy;
at 
org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158)
at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50)
at 
org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217)
at 
org.apache.axis2.context.ConfigurationContextFactory.init(ConfigurationContextFactory.java:193)
at 
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70)
at 
org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:366)
at 
org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4197)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
at 
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:450)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
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:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

BROWSER
===

org.apache.jasper.JasperException

org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

root cause

org.apache.jasper.JasperException

org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.jav

[jira] Commented: (AXIS2-1311) WSDL2Java removes fault information from WSDL file

2006-10-08 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-1311?page=comments#action_12440749 ] 

Thilo Frotscher commented on AXIS2-1311:


WSDL and XSD added. Thanks.


> WSDL2Java removes fault information from WSDL file
> --
>
> Key: AXIS2-1311
> URL: http://issues.apache.org/jira/browse/AXIS2-1311
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of 02 Oct 2006
>Reporter: Thilo Frotscher
>Priority: Blocker
> Attachments: hotel.wsdl, hotel.xsd
>
>
> This bug relates to the resources files that are created by WSDL2Java.
> First of all, I wonder why WSDL2Java generates a completely new WSDL file at 
> all. If it's just for adding bindings, these could be inserted into a copied 
> source WSDL. I also don't understand why the filenames of WSDL and XSDs are 
> changed.
> The actual bug I'd like to report is as follows: 
> When generating code using WSDL2Java from a WSDL that contains 
> - fault messages
> -  elements as children of 
> -  elements as children of 
> all these elements related to faults are missing in the generated WSDL file 
> which can be found in the resources folder. This is a severe problem, because 
> it is this generated WSDL file that is delivered in case of requests to 
> htp://...?wsdl.
> The generated code works fine though, including the exceptions that are 
> raised etc.
>  

-- 
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-1311) WSDL2Java removes fault information from WSDL file

2006-10-08 Thread Thilo Frotscher (JIRA)

 [ http://issues.apache.org/jira/browse/AXIS2-1311?page=all ]

Thilo Frotscher updated AXIS2-1311:
---

Attachment: hotel.xsd

> WSDL2Java removes fault information from WSDL file
> --
>
> Key: AXIS2-1311
> URL: http://issues.apache.org/jira/browse/AXIS2-1311
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of 02 Oct 2006
>Reporter: Thilo Frotscher
>Priority: Blocker
> Attachments: hotel.wsdl, hotel.xsd
>
>
> This bug relates to the resources files that are created by WSDL2Java.
> First of all, I wonder why WSDL2Java generates a completely new WSDL file at 
> all. If it's just for adding bindings, these could be inserted into a copied 
> source WSDL. I also don't understand why the filenames of WSDL and XSDs are 
> changed.
> The actual bug I'd like to report is as follows: 
> When generating code using WSDL2Java from a WSDL that contains 
> - fault messages
> -  elements as children of 
> -  elements as children of 
> all these elements related to faults are missing in the generated WSDL file 
> which can be found in the resources folder. This is a severe problem, because 
> it is this generated WSDL file that is delivered in case of requests to 
> htp://...?wsdl.
> The generated code works fine though, including the exceptions that are 
> raised etc.
>  

-- 
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-1311) WSDL2Java removes fault information from WSDL file

2006-10-08 Thread Thilo Frotscher (JIRA)

 [ http://issues.apache.org/jira/browse/AXIS2-1311?page=all ]

Thilo Frotscher updated AXIS2-1311:
---

Attachment: hotel.wsdl

> WSDL2Java removes fault information from WSDL file
> --
>
> Key: AXIS2-1311
> URL: http://issues.apache.org/jira/browse/AXIS2-1311
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of 02 Oct 2006
>Reporter: Thilo Frotscher
>Priority: Blocker
> Attachments: hotel.wsdl, hotel.xsd
>
>
> This bug relates to the resources files that are created by WSDL2Java.
> First of all, I wonder why WSDL2Java generates a completely new WSDL file at 
> all. If it's just for adding bindings, these could be inserted into a copied 
> source WSDL. I also don't understand why the filenames of WSDL and XSDs are 
> changed.
> The actual bug I'd like to report is as follows: 
> When generating code using WSDL2Java from a WSDL that contains 
> - fault messages
> -  elements as children of 
> -  elements as children of 
> all these elements related to faults are missing in the generated WSDL file 
> which can be found in the resources folder. This is a severe problem, because 
> it is this generated WSDL file that is delivered in case of requests to 
> htp://...?wsdl.
> The generated code works fine though, including the exceptions that are 
> raised etc.
>  

-- 
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-1311) WSDL2Java removes fault information from WSDL file

2006-10-05 Thread Thilo Frotscher (JIRA)

WSDL2Java removes fault information from WSDL file
--

 Key: AXIS2-1311
 URL: http://issues.apache.org/jira/browse/AXIS2-1311
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: core
Affects Versions: 1.1
 Environment: Axis2 1.1 Snapshot of 02 Oct 2006
Reporter: Thilo Frotscher
Priority: Blocker


This bug relates to the resources files that are created by WSDL2Java.

First of all, I wonder why WSDL2Java generates a completely new WSDL file at 
all. If it's just for adding bindings, these could be inserted into a copied 
source WSDL. I also don't understand why the filenames of WSDL and XSDs are 
changed.

The actual bug I'd like to report is as follows: 
When generating code using WSDL2Java from a WSDL that contains 

- fault messages
-  elements as children of 
-  elements as children of 

all these elements related to faults are missing in the generated WSDL file 
which can be found in the resources folder. This is a severe problem, because 
it is this generated WSDL file that is delivered in case of requests to 
htp://...?wsdl.

The generated code works fine though, including the exceptions that are raised 
etc.
 

-- 
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-1291) WSDL2Java should not create ExtensionMapper in package axis2.apache.org

2006-10-03 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-1291?page=comments#action_12439445 ] 

Thilo Frotscher commented on AXIS2-1291:


Sorry, this issue is obviously *not* a major one. Please reduce the priority 
accordingly.


> WSDL2Java should not create ExtensionMapper in package axis2.apache.org
> ---
>
> Key: AXIS2-1291
> URL: http://issues.apache.org/jira/browse/AXIS2-1291
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.1
> Environment: Axis2 1.1 Snapshot of  02 Oct 2006
>Reporter: Thilo Frotscher
>
> WSDL2Java creates a class called ExtensionMapper which belongs to the package 
> axis2.apache.org. Can this please be changed so that it is created in the 
> same package as the classes for the types, aka in an application-specific 
> package? 
> Or, at the very least, change the package to org.apache.axis2 instead of 
> axis2.apache.org. However, I can't think of a reason why ExtensionMapper 
> should not belong to an application-specific package, because the class 
> actually is specific to the application for which it was created.
> Thanx!

-- 
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-1291) WSDL2Java should not create ExtensionMapper in package axis2.apache.org

2006-10-03 Thread Thilo Frotscher (JIRA)

WSDL2Java should not create ExtensionMapper in package axis2.apache.org
---

 Key: AXIS2-1291
 URL: http://issues.apache.org/jira/browse/AXIS2-1291
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: Tools
Affects Versions: 1.1
 Environment: Axis2 1.1 Snapshot of  02 Oct 2006
Reporter: Thilo Frotscher


WSDL2Java creates a class called ExtensionMapper which belongs to the package 
axis2.apache.org. Can this please be changed so that it is created in the same 
package as the classes for the types, aka in an application-specific package? 

Or, at the very least, change the package to org.apache.axis2 instead of 
axis2.apache.org. However, I can't think of a reason why ExtensionMapper should 
not belong to an application-specific package, because the class actually is 
specific to the application for which it was created.

Thanx!


-- 
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-663) WSDL2Java: allow user to specify separate destination folders for src and resources

2006-09-28 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-663?page=comments#action_12438412 ] 

Thilo Frotscher commented on AXIS2-663:
---

Looks great! Just one thing: can you please add the new command line options to 
the usage information of WSDL2Java, i.e. what appears on the screen when 
executing "wsdl2java -?"


> WSDL2Java: allow user to specify separate destination folders for src and 
> resources
> ---
>
> Key: AXIS2-663
> URL: http://issues.apache.org/jira/browse/AXIS2-663
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.0
> Environment: Axis2 1.0 RC5
>Reporter: Thilo Frotscher
> Assigned To: Ajith Harshana Ranabahu
>Priority: Blocker
>
> WSDL2Java generates source code, resources (service.xml, wsdl, xsd) and a 
> build.xml file.
> The user can specify a destination folder for all of these files, but they 
> all go into the same folder.
> When generating code for more than one service, you'll generally want to have 
> the source code for all services in the same src-folder.
> That's why you would specify the same destination folder for all services. 
> However, in this causes the problem that the build.xml files 
> and the resources for all the services go into the same folder as well and 
> interfere with each other, or a overwritten respectively.
> Therefore, it would be great if the user could specify two separate 
> destination folders: one for the source code and the second one for 
> the build file and the resources. Of course, the build files would have to 
> reflect the new folder structure.
> Alternative suggestion: WSDL2Java could do this automatically by introducing 
> a service-specific folder
> under resouces:
> /resources/MyService1/service.xml
> /resources/MyService1/MyService.wsdl
> /resources/MyService1/MyService.xsd
> /resources/MyService2/service.xml
> /resources/MyService2/MyService.wsdl
> /resources/MyService2/MyService.xsd
> For the build files a similar solution could be used.

-- 
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-663) WSDL2Java: allow user to specify separate destination folders for src and resources

2006-09-20 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-663?page=comments#action_12436247 ] 

Thilo Frotscher commented on AXIS2-663:
---

Eran,

this JIRA was not set to "Blocker" by me :-) I believe it was Dims after I sent 
an email a few weeks ago asking to fix this for 1.1
You're right, I wouldn't call it a blocker either. But I think all JIRAs that 
were supposed to be fixed for 1.1 were set to "Blocker" by Dims.

Anyway,  the current behaviour is quite annoying because it requires a lot of 
manual folder movement and renaming in an application project. Thus it would be 
great to have it fixed in the new release and I think it can probably be 
implemented rather quickly. The same applies to one or two other JIRAs. I 
understand that you're in the process of creating a new release. But I also 
believe that it's always better to release software a few days later than 
announced, but with all important issues fixed, instead of releasing on time 
and the software contains annoying issues. After all, it's your decision of 
course :-)

I'd be happy to contribute but I am very busy at the moment. Until when would 
you need the fix to make sure it goes into 1.1?




> WSDL2Java: allow user to specify separate destination folders for src and 
> resources
> ---
>
> Key: AXIS2-663
> URL: http://issues.apache.org/jira/browse/AXIS2-663
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.0
> Environment: Axis2 1.0 RC5
>Reporter: Thilo Frotscher
> Assigned To: Ajith Harshana Ranabahu
>Priority: Blocker
>
> WSDL2Java generates source code, resources (service.xml, wsdl, xsd) and a 
> build.xml file.
> The user can specify a destination folder for all of these files, but they 
> all go into the same folder.
> When generating code for more than one service, you'll generally want to have 
> the source code for all services in the same src-folder.
> That's why you would specify the same destination folder for all services. 
> However, in this causes the problem that the build.xml files 
> and the resources for all the services go into the same folder as well and 
> interfere with each other, or a overwritten respectively.
> Therefore, it would be great if the user could specify two separate 
> destination folders: one for the source code and the second one for 
> the build file and the resources. Of course, the build files would have to 
> reflect the new folder structure.
> Alternative suggestion: WSDL2Java could do this automatically by introducing 
> a service-specific folder
> under resouces:
> /resources/MyService1/service.xml
> /resources/MyService1/MyService.wsdl
> /resources/MyService1/MyService.xsd
> /resources/MyService2/service.xml
> /resources/MyService2/MyService.wsdl
> /resources/MyService2/MyService.xsd
> For the build files a similar solution could be used.

-- 
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-663) WSDL2Java: allow user to specify separate destination folders for src and resources

2006-09-19 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-663?page=comments#action_12435753 ] 

Thilo Frotscher commented on AXIS2-663:
---

Eran, no the -o option is not enough. We really need a way to specify to 
different destinations:

1) a destination folder for the source code
2) a destination folder the resources and the build script

Otherwise, the resources and build scripts of multiple services get in each 
others way if you need to generate code for multiple WSDLs in the same project.
When implementing this, please make sure the generated build scripts "know" the 
destination of the source code, as it won't necessarily be in the same folder 
anymore!

Thanks!


> WSDL2Java: allow user to specify separate destination folders for src and 
> resources
> ---
>
> Key: AXIS2-663
> URL: http://issues.apache.org/jira/browse/AXIS2-663
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.0
> Environment: Axis2 1.0 RC5
>Reporter: Thilo Frotscher
> Assigned To: Ajith Harshana Ranabahu
>Priority: Blocker
>
> WSDL2Java generates source code, resources (service.xml, wsdl, xsd) and a 
> build.xml file.
> The user can specify a destination folder for all of these files, but they 
> all go into the same folder.
> When generating code for more than one service, you'll generally want to have 
> the source code for all services in the same src-folder.
> That's why you would specify the same destination folder for all services. 
> However, in this causes the problem that the build.xml files 
> and the resources for all the services go into the same folder as well and 
> interfere with each other, or a overwritten respectively.
> Therefore, it would be great if the user could specify two separate 
> destination folders: one for the source code and the second one for 
> the build file and the resources. Of course, the build files would have to 
> reflect the new folder structure.
> Alternative suggestion: WSDL2Java could do this automatically by introducing 
> a service-specific folder
> under resouces:
> /resources/MyService1/service.xml
> /resources/MyService1/MyService.wsdl
> /resources/MyService1/MyService.xsd
> /resources/MyService2/service.xml
> /resources/MyService2/MyService.wsdl
> /resources/MyService2/MyService.xsd
> For the build files a similar solution could be used.

-- 
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-917) User guide should give explanation and examples of fault handling

2006-09-19 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-917?page=comments#action_12435751 ] 

Thilo Frotscher commented on AXIS2-917:
---


I agree with William and Derek that it is absolutely essential for the Axis2 
framework to clarify how error handling works. I am sure users don't mind if 
Axis2 1.1 will be released one or two weeks later, as long as important issues 
are resolved in this release. 
By the way: interoperability of fault messages with other frameworks (like .NET 
for example) introduces another bunch of issues. But this is something for 
Axis2 1.5 :-)
 

> User guide should give explanation and examples of fault handling
> -
>
> Key: AXIS2-917
> URL: http://issues.apache.org/jira/browse/AXIS2-917
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Wish
>  Components: samples, build,site  & docs
>Affects Versions: 1.0
>Reporter: Derek Foster
> Assigned To: Eran Chinthaka
>Priority: Blocker
> Attachments: sampleService-wsdl.rar
>
>
> The Axis2 user guide provides no examples of:
>   1) The WSDL to declare that a fault may be thrown from an operation 
> (suitable for passing into WSDL2Java)
>   2) The server-side code for a fault exception, as generated by WSDL2Java 
> and modified as a user might be expected to modify it.
>   3) The server-side code to throw the fault exception, including a tested 
> example of passing on a custom error message to be transmitted as part of a 
> SOAP fault (in the faultDetail) and received by the client.
>   4) The client-side code for receiving and handling a fault.
> Furthermore, what discussion of faults that there is seems fairly 
> contradictory. For instance, there are various suggestions that throwing an 
> AxisFault exception from a service is the way to issue a fault. However, 
> WSDL2Java does not generate service methods that are declared to throw 
> AxisFault, and there seems to be no way to declare such a fault in WSDL. (at 
> least, none that I can find). Fault generation from a service that was not 
> generated by WSDL2Java should be treated as a separate section, since it is 
> handled in a totally different manner by server code. I think that both kinds 
> of fault handling need to be documented clearly in the user guide.
> I have been trying for weeks to figure out how this is supposed to work, and 
> still haven't gotten it to work quite right (my custom error message included 
> in the thrown fault exception is getting lost somewhere before the SOAP fault 
> is transmitted). This is a basic feature that should be documented clearly.

-- 
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-1120) Phases concept is too confusing - please change for v1.1

2006-09-10 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-1120?page=comments#action_12433689 ] 

Thilo Frotscher commented on AXIS2-1120:



I think I have to clarify my request for improvement. By no means I wanted to 
suggest to completely remove the concept of phases. I think it's generally a 
great idea. It's just one single behaviour of modules and phases that I think 
is too confusing. That is, as described before: engaging a module with a single 
service can result in engaging the module with all services...without any 
warning.

What do you think about the following suggestions? They should be easy to 
implement:

1) if a module is engaged with a single service or operation, and the module 
contains handlers that belong to a global phase, then Axis2 reports a warning
- in the log file of the servlet container
- in the web administration frontend (if the engagement was done using the 
frontend)
   This warning says: "You engaged module FOO with service/operation BAR, but 
because the module contains global handlers, these will be invoked for ALL 
messages, no only for messages to service/operation BAR"

2) Deepal wrote that developers of handlers should check in the MessageContext 
whether the handler was engaged to the incoming message or not. Well, if this 
information is stored in the MessageContext, why invoke the handler at all? 
Wouldn't it be better if AxisEngine could do this check and invoke only those 
handlers that were engaged? This is basically the same like my second 
suggestion in my initial posting.

I clearly prefer option 2) and still think that this small change is absolutely 
necessary. It would make the phases concept perfect. Without a change, it's 
just too complicated to figure out which services a module is engaged with. I 
am happy to discuss this further and to tell you about feedback from 
participant's of my Axis2 training courses about this issue. 


> Phases concept is too confusing - please change for v1.1
> 
>
> Key: AXIS2-1120
> URL: http://issues.apache.org/jira/browse/AXIS2-1120
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Improvement
>  Components: core
>    Affects Versions: 1.0
>Reporter: Thilo Frotscher
>Priority: Blocker
>
> With Axis2 1.0 it can easily happen that you engage a module with services 
> without realizing it! 
> This is because even if explicitly engaging a module with a *single* service 
> or a *single* operation, its handlers will automatically be invoked for *all* 
> services if they belong to a global phase. There's no warning messages or 
> anything that prevent's you from doing this. IMHO this bevaviour is very 
> confusing, especially for beginners.
> I think there are two possible solutions to this:
> - disallow engagement with single services or operations for all modules that 
> contain handlers in global phases
>   (at the very least, display a warning message that the module will actually 
> be invoked for *all* services)
> - or make sure that handlers in global phases are *available*  to all 
> services, but will only be invoked for services that they were *explicitly* 
> engaged with
> Either way, the release of Axis2 1.1 is a very good opportunity to change 
> this behaviour. The later you do this, the more backwards compatibility might 
> have to be sacrificed.
> I am sure that many users will vote for this change once the use of Axis2 in 
> general and modules in particular is more widespread.
> There was a discussion about this on the mailing list, but somehow it died 
> out: http://marc.theaimsgroup.com/?l=axis-dev&m=115394666310204&w=2
> Please consider making this change for v1.1
> Thanks!

-- 
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-1120) Phases concept is too confusing - please change for v1.1

2006-09-07 Thread Thilo Frotscher (JIRA)

Phases concept is too confusing - please change for v1.1


 Key: AXIS2-1120
 URL: http://issues.apache.org/jira/browse/AXIS2-1120
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: core
Affects Versions: 1.0
Reporter: Thilo Frotscher
Priority: Blocker



With Axis2 1.0 it can easily happen that you engage a module with services 
without realizing it! 

This is because even if explicitly engaging a module with a *single* service or 
a *single* operation, its handlers will automatically be invoked for *all* 
services if they belong to a global phase. There's no warning messages or 
anything that prevent's you from doing this. IMHO this bevaviour is very 
confusing, especially for beginners.

I think there are two possible solutions to this:
- disallow engagement with single services or operations for all modules that 
contain handlers in global phases
  (at the very least, display a warning message that the module will actually 
be invoked for *all* services)

- or make sure that handlers in global phases are *available*  to all services, 
but will only be invoked for services that they were *explicitly* engaged with

Either way, the release of Axis2 1.1 is a very good opportunity to change this 
behaviour. The later you do this, the more backwards compatibility might have 
to be sacrificed.
I am sure that many users will vote for this change once the use of Axis2 in 
general and modules in particular is more widespread.

There was a discussion about this on the mailing list, but somehow it died out: 
http://marc.theaimsgroup.com/?l=axis-dev&m=115394666310204&w=2

Please consider making this change for v1.1
Thanks!


-- 
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]

Re: [Axis2] Blockers for Axis2 1.1

2006-08-22 Thread Thilo Frotscher



Hello Dims!

Could you please consider fixing

Axis2-961
Axis2-663

for the 1.1 release? I'd also like to vote for

Axis2-968

Thank you very much!!
Thilo





Davanum Srinivas wrote:

Team,

As promised, i've marked a few issues as blockers for 1.1 release,
Please review the list and add your comments in the specific bug if
you want me to remove the blocker on some bugs or if you want me to
add new ones (or you can do that yourself).

http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311157 



Let's take the next few days to nail down the list of issues that we
think we should fix. That will help us determine the schedule for the
release.

Thanks,
dims

 >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2-979) Rampart: wrong error message

2006-08-06 Thread Thilo Frotscher (JIRA)

Rampart: wrong error message


 Key: AXIS2-979
 URL: http://issues.apache.org/jira/browse/AXIS2-979
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
Reporter: Thilo Frotscher
Priority: Minor



I just had the following exception:

Exception in thread "main" org.apache.axis2.AxisFault: WSDoAllReceiver: Request 
does not contain required Security header

If Rampart is used on the client side, then WSDoAllReceiver processes 
responses, not requests - at least in case of a typical request/response MEP.
So the error message is misleading. It should be more general to be correct on 
the client side and the server side. It should be changed to:

Incoming message does not contain required Security header.

Thanks.


-- 
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]

Re: [jira] Updated: (AXIS2-963) Problems with complex xml schemas in wsdl2java

2006-08-04 Thread Thilo Frotscher



Ups, sorry. My fault. I thought the schema location would be
a broken link. But you're right, it is not. The WSDL seems
to be ok and complies to the WS-I Basic Profile. So I'd
say there's a problem in the code generator.

Gruesse nach Deutschland :-)



Carsten Ziegeler wrote:

Thilo Frotscher schrieb:

Carsten,

The schema location URL in your WSDL does not point to a document.
Perhaps that's already the problem: the code generator just can't
load the schema.


Hi Thilo,

the schema location points to
"http://schemas.xmlsoap.org/ws/2005/02/trust/ws-trust.xsd"; which is a
valid schema. Or do you mean something different?

Thanks
Carsten



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2-968) If a module's init() method throws an AxisFault, the initialization of the complete Axis2 web app fails

2006-08-03 Thread Thilo Frotscher (JIRA)

If a module's init() method throws an AxisFault, the initialization of the 
complete Axis2 web app fails 


 Key: AXIS2-968
 URL: http://issues.apache.org/jira/browse/AXIS2-968
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: core
Affects Versions: 1.0
Reporter: Thilo Frotscher
Priority: Critical


The interface module defines that method init() can throw an AxisFault. This is 
important, so that a module can report any problems in its initialization.
However, if a module throws this exception, the complete Axis2 web application 
fails to initialize and thus, the start page cannot be displayed in a browser.


-- 
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]

Re: [jira] Updated: (AXIS2-963) Problems with complex xml schemas in wsdl2java

2006-08-03 Thread Thilo Frotscher



Carsten,

The schema location URL in your WSDL does not point to a document.
Perhaps that's already the problem: the code generator just can't
load the schema.

Also, try checking the WSDL for compliance with Basic Profile
using WS-I's analyzer tool.

Cheers,
Thilo



Carsten Ziegeler (JIRA) wrote:

 [ http://issues.apache.org/jira/browse/AXIS2-963?page=all ]

Carsten Ziegeler updated AXIS2-963:
---

Attachment: authentication.wsdl


Problems with complex xml schemas in wsdl2java
--

Key: AXIS2-963
URL: http://issues.apache.org/jira/browse/AXIS2-963
Project: Apache Axis 2.0 (Axis2)
 Issue Type: Bug
 Components: wsdl
   Reporter: Carsten Ziegeler
Attachments: authentication.wsdl


When trying to generate a service code using wsdl2java (latest svn), I get different 
errors depending on the databinding used. With "-d none" I get:
xception in thread "main"
org.apache.axis2.wsdl.codegen.CodeGenerationException
: org.apache.axis2.wsdl.codegen.CodeGenerationException:
org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to 
the name
RequestSecurityToken with namespace http://schemas.xmlsoap.org/ws/2005/02/trust 
  at
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:235)
at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException:
org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to 
the name RequestSecurityToken with namespace 
http://schemas.xmlsoap.org/ws/2005/02/trust at
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.emitSkeleton(AxisServiceBasedMultiLanguageEmitter.java:796)
at
With "-d adb" I get this exception:
Caused by: org.apache.axis2.schema.SchemaCompilationException:
Unsupported content Simple Content Extension !  at
org.apache.axis2.schema.SchemaCompiler.processSimpleContent(SchemaCom
piler.java:979)
With "-d xmlbeans" I get the following exception:
...
Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
http://schemas.xmlsoap.org/ws/2004/08/addressing/:4:1571: error:
cvc-enumeration-valid:
 string value 'none' is not a valid enumeration value for type of
processContents attribute in xs:wildcard
at
org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGe
nerationUtility.java:235)
... 8 more




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2-961) Tidy up phase configuration in axis2.xml

2006-08-01 Thread Thilo Frotscher (JIRA)

Tidy up phase configuration in axis2.xml


 Key: AXIS2-961
 URL: http://issues.apache.org/jira/browse/AXIS2-961
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: core
Affects Versions: 1.0
Reporter: Thilo Frotscher



The current state of the phase configuration in axis2.xml is confusing, 
especially for beginners.

1) In In-Flow the handler InstanceDispatch is configured to belong to phase 
PostDispatch. This phase does not exist in the current configuration.





2) In In-Flow the handlers RequestURIBasedDispatcher and 
SOAPActionBasedDispatcher belong to Transport phase, while in In-Fault-Flow 
they belong to phase Dispatch. This should be consistent.

3) The usage of capital letters in phase names should be consistent. Currently 
it's inflow, outflow, INfaultflow and Outfaultflow.

4) The comments that are supposed to mark which phases are pre-defined and 
where developers can insert custom phases are confusing and misleading. They 
also refer to phases that don't exist.
 I suggest inserting comments like this:
 


 
 

 

or like this., respectively:
 

 
 


 

Thank you very much,
Thilo

-- 
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-945) Property clientData in generated CallbackHandler is unaccessible

Property clientData in generated CallbackHandler is unaccessible


 Key: AXIS2-945
 URL: http://issues.apache.org/jira/browse/AXIS2-945
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: client-api
Affects Versions: 1.0
Reporter: Thilo Frotscher


WSDL2Java generates an abstract callback handler class. You can pass its 
constructor a parameter for clientData.
When implementing your own callback handler that extends the generated abstract 
class, it can't access clientData because the property is private in the 
generated class and there's no getter-method.


-- 
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]

Re: [Axis2] Phases concept is confusing - bug or feature? Please discuss!

2006-07-30 Thread Thilo Frotscher



Hello,


However, when sending messages to this service, Axis2 1.0 will behave
differently. A handler that belongs to a global phase will be invoked for
*all* services and *all* operations after it was engaged with a *single*
service or *single* operation only. This is very confusing!


agreed , but that is the behavior   :-) .


If we agree that this behavior very confusing, then it should
really be changed. How are beginners supposed to understand this
concept? As the current version is still 1.0 and probably only few
people are using modules and phases in production today, there's
still a chance to make changes like this without sacrificing too
much backwards compatibility.



The problem is until you find the service and operation (until dispatch
happen) you dont know the operation specific chains. 


This only applies to incoming messages on the server side. The problem
I described applies to all flows.



So when you engage
a module to a service , then if add a handler to global phases as you
said it will run irrespective of the service. Since anyone can add
handler to global phases and no one keep track of that , at the run time
Axis2 can not figure out who add this handler into here.


My suggestion is as follows:

- it should not be allowed to engage a module with a service or operation
  if the module contains handlers that go to any of the global phases
  *before* dispatch phase. If somebody tries to do this, Axis2 should report an
  error. Modules with handlers in Transport/Security/PreDispatch phase
  can be engaged only globally, i.e. with all services and all operations,
  because this is what actually happens.
- only if all handlers of a module go to operation-specific phases or
  to global phases after dispatch, it should be allowed to engage them
  with a particular service or operation.



- handler method "cleanup" is never called


one more JIRA


I created a JIRA 2 months ago (AXIS2-653). It's unassigned so far.



I also think we need to take this into consideration , so +1 for the idea.
we need to call handler.onFault(); for all the prior handlers.


I created a new JIRA (AXIS2-942).



- it would be great if modules could be disengaged using the admin
frontend


pls create a JIRA so that we wont forget that.


Created AXIS2-943.



- Why is there a "Security" phase in th In Flow, but not in the Out Flow?
  Rampart puts its SecurityOutHandler into the "MessageOut" phase...
  Wouldn't it be easier to understand if there was a Security phase in
  the Out Flow as well?


Ruchith what do you think  ? I am +1 of doing this change.


Created AXIS2-944.

Cheers,
Thilo



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2-944) Add security phase to out flow(s)

Add security phase to out flow(s)
-

 Key: AXIS2-944
 URL: http://issues.apache.org/jira/browse/AXIS2-944
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: core
Affects Versions: 1.0
Reporter: Thilo Frotscher


There is a "Security" phase in th In Flow, but not in the Out Flow. Rampart 
puts its SecurityOutHandler into the "MessageOut" phase...
Wouldn't it be easier to understand if there was a Security phase in the Out 
Flow as well?

-- 
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-943) Add support for disengagement of modules to administration web frontend

Add support for disengagement of modules to administration web frontend
---

 Key: AXIS2-943
 URL: http://issues.apache.org/jira/browse/AXIS2-943
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: New Feature
  Components: core
Affects Versions: 1.0
Reporter: Thilo Frotscher


It would be great if modules could be disengaged using the admin frontend!


-- 
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-942) If handler throws an exception, inform all prior handlers in same flow

If handler throws an exception, inform all prior handlers in same flow
--

 Key: AXIS2-942
 URL: http://issues.apache.org/jira/browse/AXIS2-942
 Project: Apache Axis 2.0 (Axis2)
  Issue Type: Improvement
  Components: core
Affects Versions: 1.0
Reporter: Thilo Frotscher


If a handler throws an exception in the In-Flow, the flow is cancelled 
immediately. AxisEngine carries on with an operation-specific OutFaultFlow (if 
there already is an operation context) and then with the global out fault flow. 
Instead of just cancelling the in-flow, there should be a mechanism that 
informs prior handlers of the in-flow about the occurrence of the exception, so 
that they have a chance to undo their functionality. Axis 1.x had something 
like this (onFault method).

-- 
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]

[Axis2] Phases concept is confusing - bug or feature? Please discuss!

2006-07-26 Thread Thilo Frotscher



Hello Axis2 team!

I am trying to completely understand Axis2 phases, but while the concept
seems simple at first glance, I find it actually quite confusing the way
it is currently implemented.

There are two types of phases:
- global/system/pre-defined phases
- operation-specific phases

My understanding of the whole concept is that phases are used to define
*where* or *at which position* in the chain a particular handler will be
placed. Using the engagement mechanism you can define *if* or in which
cases a module/handler will be invoked (for all services, a service group,
a service or an operation).

The confusion starts if a handler is placed into one of the global phases,
let's say into PreDispatch. According to the theory above, we now know
*where* in the chain the handler would be invoked. We also know, that the
handler would *generally* be available to all services, because it
was not placed into an operation-specific phase.

Now, let's say you don't want to engage the module/handler globally.
Instead, you engage it with one particular service or even with one
particular operation. This can be done either by configuration file or
using the admin frontend. My expectation is then, that the handler will be
invoked *only* if a message is addressed to the service or operation I
engaged the module/handler with. This expectation is even confirmed when
I click on "Available Services" in the admin frontend, where services,
operations and their engaged modules are displayed. The engagement is
displayed *only* for the service or operation I picked.

However, when sending messages to this service, Axis2 1.0 will behave
differently. A handler that belongs to a global phase will be invoked for
*all* services and *all* operations after it was engaged with a *single*
service or *single* operation only. This is very confusing!

The problem is obvious with Rampart, however it works around this. It places
its handlers into global phases, so that they are always invoked, whether
security is needed or not. Whether it has any effect or not depends on the
configuration of a service or operation. Only if these configurations contain
any parameters for Rampart, then Rampart will do something. Otherwise it will
not. Hmmm... wouldn't the whole thing be easier to understand if Rampart could
be switched on/off for the single services or operations by engagement?

Perhaps I just misunderstand the concept. If that's the case please give some
advice. But if I am right, then please review this part of the phase concept.
IMHO it is very confusing that engaging a handler with *one* operation can mean
that the handler will be invoked for *all* services and *all* operations.


Apart from the above I found some minor issues:

- handler method "cleanup" is never called

- if a handler throws an exception in the In-Flow, the flow is cancelled
  immediately. AxisEngine carries on with an operation-specific OutFaultFlow
  (if there already is an operation context) and then with the global
  out fault flow. I think instead of just cancelling the in-flow, there
  should be a mechanism that informs prior handlers of the in-flow about the
  occurrence of the exception, so that they have a chance to undo their
  functionality. Axis 1.x had something like this (onFault method).

- it would be great if modules could be disengaged using the admin frontend

- on the client side, OutInAxisOperationClient (method "send") does *not*
  invoke receiveFault on the AxisEngine (and thereby InFaultFlow) if a
  service responses with a SOAP fault. Instead, it aways invokes receive
  (i.e. InFlow). I believe that this is a bug.

- Why is there a "Security" phase in th In Flow, but not in the Out Flow?
  Rampart puts its SecurityOutHandler into the "MessageOut" phase...
  Wouldn't it be easier to understand if there was a Security phase in the
  Out Flow as well?

Thank you very much for any help and advice.

Kind Regards,
Thilo



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2-653) Handler method "cleanup" is never called

2006-07-23 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-653?page=comments#action_12422878 ] 

Thilo Frotscher commented on AXIS2-653:
---

Can you please make sure that the cleanup-Method is called when a Handler is 
destroyed? Many thanks!


> Handler method "cleanup" is never called
> 
>
> Key: AXIS2-653
> URL: http://issues.apache.org/jira/browse/AXIS2-653
> Project: Apache Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0
>Reporter: Thilo Frotscher
>
> 1) My IDE couldn't find any references to method "cleanup" in the Axis2 
> source code. It's never called...
> 2) What happens if the handler's invoke method thows a fault? Javadoc for 
> "invoke" says that "onFault" would be called. But there is no such method...
> 3) User guide, page 4 
> - mentions a method called "revoke". There is no such method in interface 
> Handler. 
> - refers to green lines in sample configuration...there are no green lines
> - sample configuration contains mistakes
>  

-- 
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-692) Service Archiver Wizard: Several bugs

 [ http://issues.apache.org/jira/browse/AXIS2-692?page=all ]

Thilo Frotscher updated AXIS2-692:
--

Attachment: screenshot.jpg

> Service Archiver Wizard: Several bugs
> -
>
>  Key: AXIS2-692
>  URL: http://issues.apache.org/jira/browse/AXIS2-692
>  Project: Apache Axis 2.0 (Axis2)
> Type: Bug

> Versions: 1.0
>  Environment: Axis2 1.0 final, Eclipse 3.1.2
> Reporter: Thilo Frotscher
>  Attachments: screenshot.jpg
>
> Opening the wizard using the "Select a wizard" dialog in Eclipse
> - after selecting "Axis2 Service Archiver" from the list, the wizard does not 
> start when clicking "Next". It only starts by double-clicking on the wizard's 
> name
> - this is a minor bug of course
> Using the Wizard
> - after selecting "Generate the service xml automatically" it happens 
> sometimes (but not always) that the "Next" button doesn't have any effect. 
> Clicking the "Finish" button results in a dialog box with the title "Error" 
> but no message. I am writing "sometimes" because the behaviour seems to be 
> dependent on the values the user entered on other pages of the wizard during 
> prior use.
> - the last page of the wizard is titled "set the output location and the 
> output file name", but actually a service name and a class name have to be 
> specified. The output location for the service archive can't be selected (but 
> would be nice to have).
> - on the same wizard page, the button "Load" always results in an error being 
> displayed. Clicking "Finish" results in the error message shown in the 
> screenshot (the folder "Service-copy" doesn't exist and couldn't be created 
> on my machine anyway, because my user account doesn't have write permissions 
> for the installation folder of Eclipse).
> - Generally, storing the values a user typed into the text fields seems to be 
> an issue when jumping backward and forward in the wizard using the 
> corresponding buttons or when using the wizard multiple times in a row.

-- 
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] Created: (AXIS2-692) Service Archiver Wizard: Several bugs

Service Archiver Wizard: Several bugs
-

 Key: AXIS2-692
 URL: http://issues.apache.org/jira/browse/AXIS2-692
 Project: Apache Axis 2.0 (Axis2)
Type: Bug

Versions: 1.0
 Environment: Axis2 1.0 final, Eclipse 3.1.2
Reporter: Thilo Frotscher
 Attachments: screenshot.jpg

Opening the wizard using the "Select a wizard" dialog in Eclipse
- after selecting "Axis2 Service Archiver" from the list, the wizard does not 
start when clicking "Next". It only starts by double-clicking on the wizard's 
name
- this is a minor bug of course

Using the Wizard
- after selecting "Generate the service xml automatically" it happens sometimes 
(but not always) that the "Next" button doesn't have any effect. Clicking the 
"Finish" button results in a dialog box with the title "Error" but no message. 
I am writing "sometimes" because the behaviour seems to be dependent on the 
values the user entered on other pages of the wizard during prior use.

- the last page of the wizard is titled "set the output location and the output 
file name", but actually a service name and a class name have to be specified. 
The output location for the service archive can't be selected (but would be 
nice to have).

- on the same wizard page, the button "Load" always results in an error being 
displayed. Clicking "Finish" results in the error message shown in the 
screenshot (the folder "Service-copy" doesn't exist and couldn't be created on 
my machine anyway, because my user account doesn't have write permissions for 
the installation folder of Eclipse).

- Generally, storing the values a user typed into the text fields seems to be 
an issue when jumping backward and forward in the wizard using the 
corresponding buttons or when using the wizard multiple times in a row.


-- 
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] Created: (AXIS2-691) Code Generator Wizard: namespace-package mapping is not editable

Code Generator Wizard: namespace-package mapping is not editable


 Key: AXIS2-691
 URL: http://issues.apache.org/jira/browse/AXIS2-691
 Project: Apache Axis 2.0 (Axis2)
Type: Bug

  Components: Tools  
Versions: 1.0
 Environment: Axis2 1.0 final, Eclipse 3.1.2
Reporter: Thilo Frotscher


After selecting "Generate Java from WSDL" and the corresponding WSDL file, the 
table with the namespace-package mappings is not editable.
Besides, the selection box for databindings contains only ADB and XML Beans. 
The other supported databinding are missing.
 

-- 
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: (AXIS2-661) WSDL2Java generates wrong build.xml when jaxme option is used

[ 
http://issues.apache.org/jira/browse/AXIS2-661?page=comments#action_12378376 ] 

Thilo Frotscher commented on AXIS2-661:
---


Sorry, I think my comment was mistakable. It's not the jaxme libraries (i.e. 
jar files) that the server can't find, but the generated files (classes, 
jaxb.properties, Configuration.xml). These files are contained in the aar file, 
but deploying the aar file is not enough: the same files have to be copied to 
webapps\axis2\WEB-INF\classes, otherwise there is an exception when the service 
is invoked. This way, the same files are deployed twice (aar file and classes 
folder)

The other to issues reported in my first comment apply to Axis2 1.0 final as 
well.

Thanks!
 



> WSDL2Java generates wrong build.xml when jaxme option is used
> -
>
>  Key: AXIS2-661
>  URL: http://issues.apache.org/jira/browse/AXIS2-661
>  Project: Apache Axis 2.0 (Axis2)
> Type: Bug

>   Components: Tools
>  Environment: Axis2 1.0 RC5
> Reporter: Thilo Frotscher
> Assignee: Ajith Harshana Ranabahu

>
> When WSDL2Java is used with the jaxme option for databinding , there are two 
> bugs:
> - it generates a build.xml for the xmlbeans databinding instead for jaxme
> - ns2p option does not seem to work for jaxme (but works fine for adb and 
> xmlbeans)

-- 
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: (AXIS2-647) "Unbound namespace URI" when generating code for ADB and using chained schema imports

2006-05-07 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-647?page=comments#action_12378359 ] 

Thilo Frotscher commented on AXIS2-647:
---


Hello Ajith,

I tried this again with Axis2 1.0 final. The "Unbound namespace URI" exception 
is not thrown anymore, so this bug is fixed. Great!
However, I now get an exception on the client side, when the generated client 
code is trying to process the SOAP response:

java.lang.RuntimeException: java.lang.RuntimeException: Unexpected subelement 
menu
at 
org.apache.axis2.RestaurantServiceStub.fromOM(RestaurantServiceStub.java:577)
at 
org.apache.axis2.RestaurantServiceStub.GetMenuList(RestaurantServiceStub.java:118)
at 
org.apache.axis2.MyADBServiceClient.testADB(MyADBServiceClient.java:52)
at org.apache.axis2.MyADBServiceClient.main(MyADBServiceClient.java:79)
Caused by: java.lang.RuntimeException: Unexpected subelement menu
at 
org.apache.axis2.RestaurantServiceStub$MenuList$Factory.parse(RestaurantServiceStub.java:1732)
at 
org.apache.axis2.RestaurantServiceStub$GetMenuListResponse$Factory.parse(RestaurantServiceStub.java:796)
at 
org.apache.axis2.RestaurantServiceStub.fromOM(RestaurantServiceStub.java:559)
... 3 more

I compared the SOAP responses that are sent by the service code generated from 
1 XSD with the SOAP responses sent from service code generated from 2 XSDs (see 
above). The SOAP responses are exactly the same.  Therefore the issue must be 
somewhere in the generated client code (when using 2 XSDs).



> "Unbound namespace URI" when generating code for ADB and using chained schema 
> imports
> -
>
>  Key: AXIS2-647
>  URL: http://issues.apache.org/jira/browse/AXIS2-647
>  Project: Apache Axis 2.0 (Axis2)
> Type: Bug

>  Environment: Axis2 1.0 RC4
> Reporter: Thilo Frotscher
>  Attachments: Restaurant.xsd, RestaurantMessages.xsd, RestaurantService.aar, 
> RestaurantService.wsdl, restaurant-client-src.zip, restaurant-src.zip
>
> My scenario is as follows:
> - I defined the datatypes for my sample application in file Restaurant.xsd 
> and namespace R1
> - I defined the messages for communication with the RestaurantService in file 
> RestaurantMessages.xsd and namespace R2
> - RestaurantMessages.xsd imports Restaurant.xsd, since the messages make use 
> of the basic datatypes.
> - My WSDL imports RestaurantMessages.xsd
> - WS-I test tools show that this WSDL complies to BP
> - This scenario worked nicely with Axis 1.3
> I generated service and client code for this WSDL with WSDL2Java and ADB 
> option. When I send a message to the service using the generated proxy, I get 
> an "Unbound namespace URI" error for namespace R1( ! ) on the server side. 
> That is interesting, because the messages that are sent back and forth are 
> all in namespace R2 and my request message does not contain any reference to 
> R1 whatsoever. However, the response message (R2) is supposed to contain 
> types defined in Restaurant.xsd.
>  
> If I move all the datatype definitions from file Restaurant.xsd into 
> RestaurantMessages.xsd and thus from R1 to R2, everything works fine.
> Apparently Axis2 / ADB has issues with chained imports, perhaps only if not 
> all of the imports belong to the same namespace.

-- 
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: (AXIS2-661) WSDL2Java generates wrong build.xml when jaxme option is used

2006-05-07 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-661?page=comments#action_12378353 ] 

Thilo Frotscher commented on AXIS2-661:
---


PS: The above issues apply to Axis2 1.0 final as well.


> WSDL2Java generates wrong build.xml when jaxme option is used
> -
>
>  Key: AXIS2-661
>  URL: http://issues.apache.org/jira/browse/AXIS2-661
>  Project: Apache Axis 2.0 (Axis2)
> Type: Bug

>   Components: Tools
>  Environment: Axis2 1.0 RC5
> Reporter: Thilo Frotscher
> Assignee: Ajith Harshana Ranabahu

>
> When WSDL2Java is used with the jaxme option for databinding , there are two 
> bugs:
> - it generates a build.xml for the xmlbeans databinding instead for jaxme
> - ns2p option does not seem to work for jaxme (but works fine for adb and 
> xmlbeans)

-- 
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: (AXIS2-661) WSDL2Java generates wrong build.xml when jaxme option is used

2006-05-07 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-661?page=comments#action_12378352 ] 

Thilo Frotscher commented on AXIS2-661:
---


There's one more issue: in case of jaxme databinding it is not sufficient to 
deploy the aar file that was generated by the build.xml. For some reason the 
server can't find the class files and configuration files for jaxme when the 
service is invoked. Therefore, I had to copy all class files and config file to 
webapps/classes in addition to deploying the aar file. After that, the service 
worked fine...


> WSDL2Java generates wrong build.xml when jaxme option is used
> -
>
>  Key: AXIS2-661
>  URL: http://issues.apache.org/jira/browse/AXIS2-661
>  Project: Apache Axis 2.0 (Axis2)
> Type: Bug

>   Components: Tools
>  Environment: Axis2 1.0 RC5
> Reporter: Thilo Frotscher
> Assignee: Ajith Harshana Ranabahu

>
> When WSDL2Java is used with the jaxme option for databinding , there are two 
> bugs:
> - it generates a build.xml for the xmlbeans databinding instead for jaxme
> - ns2p option does not seem to work for jaxme (but works fine for adb and 
> xmlbeans)

-- 
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: (AXIS2-662) JAR files for jaxme missing in axis2.war

2006-05-04 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-662?page=comments#action_12377962 ] 

Thilo Frotscher commented on AXIS2-662:
---


Thanks. But then there should be some documentation for this :-)

- what's the name of the properties file and where does it have to be stored
- which jars have to be put into the classpath for the several data bindings


> JAR files for jaxme missing in axis2.war
> 
>
>  Key: AXIS2-662
>  URL: http://issues.apache.org/jira/browse/AXIS2-662
>  Project: Apache Axis 2.0 (Axis2)
> Type: Bug

>   Components: core
>  Environment: Axis2 1.0 RC5
> Reporter: Thilo Frotscher

>
> The following JAR files are missing in axis2.war. They are needed if a 
> service uses jaxme databinding.
> jaxmeapi-0.5.1.jar, stax-utils-20060501.jar, jaxme2-0.5.1, jaxmexs-0.5.1

-- 
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: (AXIS2-653) Handler method "cleanup" is never called

2006-05-04 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-653?page=comments#action_12377961 ] 

Thilo Frotscher commented on AXIS2-653:
---

IMHO it would be very important for handlers to be notified if something went 
wrong, so that they have a chance to redo actions that were caused by the 
message causing the error. Imagine a handler responsible for billing, which 
tracks incoming messages to charge clients afterwards. A client would not want 
to pay for request that didn't go through due to exceptions that occured - 
let's say - in a logging handler that was invoked after the billing handler.
Axis 1.x had a very good mechanims, in which all prior handlers were informed 
when an error occured in a subsequent handler. Axis2 should have this, too.

Regarding to cleanup: handlers should be able to cleanup the ressources they 
used (e.g. database connections etc)  

> Handler method "cleanup" is never called
> 
>
>  Key: AXIS2-653
>  URL: http://issues.apache.org/jira/browse/AXIS2-653
>  Project: Apache Axis 2.0 (Axis2)
> Type: Bug

>   Components: core
>     Versions: 1.0
> Reporter: Thilo Frotscher

>
> 1) My IDE couldn't find any references to method "cleanup" in the Axis2 
> source code. It's never called...
> 2) What happens if the handler's invoke method thows a fault? Javadoc for 
> "invoke" says that "onFault" would be called. But there is no such method...
> 3) User guide, page 4 
> - mentions a method called "revoke". There is no such method in interface 
> Handler. 
> - refers to green lines in sample configuration...there are no green lines
> - sample configuration contains mistakes
>  

-- 
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: (AXIS2-663) WSDL2Java: allow user to specify separate destination folders for src and resources

2006-05-04 Thread Thilo Frotscher (JIRA)

[ 
http://issues.apache.org/jira/browse/AXIS2-663?page=comments#action_12377806 ] 

Thilo Frotscher commented on AXIS2-663:
---

Exactly that's the problem...that WSDL2Java generates code with only a single 
service in mind. The problem arises, when you have to use WSDL2Java more than 
once in the same project. It happens quite often that you want to implement 
more than one service in the same project (or clients for more than one service 
in the same project).
In this case, you would run WSDL2Java several times, and then the generated 
files overwrite each other. That's why it would be great to have the ability to 
separate the results of multiple WSDL2Java calls from each other.

> WSDL2Java: allow user to specify separate destination folders for src and 
> resources
> ---
>
>  Key: AXIS2-663
>  URL: http://issues.apache.org/jira/browse/AXIS2-663
>  Project: Apache Axis 2.0 (Axis2)
> Type: Improvement

>   Components: Tools
> Versions: 1.0
>  Environment: Axis2 1.0 RC5
> Reporter: Thilo Frotscher

>
> WSDL2Java generates source code, resources (service.xml, wsdl, xsd) and a 
> build.xml file.
> The user can specify a destination folder for all of these files, but they 
> all go into the same folder.
> When generating code for more than one service, you'll generally want to have 
> the source code for all services in the same src-folder.
> That's why you would specify the same destination folder for all services. 
> However, in this causes the problem that the build.xml files 
> and the resources for all the services go into the same folder as well and 
> interfere with each other, or a overwritten respectively.
> Therefore, it would be great if the user could specify two separate 
> destination folders: one for the source code and the second one for 
> the build file and the resources. Of course, the build files would have to 
> reflect the new folder structure.
> Alternative suggestion: WSDL2Java could do this automatically by introducing 
> a service-specific folder
> under resouces:
> /resources/MyService1/service.xml
> /resources/MyService1/MyService.wsdl
> /resources/MyService1/MyService.xsd
> /resources/MyService2/service.xml
> /resources/MyService2/MyService.wsdl
> /resources/MyService2/MyService.xsd
> For the build files a similar solution could be used.

-- 
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] Created: (AXIS2-664) Exception when generating code for C#

Exception when generating code for C#
-

 Key: AXIS2-664
 URL: http://issues.apache.org/jira/browse/AXIS2-664
 Project: Apache Axis 2.0 (Axis2)
Type: Bug

  Components: Tools  
Versions: 1.0
 Environment: Axis2 1.0 RC5
Reporter: Thilo Frotscher



WSDL2Code cannot find code template for C#...

Exception in thread "main" 
org.apache.axis2.wsdl.codegen.CodeGenerationException: 
org.apache.axis2.wsdl.codegen.CodeGenerationException: 
org.apache.axis2.wsdl.codegen.CodeGenerationException: template for this writer 
is not found!
at 
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:185)
at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: 
org.apache.axis2.wsdl.codegen.CodeGenerationException: template for this writer 
is not found!
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.emitSkeleton(AxisServiceBasedMultiLanguageEmitter.java:640)
at 
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:168)
... 1 more
Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: template for 
this writer is not found!
at 
org.apache.axis2.wsdl.codegen.writer.ClassWriter.loadTemplate(ClassWriter.java:80)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.writeClass(AxisServiceBasedMultiLanguageEmitter.java:1346)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.writeSkeletonInterface(AxisServiceBasedMultiLanguageEmitter.java:1092)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.emitSkeletonService(AxisServiceBasedMultiLanguageEmitter.java:686)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.emitSkeleton(AxisServiceBasedMultiLanguageEmitter.java:638)
... 2 more

-- 
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] Created: (AXIS2-663) WSDL2Java: allow user to specify separate destination folders for src and resources

WSDL2Java: allow user to specify separate destination folders for src and 
resources
---

 Key: AXIS2-663
 URL: http://issues.apache.org/jira/browse/AXIS2-663
 Project: Apache Axis 2.0 (Axis2)
Type: Improvement

  Components: Tools  
Versions: 1.0
 Environment: Axis2 1.0 RC5
Reporter: Thilo Frotscher


WSDL2Java generates source code, resources (service.xml, wsdl, xsd) and a 
build.xml file.
The user can specify a destination folder for all of these files, but they all 
go into the same folder.

When generating code for more than one service, you'll generally want to have 
the source code for all services in the same src-folder.
That's why you would specify the same destination folder for all services. 
However, in this causes the problem that the build.xml files 
and the resources for all the services go into the same folder as well and 
interfere with each other, or a overwritten respectively.
Therefore, it would be great if the user could specify two separate destination 
folders: one for the source code and the second one for 
the build file and the resources. Of course, the build files would have to 
reflect the new folder structure.

Alternative suggestion: WSDL2Java could do this automatically by introducing a 
service-specific folder
under resouces:

/resources/MyService1/service.xml
/resources/MyService1/MyService.wsdl
/resources/MyService1/MyService.xsd
/resources/MyService2/service.xml
/resources/MyService2/MyService.wsdl
/resources/MyService2/MyService.xsd

For the build files a similar solution could be used.


-- 
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] Created: (AXIS2-661) WSDL2Java generates wrong build.xml when jaxme option is used

WSDL2Java generates wrong build.xml when jaxme option is used
-

 Key: AXIS2-661
 URL: http://issues.apache.org/jira/browse/AXIS2-661
 Project: Apache Axis 2.0 (Axis2)
Type: Bug

  Components: Tools  
 Environment: Axis2 1.0 RC5
Reporter: Thilo Frotscher



When WSDL2Java is used with the jaxme option for databinding , there are two 
bugs:

- it generates a build.xml for the xmlbeans databinding instead for jaxme
- ns2p option does not seem to work for jaxme (but works fine for adb and 
xmlbeans)


-- 
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] Created: (AXIS2-662) JAR files for jaxme missing in axis2.war

JAR files for jaxme missing in axis2.war 
-

 Key: AXIS2-662
 URL: http://issues.apache.org/jira/browse/AXIS2-662
 Project: Apache Axis 2.0 (Axis2)
Type: Bug

  Components: core  
 Environment: Axis2 1.0 RC5
Reporter: Thilo Frotscher



The following JAR files are missing in axis2.war. They are needed if a service 
uses jaxme databinding.

jaxmeapi-0.5.1.jar, stax-utils-20060501.jar, jaxme2-0.5.1, jaxmexs-0.5.1

-- 
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: (AXIS2-647) "Unbound namespace URI" when generating code for ADB and using chained schema imports