You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Mauro Molinari <ma...@cardinis.com> on 2007/11/20 10:53:47 UTC
Shared schemas: where to put them?
Hello!
I have a problem if I want to share some schema files between services.
Suppose I have the following structure:
The WSDLs for MyService1 and MyService2 are in the following folders,
respectively:
contextpath/WEB-INF/services/MyService1/META-INF/
contextpath/WEB-INF/services/MyService2/META-INF/
I want them to share Common.xsd: where should I put it?
If I put it here:
contextpath/WEB-INF/services/
and the xsd:import schemaLocation in the WSDLs points to
"../../Common.xsd", Axis2 can find them and processes the services
correctly, but when it substitutes the link to it in the WSDLs, it
generates the following links:
MyService1?xsd=../../Common.xsd (in MyService1 WSDL)
MyService2?xsd=../../Common.xsd (in MyService2 WSDL)
The problem is that from an HTTP client point of view, this translates
to path contextpath/Common.xsd: in fact, if you try to write the link:
http://server:8080/contextpath/services/MyService1?xsd=../../Common.xsd
a "file not found" error is given.
Another clue is that if I try to generate a client pointing to
http://server:8080/contextpath/services/MyService1?wsdl, Java2WSDL says
that it cannot retrieve the schema.
By manually typing:
http://server:8080/contextpath/services/MyService1?xsd=../Common.xsd
I see that the schema can actually be found; but if I replace the
xsd:import in the original WSDL so that the schemaLocation points to
"../Common.xsd", then Axis2 can't find it anymore, because it searches
for it in contextpath/WEB-INF/services/MyService1/ and the generation of
the WSDL fails.
How to face this problem? Where should I put the shared schemas? How to
reference them from within the original WSDLs?
Thanks in advance.
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Shared schemas: where to put them?
Posted by Mauro Molinari <ma...@cardinis.com>.
Mauro Molinari ha scritto:
> Another clue is that if I try to generate a client pointing to
> http://server:8080/contextpath/services/MyService1?wsdl, Java2WSDL says
> that it cannot retrieve the schema.
Sorry, I meant WSDL2Java, not Java2WSDL ;-)
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Shared schemas: where to put them?
Posted by Mauro Molinari <ma...@cardinis.com>.
Hi Sietse!
sietsenicolaas.tenhoeve@bt.com ha scritto:
> Hi Mauro,
>
> I am not working in a big dev environment. But that doesn't make a
> difference. Common schemas or parts of it isn't a problem.
>
> I also have the webservice structure in SCM (svn in this case). Having
> the generated code in there is the wrong usage of it in my opinion. This
> causes duplication. What I do is:
> - Check out the sources (using eclipse or another program/IDE who can
> perform svn client operations);
This is a not so easy thing: our application is made up of something
like 20 different software modules, each of them have its own version
information and must be checked out and put together to prepare a
complete project for the web application. We have some Ant scripts that
can partially automatize this task, but there are some implications with
Eclipse, which has a CVS support that is not so flexible... but this is
another story.
> - Let the IDE generate the sources (I use maven for this, but ant can
> also be used);
We don't use Maven, but we can use Ant. First problem here is this: were
to store the ant script to do that? Which relation should it have with
the code, with the modules and with their versions? This is overhead...
> I hope this helps you. I think the important bit is to NOT duplicate
> sources in the SCM (which you do imho with storing the generated
> sources).
But why do you say that putting Axis2 generated code under source
control means duplicating code? I don't have any duplicated code! For
each WSDL I have a couple of unique generated classes, while I share
generated types between web services implementations by translating
shared schemas.
If one day you have to modify a WSDL, you just need to generate code for
it again and commit it over the previous one.
This also enables you to make changes to the generated code, if needed:
I know this has to be done with care, but sometimes it could be necessary.
Moreover, if I understood it well, you are saying that you have some
code under source control that doesn't compile as soon as you don't
generate the Java code from the WSDLs each time you do a checkout?
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Shared schemas: where to put them?
Posted by Mauro Molinari <ma...@cardinis.com>.
sietsenicolaas.tenhoeve@bt.com ha scritto:
> Hi Peter and Mauro,
>
> I agree that this is offtopic, but I think this discussion is very
> important! That's why I continue on it.
Hi Sietse,
although I must admit that, generally speaking, I agree with you and
Peter on the possibility to dynamically generate code at
development/deploy time instead of putting under version control
resources that are simply automatically generated, in this specific
circustamce I still can't find a ultimate reason that points out real
disadvantages with our approach, considering also the fact that you are
precluding yourself any chance to edit and/or fine-tune the generated
code (even if I know this has to be done with care).
Anyway, I opened a JIRA with my original request, as it seems to me that
Axis2 lacks an option to actually share schemas and WSDLs between services:
https://issues.apache.org/jira/browse/AXIS2-3354
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
RE: Shared schemas: where to put them?
Posted by si...@bt.com.
Hi Peter and Mauro,
I agree that this is offtopic, but I think this discussion is very
important! That's why I continue on it.
The usage of ant / maven doesn't matter. They wanted me to work with
maven, and I start being happy with it (after a lot of struggle).
Peter's point is exactly what I wanted to point out and that is:
- When we set up a new development environment, a checkout is done and
an ANT script is run (in my case "mvn clean generate-sources").
I think it is also important to be IDE independent. That way every
developer can work with his favourite IDE and I don't see a reason why
an dependency to an IDE should be a part of the product. In my opinion
you should have an automated build (i.e. "ant build", "mvn package").
Every manual action needed is one too much and is error prone.
Project dependencies are one of the points where maven is very strong!
Although I haven't used it widely, because I don't have all those
dependencies on own packages, maven can handle these for you. I think
there also is an ant workaround for it but I can't answer that question.
I only have the main ant knowledge.
The build script is part of the build, so it should be stored in CVS
yes. You should store everything which is needed to create a build in
the CVS. When someone checks out from the trunk, he/she needs to be able
to build the complete system automatically.
Mauro: But why do you say that putting Axis2 generated code under source
control means duplicating code?
The source is the wsdl + xsd files, not the generated source. The
duplication is the generated source, which is exactly the same as the
wsdl + xsd files. This is important to notice, and that is exactly the
reason that it is not needed.
If the wsdl / xsd files are changing, you change the contract of the
service. It is fair in my opinion that you've to adjust the code which
makes use of the generated sources for that.
You are right that the code under version control isn't compilable
directly, it needs the code generation first!
Regards,
Sietse
-----Original Message-----
From: Peter Hrastnik [mailto:Peter.Hrastnik@sonydadc.com]
Sent: 20 November 2007 12:56
To: axis-user@ws.apache.org
Subject: RE: Shared schemas: where to put them?
Hi Mauro!
Just want to add my 2 cents (even though it's off-topic), perhaps it
helps you.
We are using (My)Eclipse, keep the sources in CVS, and do not put
generated artefacts into CVS. It's like Sietse's approach. Concerning
magnitude, we have 5 Web services with ~5 operations per service.
When we set up a new development environment, a checkout is done and an
ANT script is run - that's all the Webapplication is ready for
development AND deployment (the ant script generates needed aretfacts
directly in the WEB-INF folder). Development is done using hot code
replacement on a local Tomcat Server (Eclipse compiles classes to
/WEB-INF/classes, no reload/restart is necessary changes are in effect
immediately). Artefacts don't have to be generated for each code change
during development. For a production release, the ANT script generates a
clean WAR file from scratch (this includes artefact generation and
re-compilation of sources).
So, artefact generation takes place only when setting up the
environment, for making production releases, and of course when source
WSDL and/or XSD documents change. The overhead added to the development
process is neglibible, also (but not only) because WSDL s and XSDs tend
to change infrequently. However, resources needed for developing the
necessary ANT build script were definitly significant.
Cheers,
Peter.
<si...@bt.com> schrieb am 20.11.2007 12:37:40:
> Hi Mauro,
>
> I am not working in a big dev environment. But that doesn't make a
> difference. Common schemas or parts of it isn't a problem.
>
> I also have the webservice structure in SCM (svn in this case). Having
> the generated code in there is the wrong usage of it in my opinion.
> This causes duplication. What I do is:
> - Check out the sources (using eclipse or another program/IDE who can
> perform svn client operations);
> - Let the IDE generate the sources (I use maven for this, but ant can
> also be used);
> - Now you have a working environment on your local machine (which
> should be independent of IDE/OS etc);
> - Go ahead and makes changes / improvements to your code. (I like the
> test driven approach, but learning that atm);
> - Try running them locally;
> - If it works local, check out the newest version from the SCM (to
> adapt with changes from other developers);
> - If you got it working and the tests pass after this you check the
> changes in to the SCM.
>
> I hope this helps you. I think the important bit is to NOT duplicate
> sources in the SCM (which you do imho with storing the generated
> sources).
>
> Regards,
> Sietse
>
> -----Original Message-----
> From: Mauro Molinari [mailto:mauro.molinari@cardinis.com]
> Sent: 20 November 2007 11:25
> To: axis-user@ws.apache.org
> Subject: Re: Shared schemas: where to put them?
>
> sietsenicolaas.tenhoeve@bt.com ha scritto:
> > Hi all,
> >
> > In my opinion Peter sketched out a nice solution. Why do you care of
> > having multiple copies of the xsd while they're generated? Generated
> > code shouldn't be in version management, only the sources. And
> > because
>
> > of his solution makes use of only one xsd you're not duplicating
> > anything. The only source is the original (shared) xsd file.
>
> Hi Sietse,
> I don't know which is your development environment, however here we
> have a very huge web application for which we are going to write many
> web services. These web services can have some data in common (think
> of exceptions/faults, for instance) and this is why we need a shared
> common.xsd.
> We use environments like Eclipse and Netbeans to develop. Having the
> webservice structure ready after a CVS checkout enables us to let the
> IDE auomatically do the deployment and hit a couple of clicks to make
> the webapp start inside our development environment, in order to test
> and/or debug.
> Adding a custom deployment phase like the replication of this XSD into
> all services META-INF folders breaks this automation. Although there
> are ways of partially solve this, it simply adds overhead to a process
> that isn't working because of what seems to me just a minor flaw of
Axis2.
>
> Moreover, maybe I'm missing something, but I can hardly realize how
> you could implement your webservices without putting the generated
> code (at least the Java code) under version control... How do you fill
> your skeleton with the implementation? How do you use type classes
> generated from the WSDL if they are not available at development time?
>
> --
> Mauro Molinari
> Software Developer
> mauro.molinari@cardinis.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
RE: Shared schemas: where to put them?
Posted by Peter Hrastnik <Pe...@sonydadc.com>.
Hi Mauro!
Just want to add my 2 cents (even though it's off-topic), perhaps it helps
you.
We are using (My)Eclipse, keep the sources in CVS, and do not put
generated artefacts into CVS. It's like Sietse's approach. Concerning
magnitude, we have 5 Web services with ~5 operations per service.
When we set up a new development environment, a checkout is done and an
ANT script is run - that's all the Webapplication is ready for development
AND deployment (the ant script generates needed aretfacts directly in the
WEB-INF folder). Development is done using hot code replacement on a local
Tomcat Server (Eclipse compiles classes to /WEB-INF/classes, no
reload/restart is necessary changes are in effect immediately). Artefacts
don't have to be generated for each code change during development. For a
production release, the ANT script generates a clean WAR file from scratch
(this includes artefact generation and re-compilation of sources).
So, artefact generation takes place only when setting up the environment,
for making production releases, and of course when source WSDL and/or XSD
documents change. The overhead added to the development process is
neglibible, also (but not only) because WSDL s and XSDs tend to change
infrequently. However, resources needed for developing the necessary ANT
build script were definitly significant.
Cheers,
Peter.
<si...@bt.com> schrieb am 20.11.2007 12:37:40:
> Hi Mauro,
>
> I am not working in a big dev environment. But that doesn't make a
> difference. Common schemas or parts of it isn't a problem.
>
> I also have the webservice structure in SCM (svn in this case). Having
> the generated code in there is the wrong usage of it in my opinion. This
> causes duplication. What I do is:
> - Check out the sources (using eclipse or another program/IDE who can
> perform svn client operations);
> - Let the IDE generate the sources (I use maven for this, but ant can
> also be used);
> - Now you have a working environment on your local machine (which should
> be independent of IDE/OS etc);
> - Go ahead and makes changes / improvements to your code. (I like the
> test driven approach, but learning that atm);
> - Try running them locally;
> - If it works local, check out the newest version from the SCM (to adapt
> with changes from other developers);
> - If you got it working and the tests pass after this you check the
> changes in to the SCM.
>
> I hope this helps you. I think the important bit is to NOT duplicate
> sources in the SCM (which you do imho with storing the generated
> sources).
>
> Regards,
> Sietse
>
> -----Original Message-----
> From: Mauro Molinari [mailto:mauro.molinari@cardinis.com]
> Sent: 20 November 2007 11:25
> To: axis-user@ws.apache.org
> Subject: Re: Shared schemas: where to put them?
>
> sietsenicolaas.tenhoeve@bt.com ha scritto:
> > Hi all,
> >
> > In my opinion Peter sketched out a nice solution. Why do you care of
> > having multiple copies of the xsd while they're generated? Generated
> > code shouldn't be in version management, only the sources. And because
>
> > of his solution makes use of only one xsd you're not duplicating
> > anything. The only source is the original (shared) xsd file.
>
> Hi Sietse,
> I don't know which is your development environment, however here we have
> a very huge web application for which we are going to write many web
> services. These web services can have some data in common (think of
> exceptions/faults, for instance) and this is why we need a shared
> common.xsd.
> We use environments like Eclipse and Netbeans to develop. Having the
> webservice structure ready after a CVS checkout enables us to let the
> IDE auomatically do the deployment and hit a couple of clicks to make
> the webapp start inside our development environment, in order to test
> and/or debug.
> Adding a custom deployment phase like the replication of this XSD into
> all services META-INF folders breaks this automation. Although there are
> ways of partially solve this, it simply adds overhead to a process that
> isn't working because of what seems to me just a minor flaw of Axis2.
>
> Moreover, maybe I'm missing something, but I can hardly realize how you
> could implement your webservices without putting the generated code (at
> least the Java code) under version control... How do you fill your
> skeleton with the implementation? How do you use type classes generated
> from the WSDL if they are not available at development time?
>
> --
> Mauro Molinari
> Software Developer
> mauro.molinari@cardinis.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
RE: Shared schemas: where to put them?
Posted by si...@bt.com.
Hi Mauro,
I am not working in a big dev environment. But that doesn't make a
difference. Common schemas or parts of it isn't a problem.
I also have the webservice structure in SCM (svn in this case). Having
the generated code in there is the wrong usage of it in my opinion. This
causes duplication. What I do is:
- Check out the sources (using eclipse or another program/IDE who can
perform svn client operations);
- Let the IDE generate the sources (I use maven for this, but ant can
also be used);
- Now you have a working environment on your local machine (which should
be independent of IDE/OS etc);
- Go ahead and makes changes / improvements to your code. (I like the
test driven approach, but learning that atm);
- Try running them locally;
- If it works local, check out the newest version from the SCM (to adapt
with changes from other developers);
- If you got it working and the tests pass after this you check the
changes in to the SCM.
I hope this helps you. I think the important bit is to NOT duplicate
sources in the SCM (which you do imho with storing the generated
sources).
Regards,
Sietse
-----Original Message-----
From: Mauro Molinari [mailto:mauro.molinari@cardinis.com]
Sent: 20 November 2007 11:25
To: axis-user@ws.apache.org
Subject: Re: Shared schemas: where to put them?
sietsenicolaas.tenhoeve@bt.com ha scritto:
> Hi all,
>
> In my opinion Peter sketched out a nice solution. Why do you care of
> having multiple copies of the xsd while they're generated? Generated
> code shouldn't be in version management, only the sources. And because
> of his solution makes use of only one xsd you're not duplicating
> anything. The only source is the original (shared) xsd file.
Hi Sietse,
I don't know which is your development environment, however here we have
a very huge web application for which we are going to write many web
services. These web services can have some data in common (think of
exceptions/faults, for instance) and this is why we need a shared
common.xsd.
We use environments like Eclipse and Netbeans to develop. Having the
webservice structure ready after a CVS checkout enables us to let the
IDE auomatically do the deployment and hit a couple of clicks to make
the webapp start inside our development environment, in order to test
and/or debug.
Adding a custom deployment phase like the replication of this XSD into
all services META-INF folders breaks this automation. Although there are
ways of partially solve this, it simply adds overhead to a process that
isn't working because of what seems to me just a minor flaw of Axis2.
Moreover, maybe I'm missing something, but I can hardly realize how you
could implement your webservices without putting the generated code (at
least the Java code) under version control... How do you fill your
skeleton with the implementation? How do you use type classes generated
from the WSDL if they are not available at development time?
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Shared schemas: where to put them?
Posted by Mauro Molinari <ma...@cardinis.com>.
sietsenicolaas.tenhoeve@bt.com ha scritto:
> Hi all,
>
> In my opinion Peter sketched out a nice solution. Why do you care of
> having multiple copies of the xsd while they're generated? Generated
> code shouldn't be in version management, only the sources. And because
> of his solution makes use of only one xsd you're not duplicating
> anything. The only source is the original (shared) xsd file.
Hi Sietse,
I don't know which is your development environment, however here we have
a very huge web application for which we are going to write many web
services. These web services can have some data in common (think of
exceptions/faults, for instance) and this is why we need a shared
common.xsd.
We use environments like Eclipse and Netbeans to develop. Having the
webservice structure ready after a CVS checkout enables us to let the
IDE auomatically do the deployment and hit a couple of clicks to make
the webapp start inside our development environment, in order to test
and/or debug.
Adding a custom deployment phase like the replication of this XSD into
all services META-INF folders breaks this automation. Although there are
ways of partially solve this, it simply adds overhead to a process that
isn't working because of what seems to me just a minor flaw of Axis2.
Moreover, maybe I'm missing something, but I can hardly realize how you
could implement your webservices without putting the generated code (at
least the Java code) under version control... How do you fill your
skeleton with the implementation? How do you use type classes generated
from the WSDL if they are not available at development time?
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
RE: Shared schemas: where to put them?
Posted by si...@bt.com.
Hi all,
In my opinion Peter sketched out a nice solution. Why do you care of
having multiple copies of the xsd while they're generated? Generated
code shouldn't be in version management, only the sources. And because
of his solution makes use of only one xsd you're not duplicating
anything. The only source is the original (shared) xsd file.
I have to use this soon too, so this message opened my eyes on this
point!
Regards,
Sietse
-----Original Message-----
From: Mauro Molinari [mailto:mauro.molinari@cardinis.com]
Sent: 20 November 2007 10:56
To: axis-user@ws.apache.org
Subject: Re: Shared schemas: where to put them?
Hi Peter,
thank you for your reply!
Peter Hrastnik ha scritto:
> Hi!
>
> I had similar requirements and decided to rely on code generation by
> WSDL2JAVA. WSDL2JAVA takes the unique shared XSD from a source
> directory and copies it for each service. That is, I have a directory
> wsdlDefinitions that contains service1.wsdl, service2.wsdl, and
> common.xsd. Then I run WSDL2JAVA to generate server code with the -R
> option, and .../MyService1/META-INF/service1.wsdl
> .../MyService1/META-INF/common.xsd
>
> .../MyService2/META-INF/service2.wsdl
> .../MyService2/META-INF/common.xsd
>
> are generated. I have no troubles with the replication of common.xsd
> because I only change wsdlDefinitions/common.xsd. Generated artefacts
> won't be touched anyway.
This could be a work-around, although it is not so convenient if all
those things are then put under version-control.
I might consider to add the replication of common.xsd in every META-INF
directory at deploy time, but this makes things more complicate than
they should and could cause a burden at development time when working
with IDEs.
I was wondering if a more clean way of doing this exists, however thank
you very much for your suggestion!
> I know that my approach above may not be appropriate in your
> situation. If so, perhaps You can try setting the useOriginalWSDL
> parameter in the service.xml to true. Frankly, I don't know the
effects of doing this.
Actually, I am using useOriginalWSDL="true". The problem is that if I
put things so that Axis2 can find all the WSDLs and XSDs and make the
necessary changes (e.g.: the port address, the WSDL and XSD import
locations, etc.), then things cannot be downloaded by a HTTP client;
while, if I put things so that HTTP client could access them, Axis2
cannot find all the WSDLs and XSDs anymore.
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Shared schemas: where to put them?
Posted by Mauro Molinari <ma...@cardinis.com>.
Hi Peter,
thank you for your reply!
Peter Hrastnik ha scritto:
> Hi!
>
> I had similar requirements and decided to rely on code generation by
> WSDL2JAVA. WSDL2JAVA takes the unique shared XSD from a source directory
> and copies it for each service. That is, I have a directory
> wsdlDefinitions that contains service1.wsdl, service2.wsdl, and
> common.xsd. Then I run WSDL2JAVA to generate server code with the -R
> option, and
> .../MyService1/META-INF/service1.wsdl
> .../MyService1/META-INF/common.xsd
>
> .../MyService2/META-INF/service2.wsdl
> .../MyService2/META-INF/common.xsd
>
> are generated. I have no troubles with the replication of common.xsd
> because I only change wsdlDefinitions/common.xsd. Generated artefacts
> won't be touched anyway.
This could be a work-around, although it is not so convenient if all
those things are then put under version-control.
I might consider to add the replication of common.xsd in every META-INF
directory at deploy time, but this makes things more complicate than
they should and could cause a burden at development time when working
with IDEs.
I was wondering if a more clean way of doing this exists, however thank
you very much for your suggestion!
> I know that my approach above may not be appropriate in your situation. If
> so, perhaps You can try setting the useOriginalWSDL parameter in the
> service.xml to true. Frankly, I don't know the effects of doing this.
Actually, I am using useOriginalWSDL="true". The problem is that if I
put things so that Axis2 can find all the WSDLs and XSDs and make the
necessary changes (e.g.: the port address, the WSDL and XSD import
locations, etc.), then things cannot be downloaded by a HTTP client;
while, if I put things so that HTTP client could access them, Axis2
cannot find all the WSDLs and XSDs anymore.
--
Mauro Molinari
Software Developer
mauro.molinari@cardinis.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Shared schemas: where to put them?
Posted by Peter Hrastnik <Pe...@sonydadc.com>.
Hi!
I had similar requirements and decided to rely on code generation by
WSDL2JAVA. WSDL2JAVA takes the unique shared XSD from a source directory
and copies it for each service. That is, I have a directory
wsdlDefinitions that contains service1.wsdl, service2.wsdl, and
common.xsd. Then I run WSDL2JAVA to generate server code with the -R
option, and
.../MyService1/META-INF/service1.wsdl
.../MyService1/META-INF/common.xsd
.../MyService2/META-INF/service2.wsdl
.../MyService2/META-INF/common.xsd
are generated. I have no troubles with the replication of common.xsd
because I only change wsdlDefinitions/common.xsd. Generated artefacts
won't be touched anyway.
I know that my approach above may not be appropriate in your situation. If
so, perhaps You can try setting the useOriginalWSDL parameter in the
service.xml to true. Frankly, I don't know the effects of doing this.
Good luck,
Peter.
Mauro Molinari <ma...@cardinis.com> schrieb am 20.11.2007
10:53:47:
> Hello!
> I have a problem if I want to share some schema files between services.
>
> Suppose I have the following structure:
>
> The WSDLs for MyService1 and MyService2 are in the following folders,
> respectively:
> contextpath/WEB-INF/services/MyService1/META-INF/
> contextpath/WEB-INF/services/MyService2/META-INF/
>
> I want them to share Common.xsd: where should I put it?
> If I put it here:
> contextpath/WEB-INF/services/
> and the xsd:import schemaLocation in the WSDLs points to
> "../../Common.xsd", Axis2 can find them and processes the services
> correctly, but when it substitutes the link to it in the WSDLs, it
> generates the following links:
>
> MyService1?xsd=../../Common.xsd (in MyService1 WSDL)
> MyService2?xsd=../../Common.xsd (in MyService2 WSDL)
>
> The problem is that from an HTTP client point of view, this translates
> to path contextpath/Common.xsd: in fact, if you try to write the link:
>
> http://server:8080/contextpath/services/MyService1?xsd=../../Common.xsd
> a "file not found" error is given.
> Another clue is that if I try to generate a client pointing to
> http://server:8080/contextpath/services/MyService1?wsdl, Java2WSDL says
> that it cannot retrieve the schema.
>
> By manually typing:
> http://server:8080/contextpath/services/MyService1?xsd=../Common.xsd
> I see that the schema can actually be found; but if I replace the
> xsd:import in the original WSDL so that the schemaLocation points to
> "../Common.xsd", then Axis2 can't find it anymore, because it searches
> for it in contextpath/WEB-INF/services/MyService1/ and the generation of
> the WSDL fails.
>
> How to face this problem? Where should I put the shared schemas? How to
> reference them from within the original WSDLs?
>
> Thanks in advance.
>
> --
> Mauro Molinari
> Software Developer
> mauro.molinari@cardinis.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org