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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
