You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Jarek Gawor <jg...@gmail.com> on 2008/10/28 22:20:01 UTC
Multiple deployers in axis2.xml
Hi,
Does anyone have comments on
https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would
like to know if we should allow for multiple deployers to be
registered for the same file extension (for any directory). Right now,
only one is assumed and that causes problems.
Thanks,
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Glen Daniels wrote:
> Hi Jarek, Deepal:
>
> Jarek Gawor wrote:
>> Deepal,
>>
>> I think you misunderstood. The code assumes there is one deploeyer per
>> extension. See DeploymentEngine.getDeployerForExtension(). That should
>> either be:
>>
>> Deployer getDeployerForExtension(String directory, String extension)
>>
>> or
>>
>> List<Deployer> getDeployerForExtension(String extension)
>
> The former, IMO. One extension per directory.
+1.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Jarek, Deepal:
Jarek Gawor wrote:
> Deepal,
>
> I think you misunderstood. The code assumes there is one deploeyer per
> extension. See DeploymentEngine.getDeployerForExtension(). That should
> either be:
>
> Deployer getDeployerForExtension(String directory, String extension)
>
> or
>
> List<Deployer> getDeployerForExtension(String extension)
The former, IMO. One extension per directory.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Jarek Gawor <jg...@gmail.com>.
Deepal,
I think you misunderstood. The code assumes there is one deploeyer per
extension. See DeploymentEngine.getDeployerForExtension(). That should
either be:
Deployer getDeployerForExtension(String directory, String extension)
or
List<Deployer> getDeployerForExtension(String extension)
Jarek
On Tue, Oct 28, 2008 at 7:05 PM, Deepal jayasinghe <de...@gmail.com> wrote:
> Done.
>
> Thank you!
> Deepal
>> Hi,
>>
>> Does anyone have comments on
>> https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would
>> like to know if we should allow for multiple deployers to be
>> registered for the same file extension (for any directory). Right now,
>> only one is assumed and that causes problems.
>>
>> Thanks,
>> Jarek
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>>
>
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
Done.
Thank you!
Deepal
> Hi,
>
> Does anyone have comments on
> https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would
> like to know if we should allow for multiple deployers to be
> registered for the same file extension (for any directory). Right now,
> only one is assumed and that causes problems.
>
> Thanks,
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
--
Thank you!
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
> Hey,
>
> I've been working on this problem and ran into some issues and would
> like to get your comments before committing a fix. The
> RepositoryListener.findServicesInDirectory() scans the "services"
> directory and tries to deploy service modules (.jar or .aar files)
> using ServiceDeployer. But also, when it files files with other
> extensions it tries to deploy them too using a Deployer registered for
> the given extension. For example, if you have the following deployer
> entry in the axis2.xml:
>
> <deployer extension=".svc" directory="widgets"
> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>
> The CustomDeployer will be used to deploy files with .svc extension in
> the "widgets" directory AND the "services" directory. That's a bit
> weird, IMHO.
>
> So, what I'm proposing is to remove the entire 'else' statement at
> line 303 on RepositoryListener.findServicesInDirectory() so that only
> service modules (.jar or .aar files) can be deployed from within the
> services directory. This solution might break some existing
> deployments where people put non-service module files under the
>
Nope actually it will not break anything , as I can see it is an
unnecessary check . Do you want me to fix that or if you want you can do
that to. May be you can send a patch ;-)
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
> Hi Jarek,
>
> Hmmm .. good question. I've actually been thinking for a while that
> the idea of associating a folder to a specific extension was a mistake.
Nope we are not , you can have all the extensions you want in a single
folder too. for example inside the POJO directory you can have both
.classs and .jar file.
But when you register you have to add two deployer elements in Axis2.xml
> To me that's very "static" thinking and its much more convenient to
> allow people to use whatever folder hierarchy they want and just put
> their services there, however the service is implemented.
>
> So my ideal scenario is that we allow /services to contain an
> arbitrary directory structure and that in each directory you can have
> any kind of deployable artifact (or more directories). I'd like to see
> the directory hierarchy become the URL path of the service (at least
> for HTTP; other transports can define their own mapping). So if you
> have: '
Yes , I recently implemented URL based configurator to support deployer
, so you can of course you URL as the directory. Well at the moment it
has to be relative URL to the root directory.
>
> /services
> /foo
> /bar.aar
> /baz/
> services.xml
> other stuff
> /bar
> /a.aar
> /b.js
>
Hmm , the problem with this is how do you associate dynamic directory
with a deployer. I mean in the case of foo/baz which is a directory and
those kind of stuff can be add a dynamically as well . So I can not
understand how we register folder for a directory , of course we can
register extensions for a deployer. Because you can scan the directory
and then find the corresponding deployer.
> etc. then you'd have all the following services:
> /foo/bar
> /foo/baz
> /bar/a
> /bar/b
>
> I think it'll be ok to say that if someone wants to put a .zip file
> somewhere and consider that a BPEL service (which is what we (WSO2) do
> in the hosting of BPEL/Ode processes as services IIRC). That is, it
> should be possible to say that a particular folder (structure) +
> extension combination can map to a particular service deployer.
> However that should not be the only way- I'd like the config to say
> something like
>
> extension a ==> deployer b
> directory m ==> deployer n
> directory x extension y ==> deployer z
of course this is very simple thing if you look at the current code.
>
> And you're allowed to have any number of either kind, but the order
> matters: most specific wins first and the later ones win over newer
> ones. So if you have a directory+extension combination then only that
> extension is supported in that directory. If you have a directory x
> specification then only that deployer is on for that directory etc..
I think this is too complex and we are trying to make thing too
complicated introducing who going to win and who going to loose, let's
keep it simple. I mean that is what I wanted when I introduce the
concept of Deployers. :-)
>
>
> Sanjiva.
>
> Jarek Gawor wrote:
>> Hey,
>>
>> I've been working on this problem and ran into some issues and would
>> like to get your comments before committing a fix. The
>> RepositoryListener.findServicesInDirectory() scans the "services"
>> directory and tries to deploy service modules (.jar or .aar files)
>> using ServiceDeployer. But also, when it files files with other
>> extensions it tries to deploy them too using a Deployer registered for
>> the given extension. For example, if you have the following deployer
>> entry in the axis2.xml:
>>
>> <deployer extension=".svc" directory="widgets"
>>
>> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>>
>> The CustomDeployer will be used to deploy files with .svc extension in
>> the "widgets" directory AND the "services" directory. That's a bit
>> weird, IMHO.
>>
>> So, what I'm proposing is to remove the entire 'else' statement at
>> line 303 on RepositoryListener.findServicesInDirectory() so that only
>> service modules (.jar or .aar files) can be deployed from within the
>> services directory. This solution might break some existing
>> deployments where people put non-service module files under the
>> services directory but that can be easily fixed by either moving the
>> files to the right directory or by adding another deployer entry in
>> axis2.xml for the services directory. For example:
>>
>> <deployer extension=".svc" directory="widgets"
>>
>> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>> <deployer extension=".svc" directory="services"
>>
>> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>>
>> Thoughts?
>>
>> Jarek
>>
>> On Tue, Oct 28, 2008 at 5:20 PM, Jarek Gawor <jg...@gmail.com> wrote:
>>> Hi,
>>>
>>> Does anyone have comments on
>>> https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would
>>> like to know if we should allow for multiple deployers to be
>>> registered for the same file extension (for any directory). Right now,
>>> only one is assumed and that causes problems.
>>>
>>> Thanks,
>>> Jarek
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>
>
--
Thank you!
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Deepal jayasinghe wrote:
>>
> Nope I did not say I am against the improvement what I told was we
> should not remove some working features , specially POJO deployer scenario.
+1.
> Yes of course and I am always +1 to make things more flexible , but
> without breaking what we have now.
That's what version numbers are for .. a major version change implies API
changes. Of course we need to be careful and make good judgment calls on
what should be changed, but I don't believe that its acceptable as an open
source project to say "we're always backwards compatible".
That's an invitation to freeze radical innovation. If we don't innovate
someone else will somewhere else.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
> Deepal, proposing an improvement is not saying some idea that was
> implemented some time ago was bad. That was the best we could do given
> the information we had then, but this is about improving things going
> forward.
>
Nope I did not say I am against the improvement what I told was we
should not remove some working features , specially POJO deployer scenario.
> There's no need to be defensive about decisions we made many years ago
> .. no decision is perfect and I can name at least 10 major flaws in
> Axis2 in hindsight. That doesn't mean we were stupid then - just means
> that we didn't know better. Hindsight is always 20/20.
>
> What I'm thinking about is a way to make it MUCH MORE flexible and
> user friendly than it is now. Clearly, YMMV.
Yes of course and I am always +1 to make things more flexible , but
without breaking what we have now.
>
> “When you're finished changing, you're finished.”
> .. Benjamin Franklin.
>
> Sanjiva.
>
> Deepal jayasinghe wrote:
>>> we can do some thing like that Jboss does. In Jboss if you want to
>>> deploy a web application either it should be put as .war file or under
>>> a directory of which name ends with .war .
>>>
>>> i.e in axis2 point of view either it should be bar.aar file or bar.aar
>>> directory.
>>>
>>> In my point of view always deployer should only map to an extension.
>> -1 , if you think the POJO deployer it can handle both .class files and
>> .jar files , so are you saying thats a problem. If we have the
>> flexibility and if we doing that for a long time without any problem,
>> then we should continue to keep it as it is.
>>> In the above way it can support both expanded and single file modes.
>> Hehe , seems like you are not happy with the current way , I do not
>> know whether you know about the deployment mechanism we had before the
>> deployer concept , and do you know how much of work JAX-WS people did to
>> deploy their services. FYI , at Apachecon US 2007 we had a BOF session
>> and their they mentioned what they are doing and the difficulties of the
>> process , so as solution to that problem I introduced the idea of
>> deployer , and whether you agree with me or not , it made the deployment
>> so flexible and more extensible. And I do not see a any issues with that
>> other thane the issue that Jarek mentioned.
>>
>> Thank you!
>> Deepal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Thank you!
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Deepal, proposing an improvement is not saying some idea that was
implemented some time ago was bad. That was the best we could do given the
information we had then, but this is about improving things going forward.
There's no need to be defensive about decisions we made many years ago ..
no decision is perfect and I can name at least 10 major flaws in Axis2 in
hindsight. That doesn't mean we were stupid then - just means that we
didn't know better. Hindsight is always 20/20.
What I'm thinking about is a way to make it MUCH MORE flexible and user
friendly than it is now. Clearly, YMMV.
“When you're finished changing, you're finished.”
.. Benjamin Franklin.
Sanjiva.
Deepal jayasinghe wrote:
>> we can do some thing like that Jboss does. In Jboss if you want to
>> deploy a web application either it should be put as .war file or under
>> a directory of which name ends with .war .
>>
>> i.e in axis2 point of view either it should be bar.aar file or bar.aar
>> directory.
>>
>> In my point of view always deployer should only map to an extension.
> -1 , if you think the POJO deployer it can handle both .class files and
> .jar files , so are you saying thats a problem. If we have the
> flexibility and if we doing that for a long time without any problem,
> then we should continue to keep it as it is.
>> In the above way it can support both expanded and single file modes.
> Hehe , seems like you are not happy with the current way , I do not
> know whether you know about the deployment mechanism we had before the
> deployer concept , and do you know how much of work JAX-WS people did to
> deploy their services. FYI , at Apachecon US 2007 we had a BOF session
> and their they mentioned what they are doing and the difficulties of the
> process , so as solution to that problem I introduced the idea of
> deployer , and whether you agree with me or not , it made the deployment
> so flexible and more extensible. And I do not see a any issues with that
> other thane the issue that Jarek mentioned.
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
>
> As I mentioned earlier this is about how people think about it. So I
> think one way and
> you think in another way :).
> Therefore if more people think that the current way is good enough
> lets keep it in that way. If more
> people want a change then do it in that way. Since this is a community. :)
+1 , and one more thing as I mentioned in one of my previous mail Axis2
has a number of Jiras to fix . So it would be a wise decision if we give
high priority to them than doing drastic changes.
Deepal
>
> thanks,
> Amila.
>
>
>
>
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
--
Thank you!
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Nov 4, 2008 at 8:35 PM, Deepal jayasinghe <de...@gmail.com> wrote:
> Hi Amila ,
> >
> > IMO we need to use different extensions for different type of
> > services. transport should have something like
> > http.tar. I think that is why we use .aar for service archives .mar
> > for modules etc.
> Yes I agree. But if we can have multiple deployer for same extension
> then why not do that , in fact we have that support. So why do you want
> to brake that , what do you achieve from that ?
What I have mentioned below :)
>
> >
> >
> > In the meantime we do not loose anything if we register deployer with
> > extension and the directory , so the key become extension +
> directory.
> >
> >
> > This depends on the people use it. For me what I would like to do is
> > to specify a directory as my root service directory and organize the
> > service files with some directory hierarchy and put the service archives
> > in the directories I need. And for http case it should determine the
> > service path from the directory relative to the root.
> >
> Since I am not a user , I do not know what to tell. But as a developer I
> do not see any problem with the current way. And I think I will be -1 if
> we trying to do major changes to deployment side , the reason is it is
> stable and if you break that we are in a big trouble. And have learn a
> good lesion from braking the deployment .
> > you may ask why you can't specify all those directories in Axis2.xml
> > and declare the extensions which I want to use with those directories.
> > yes it is possible. but for me this is lot of work. if I change a
> > directory name or add a new directory I need to update the Axis2.xml.
> > And also with this way I am not sure how to figure out the http
> > service path from the directory path since there is no any root
> directory.
> Amila , stuff you are talking does not happen regularly. Specially in
> production environment . So changing axis2.xml is not a problem at all.
> And even if you look at stuff like Jboss , Tomcat they have the same
> thing , as long as you go with the default you are fine , if you need
> additional stuff then you got to change configuration file.
As I mentioned earlier this is about how people think about it. So I think
one way and
you think in another way :).
Therefore if more people think that the current way is good enough lets keep
it in that way. If more
people want a change then do it in that way. Since this is a community. :)
thanks,
Amila.
>
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
Hi Amila ,
>
> IMO we need to use different extensions for different type of
> services. transport should have something like
> http.tar. I think that is why we use .aar for service archives .mar
> for modules etc.
Yes I agree. But if we can have multiple deployer for same extension
then why not do that , in fact we have that support. So why do you want
to brake that , what do you achieve from that ?
>
>
> In the meantime we do not loose anything if we register deployer with
> extension and the directory , so the key become extension + directory.
>
>
> This depends on the people use it. For me what I would like to do is
> to specify a directory as my root service directory and organize the
> service files with some directory hierarchy and put the service archives
> in the directories I need. And for http case it should determine the
> service path from the directory relative to the root.
>
Since I am not a user , I do not know what to tell. But as a developer I
do not see any problem with the current way. And I think I will be -1 if
we trying to do major changes to deployment side , the reason is it is
stable and if you break that we are in a big trouble. And have learn a
good lesion from braking the deployment .
> you may ask why you can't specify all those directories in Axis2.xml
> and declare the extensions which I want to use with those directories.
> yes it is possible. but for me this is lot of work. if I change a
> directory name or add a new directory I need to update the Axis2.xml.
> And also with this way I am not sure how to figure out the http
> service path from the directory path since there is no any root directory.
Amila , stuff you are talking does not happen regularly. Specially in
production environment . So changing axis2.xml is not a problem at all.
And even if you look at stuff like Jboss , Tomcat they have the same
thing , as long as you go with the default you are fine , if you need
additional stuff then you got to change configuration file.
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Nov 4, 2008 at 7:09 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>
> >
> > > In my point of view always deployer should only map to an
> extension.
> > -1 , if you think the POJO deployer it can handle both .class
> > files and
> > .jar files , so are you saying thats a problem. If we have the
> > flexibility and if we doing that for a long time without any problem,
> > then we should continue to keep it as it is.
> >
> > good point. Lets associate many extensions with a deployer as Sanjiva
> > has mentioned.
> > Here the main point I want to tell is that deployer has nothing to do
> > with a directory. For an example POJODeployer deployes either a .class
> > or .jar file. Where is that file is not relevant for that.
> I agree. However the problem is we are limiting some stuff , for example
> at the moment we can deploy POJO and Transport as .jar archive. But if
> you go with this proposal we are limiting some stuff right ?
IMO we need to use different extensions for different type of services.
transport should have something like
http.tar. I think that is why we use .aar for service archives .mar for
modules etc.
>
> In the meantime we do not loose anything if we register deployer with
> extension and the directory , so the key become extension + directory.
This depends on the people use it. For me what I would like to do is to
specify a directory as my root service directory and organize the service
files with some directory hierarchy and put the service archives
in the directories I need. And for http case it should determine the
service path from the directory relative to the root.
you may ask why you can't specify all those directories in Axis2.xml and
declare the extensions which I want to use with those directories. yes it is
possible. but for me this is lot of work. if I change a directory name or
add a new directory I need to update the Axis2.xml. And also with this way I
am not sure how to figure out the http service path from the directory path
since there is no any root directory.
The other advantage is that if we think in this way it is easy to extend
this for other repositories as URL repositories.
thanks,
Amila.
> >
> > As I can see even the repository can be able to configure through
> > Axis2.xml as well.
> >
> > <repository class="<class name>" >
> > <parameter name="" value=""/>
> > <repository>
> >
> > This repository can be a file repository, url repository, WSO2
> > registry repository. Then the repository class can read the files on
> > the repository and ask deployers to deploy them.
> In other world what you are telling is AxisConfigurator , that exactly
> what you are proposing. I mean adding new stuff into it. As I mentioned
> in one of my previous mail , we have support for URL repo and file based
> repo.
> > (Since a deployer has only associated with a set of extensions) But
> > this may have limitations in the way we read the files from different
> > repositories.
> you mean now ?
No.
>
> >
> >
> >
> >
> > > In the above way it can support both expanded and single file
> modes.
> > Hehe , seems like you are not happy with the current way , I do not
> > know whether you know about the deployment mechanism we had before
> the
> > deployer concept , and do you know how much of work JAX-WS people
> > did to
> > deploy their services.
> >
> > Well now you can understand the problem of not having custom deployers
> > at the begining of Axis2. Then custom deployers has introduced as a
> > solution for this. So it is an improvement but not an underestimation
> > of the existing work. This is what currently happen as well. There
> > are requirement even can not be solved by current custom deployers so
> > need to improve it.
> I understand what you mean, But IMO re-writing is not the solution for
> each problem ;-)
> >
> > thanks,
> > Amila.
> >
> > FYI , at Apachecon US 2007 we had a BOF session
> > and their they mentioned what they are doing and the difficulties
> > of the
> > process , so as solution to that problem I introduced the idea of
> > deployer , and whether you agree with me or not , it made the
> > deployment
> > so flexible and more extensible. And I do not see a any issues
> > with that
> > other thane the issue that Jarek mentioned.
> >
> > Thank you!
> > Deepal
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
>
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
>
> > In my point of view always deployer should only map to an extension.
> -1 , if you think the POJO deployer it can handle both .class
> files and
> .jar files , so are you saying thats a problem. If we have the
> flexibility and if we doing that for a long time without any problem,
> then we should continue to keep it as it is.
>
> good point. Lets associate many extensions with a deployer as Sanjiva
> has mentioned.
> Here the main point I want to tell is that deployer has nothing to do
> with a directory. For an example POJODeployer deployes either a .class
> or .jar file. Where is that file is not relevant for that.
I agree. However the problem is we are limiting some stuff , for example
at the moment we can deploy POJO and Transport as .jar archive. But if
you go with this proposal we are limiting some stuff right ?
In the meantime we do not loose anything if we register deployer with
extension and the directory , so the key become extension + directory.
>
> As I can see even the repository can be able to configure through
> Axis2.xml as well.
>
> <repository class="<class name>" >
> <parameter name="" value=""/>
> <repository>
>
> This repository can be a file repository, url repository, WSO2
> registry repository. Then the repository class can read the files on
> the repository and ask deployers to deploy them.
In other world what you are telling is AxisConfigurator , that exactly
what you are proposing. I mean adding new stuff into it. As I mentioned
in one of my previous mail , we have support for URL repo and file based
repo.
> (Since a deployer has only associated with a set of extensions) But
> this may have limitations in the way we read the files from different
> repositories.
you mean now ?
>
>
>
>
> > In the above way it can support both expanded and single file modes.
> Hehe , seems like you are not happy with the current way , I do not
> know whether you know about the deployment mechanism we had before the
> deployer concept , and do you know how much of work JAX-WS people
> did to
> deploy their services.
>
> Well now you can understand the problem of not having custom deployers
> at the begining of Axis2. Then custom deployers has introduced as a
> solution for this. So it is an improvement but not an underestimation
> of the existing work. This is what currently happen as well. There
> are requirement even can not be solved by current custom deployers so
> need to improve it.
I understand what you mean, But IMO re-writing is not the solution for
each problem ;-)
>
> thanks,
> Amila.
>
> FYI , at Apachecon US 2007 we had a BOF session
> and their they mentioned what they are doing and the difficulties
> of the
> process , so as solution to that problem I introduced the idea of
> deployer , and whether you agree with me or not , it made the
> deployment
> so flexible and more extensible. And I do not see a any issues
> with that
> other thane the issue that Jarek mentioned.
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
--
Thank you!
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Amila Suriarachchi <am...@gmail.com>.
On Mon, Nov 3, 2008 at 6:55 PM, Deepal jayasinghe <de...@gmail.com> wrote:
>
> > we can do some thing like that Jboss does. In Jboss if you want to
> > deploy a web application either it should be put as .war file or under
> > a directory of which name ends with .war .
> >
> > i.e in axis2 point of view either it should be bar.aar file or bar.aar
> > directory.
> >
> > In my point of view always deployer should only map to an extension.
> -1 , if you think the POJO deployer it can handle both .class files and
> .jar files , so are you saying thats a problem. If we have the
> flexibility and if we doing that for a long time without any problem,
> then we should continue to keep it as it is.
good point. Lets associate many extensions with a deployer as Sanjiva has
mentioned.
Here the main point I want to tell is that deployer has nothing to do with a
directory. For an example POJODeployer deployes either a .class or .jar
file. Where is that file is not relevant for that.
As I can see even the repository can be able to configure through Axis2.xml
as well.
<repository class="<class name>" >
<parameter name="" value=""/>
<repository>
This repository can be a file repository, url repository, WSO2 registry
repository. Then the repository class can read the files on the repository
and ask deployers to deploy them. (Since a deployer has only associated with
a set of extensions) But this may have limitations in the way we read the
files from different repositories.
> > In the above way it can support both expanded and single file modes.
> Hehe , seems like you are not happy with the current way , I do not
> know whether you know about the deployment mechanism we had before the
> deployer concept , and do you know how much of work JAX-WS people did to
> deploy their services.
Well now you can understand the problem of not having custom deployers at
the begining of Axis2. Then custom deployers has introduced as a solution
for this. So it is an improvement but not an underestimation of the
existing work. This is what currently happen as well. There are requirement
even can not be solved by current custom deployers so need to improve it.
thanks,
Amila.
FYI , at Apachecon US 2007 we had a BOF session
> and their they mentioned what they are doing and the difficulties of the
> process , so as solution to that problem I introduced the idea of
> deployer , and whether you agree with me or not , it made the deployment
> so flexible and more extensible. And I do not see a any issues with that
> other thane the issue that Jarek mentioned.
>
> Thank you!
> Deepal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Multiple deployers in axis2.xml
Posted by Deepal jayasinghe <de...@gmail.com>.
> we can do some thing like that Jboss does. In Jboss if you want to
> deploy a web application either it should be put as .war file or under
> a directory of which name ends with .war .
>
> i.e in axis2 point of view either it should be bar.aar file or bar.aar
> directory.
>
> In my point of view always deployer should only map to an extension.
-1 , if you think the POJO deployer it can handle both .class files and
.jar files , so are you saying thats a problem. If we have the
flexibility and if we doing that for a long time without any problem,
then we should continue to keep it as it is.
> In the above way it can support both expanded and single file modes.
Hehe , seems like you are not happy with the current way , I do not
know whether you know about the deployment mechanism we had before the
deployer concept , and do you know how much of work JAX-WS people did to
deploy their services. FYI , at Apachecon US 2007 we had a BOF session
and their they mentioned what they are doing and the difficulties of the
process , so as solution to that problem I introduced the idea of
deployer , and whether you agree with me or not , it made the deployment
so flexible and more extensible. And I do not see a any issues with that
other thane the issue that Jarek mentioned.
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Amila Suriarachchi wrote:
>
> we can do some thing like that Jboss does. In Jboss if you want to
> deploy a web application either it should be put as .war file or under a
> directory of which name ends with .war .
>
> i.e in axis2 point of view either it should be bar.aar file or bar.aar
> directory.
Sounds good .. I like it; less options and "magic" the better.
> In my point of view always deployer should only map to an extension. In
> the above way it can support both expanded and single file modes.
Yes, but a given deployer can of course support multiple extensions - like
for POJOs support .class and .jar both.
> In Axis2.xml level we should be able to define deployment
> directories.(In most case one is enough).
> These directories can have files with any extension and relevant
> deployer can be used to deploy these files. In http case service path is
> determined relative to this directory.
+1.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Amila Suriarachchi <am...@gmail.com>.
On Mon, Nov 3, 2008 at 8:53 AM, Sanjiva Weerawarana
<sa...@opensource.lk>wrote:
> Hi Jarek,
>
> Hmmm .. good question. I've actually been thinking for a while that the
> idea of associating a folder to a specific extension was a mistake. To me
> that's very "static" thinking and its much more convenient to allow people
> to use whatever folder hierarchy they want and just put their services
> there, however the service is implemented.
>
> So my ideal scenario is that we allow /services to contain an arbitrary
> directory structure and that in each directory you can have any kind of
> deployable artifact (or more directories). I'd like to see the directory
> hierarchy become the URL path of the service (at least for HTTP; other
> transports can define their own mapping). So if you have:
>
> /services
> /foo
> /bar.aar
> /baz/
> services.xml
> other stuff
> /bar
> /a.aar
> /b.js
>
> etc. then you'd have all the following services:
> /foo/bar
> /foo/baz
> /bar/a
> /bar/b
>
> [Keith- will this cause an issue in the REST stuff? I don't think so
> because basically the hierarchy is fixed and all the path and query
> variation will come after the path that was followed to resolve the service.
> I think that's similar to how things work in servlet/cgi land- the maximum
> possible path is used to find the servlet and the rest is given to the
> servlet as extra path info.]
>
> I think it'll be ok to say that if someone wants to put a .zip file
> somewhere and consider that a BPEL service (which is what we (WSO2) do in
> the hosting of BPEL/Ode processes as services IIRC). That is, it should be
> possible to say that a particular folder (structure) + extension combination
> can map to a particular service deployer. However that should not be the
> only way- I'd like the config to say something like
>
> extension a ==> deployer b
> directory m ==> deployer n
> directory x extension y ==> deployer z
>
> And you're allowed to have any number of either kind, but the order
> matters: most specific wins first and the later ones win over newer ones. So
> if you have a directory+extension combination then only that extension is
> supported in that directory. If you have a directory x specification then
> only that deployer is on for that directory etc..
>
> Example:
>
> directory /services extension aar ==> deployer POJODeployer
> directory /scripts extension js ==> deployer JSDeployer
> directory /dataservices extension ds ==> deployer DSDeployer
> extension py ==> deployer JythonDeployer
>
> Then that means that /services/*.aar get deployed using the POJODeployer,
> /scripts/*.js using the JSDeployer and /dataservices/*.ds using the
> DSDeployer. If it finds a .py file anywhere except in /services, /scripts or
> /dataservices then the JythonDeployer gets called.
>
> However, it does not say what happens to /services/*.zip for example as no
> instructions are provided.
>
> We can add:
>
> directory /services ==> deployer OtherServiceDeployer
>
> which would mean that any other files I find in the /services directory
> will be handed to OtherServiceDeployer for deployment.
>
> What about sub-directories and supported expanded aar deployment. I suggest
> that if a directory contains a services.xml file we consider that a service
> directory, otherwise we assume its a directory of services and treat each
> file and directory per the deployment rules specified.
we can do some thing like that Jboss does. In Jboss if you want to deploy a
web application either it should be put as .war file or under a directory of
which name ends with .war .
i.e in axis2 point of view either it should be bar.aar file or bar.aar
directory.
In my point of view always deployer should only map to an extension. In the
above way it can support both expanded and single file modes.
In Axis2.xml level we should be able to define deployment directories.(In
most case one is enough).
These directories can have files with any extension and relevant deployer
can be used to deploy these files. In http case service path is determined
relative to this directory.
thanks,
Amila.
>
> What do you think? If you think we can pursue this path I can write up a
> more precise description ..
>
> Sanjiva.
>
>
> Jarek Gawor wrote:
>
>> Hey,
>>
>> I've been working on this problem and ran into some issues and would
>> like to get your comments before committing a fix. The
>> RepositoryListener.findServicesInDirectory() scans the "services"
>> directory and tries to deploy service modules (.jar or .aar files)
>> using ServiceDeployer. But also, when it files files with other
>> extensions it tries to deploy them too using a Deployer registered for
>> the given extension. For example, if you have the following deployer
>> entry in the axis2.xml:
>>
>> <deployer extension=".svc" directory="widgets"
>> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>>
>> The CustomDeployer will be used to deploy files with .svc extension in
>> the "widgets" directory AND the "services" directory. That's a bit
>> weird, IMHO.
>>
>> So, what I'm proposing is to remove the entire 'else' statement at
>> line 303 on RepositoryListener.findServicesInDirectory() so that only
>> service modules (.jar or .aar files) can be deployed from within the
>> services directory. This solution might break some existing
>> deployments where people put non-service module files under the
>> services directory but that can be easily fixed by either moving the
>> files to the right directory or by adding another deployer entry in
>> axis2.xml for the services directory. For example:
>>
>> <deployer extension=".svc" directory="widgets"
>> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>> <deployer extension=".svc" directory="services"
>> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>>
>> Thoughts?
>>
>> Jarek
>>
>> On Tue, Oct 28, 2008 at 5:20 PM, Jarek Gawor <jg...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Does anyone have comments on
>>> https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would
>>> like to know if we should allow for multiple deployers to be
>>> registered for the same file extension (for any directory). Right now,
>>> only one is assumed and that causes problems.
>>>
>>> Thanks,
>>> Jarek
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Multiple deployers in axis2.xml
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Jarek,
Hmmm .. good question. I've actually been thinking for a while that the
idea of associating a folder to a specific extension was a mistake. To me
that's very "static" thinking and its much more convenient to allow people
to use whatever folder hierarchy they want and just put their services
there, however the service is implemented.
So my ideal scenario is that we allow /services to contain an arbitrary
directory structure and that in each directory you can have any kind of
deployable artifact (or more directories). I'd like to see the directory
hierarchy become the URL path of the service (at least for HTTP; other
transports can define their own mapping). So if you have:
/services
/foo
/bar.aar
/baz/
services.xml
other stuff
/bar
/a.aar
/b.js
etc. then you'd have all the following services:
/foo/bar
/foo/baz
/bar/a
/bar/b
[Keith- will this cause an issue in the REST stuff? I don't think so
because basically the hierarchy is fixed and all the path and query
variation will come after the path that was followed to resolve the
service. I think that's similar to how things work in servlet/cgi land-
the maximum possible path is used to find the servlet and the rest is
given to the servlet as extra path info.]
I think it'll be ok to say that if someone wants to put a .zip file
somewhere and consider that a BPEL service (which is what we (WSO2) do in
the hosting of BPEL/Ode processes as services IIRC). That is, it should be
possible to say that a particular folder (structure) + extension
combination can map to a particular service deployer. However that should
not be the only way- I'd like the config to say something like
extension a ==> deployer b
directory m ==> deployer n
directory x extension y ==> deployer z
And you're allowed to have any number of either kind, but the order
matters: most specific wins first and the later ones win over newer ones.
So if you have a directory+extension combination then only that extension
is supported in that directory. If you have a directory x specification
then only that deployer is on for that directory etc..
Example:
directory /services extension aar ==> deployer POJODeployer
directory /scripts extension js ==> deployer JSDeployer
directory /dataservices extension ds ==> deployer DSDeployer
extension py ==> deployer JythonDeployer
Then that means that /services/*.aar get deployed using the POJODeployer,
/scripts/*.js using the JSDeployer and /dataservices/*.ds using the
DSDeployer. If it finds a .py file anywhere except in /services, /scripts
or /dataservices then the JythonDeployer gets called.
However, it does not say what happens to /services/*.zip for example as no
instructions are provided.
We can add:
directory /services ==> deployer OtherServiceDeployer
which would mean that any other files I find in the /services directory
will be handed to OtherServiceDeployer for deployment.
What about sub-directories and supported expanded aar deployment. I
suggest that if a directory contains a services.xml file we consider that
a service directory, otherwise we assume its a directory of services and
treat each file and directory per the deployment rules specified.
What do you think? If you think we can pursue this path I can write up a
more precise description ..
Sanjiva.
Jarek Gawor wrote:
> Hey,
>
> I've been working on this problem and ran into some issues and would
> like to get your comments before committing a fix. The
> RepositoryListener.findServicesInDirectory() scans the "services"
> directory and tries to deploy service modules (.jar or .aar files)
> using ServiceDeployer. But also, when it files files with other
> extensions it tries to deploy them too using a Deployer registered for
> the given extension. For example, if you have the following deployer
> entry in the axis2.xml:
>
> <deployer extension=".svc" directory="widgets"
> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>
> The CustomDeployer will be used to deploy files with .svc extension in
> the "widgets" directory AND the "services" directory. That's a bit
> weird, IMHO.
>
> So, what I'm proposing is to remove the entire 'else' statement at
> line 303 on RepositoryListener.findServicesInDirectory() so that only
> service modules (.jar or .aar files) can be deployed from within the
> services directory. This solution might break some existing
> deployments where people put non-service module files under the
> services directory but that can be easily fixed by either moving the
> files to the right directory or by adding another deployer entry in
> axis2.xml for the services directory. For example:
>
> <deployer extension=".svc" directory="widgets"
> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
> <deployer extension=".svc" directory="services"
> class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
>
> Thoughts?
>
> Jarek
>
> On Tue, Oct 28, 2008 at 5:20 PM, Jarek Gawor <jg...@gmail.com> wrote:
>> Hi,
>>
>> Does anyone have comments on
>> https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would
>> like to know if we should allow for multiple deployers to be
>> registered for the same file extension (for any directory). Right now,
>> only one is assumed and that causes problems.
>>
>> Thanks,
>> Jarek
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Multiple deployers in axis2.xml
Posted by Jarek Gawor <jg...@gmail.com>.
Hey,
I've been working on this problem and ran into some issues and would
like to get your comments before committing a fix. The
RepositoryListener.findServicesInDirectory() scans the "services"
directory and tries to deploy service modules (.jar or .aar files)
using ServiceDeployer. But also, when it files files with other
extensions it tries to deploy them too using a Deployer registered for
the given extension. For example, if you have the following deployer
entry in the axis2.xml:
<deployer extension=".svc" directory="widgets"
class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
The CustomDeployer will be used to deploy files with .svc extension in
the "widgets" directory AND the "services" directory. That's a bit
weird, IMHO.
So, what I'm proposing is to remove the entire 'else' statement at
line 303 on RepositoryListener.findServicesInDirectory() so that only
service modules (.jar or .aar files) can be deployed from within the
services directory. This solution might break some existing
deployments where people put non-service module files under the
services directory but that can be easily fixed by either moving the
files to the right directory or by adding another deployer entry in
axis2.xml for the services directory. For example:
<deployer extension=".svc" directory="widgets"
class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
<deployer extension=".svc" directory="services"
class="org.apache.axis2.deployment.deployers.CustomDeployer"/>
Thoughts?
Jarek
On Tue, Oct 28, 2008 at 5:20 PM, Jarek Gawor <jg...@gmail.com> wrote:
> Hi,
>
> Does anyone have comments on
> https://issues.apache.org/jira/browse/AXIS2-4101? In general, I would
> like to know if we should allow for multiple deployers to be
> registered for the same file extension (for any directory). Right now,
> only one is assumed and that causes problems.
>
> Thanks,
> Jarek
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org