On Mon, Feb 17, 2014 at 7:42 PM, Kasun Gajasinghe kas...@wso2.com wrote:
Hi,
It seems that Tomcat now supports the unpackWARs=true attribute for
unpacking wars outside the Host's appBase. So, in the context of AS, the
webapps deployed to tenants too will be unpacked by default. In the Tomcat
On Mon, Feb 17, 2014 at 8:06 PM, Geeth Munasinghe ge...@wso2.com wrote:
Hi
Following components in carbon-commons get dependencies from other
projects as follows.
- application-deployers/org.wso2.carbon.application.deployer.synapse
- org.wso2.carbon.mediation.initializer
Hi
Following components in carbon-commons get dependencies from other projects
as follows.
- application-deployers/org.wso2.carbon.application.deployer.synapse
- org.wso2.carbon.mediation.initializer -
carbon-mediation
- org.wso2.carbon.mediation.registry
+1 useful for jaggery as well.
Regards,
/Nuwan
On Mon, Feb 17, 2014 at 9:19 AM, Sagara Gunathunga sag...@wso2.com wrote:
On Mon, Feb 17, 2014 at 7:42 PM, Kasun Gajasinghe kas...@wso2.com wrote:
Hi,
It seems that Tomcat now supports the unpackWARs=true attribute for
unpacking wars
+1 for the proposal guys. and as chan said if we can use goose for base
stuff lets get that and built on top of that.
Regards,
/Nuwan
On Sun, Feb 16, 2014 at 7:09 AM, Chan duli...@wso2.com wrote:
I would further suggest to merge the simple router to goose.js[1] and
promote a single router as
Guys whats the verdict on this discussion ? Having a patch directory within
the app seems to be a fine idea, which does not effect the platform
patching or raise depsyc complications. Shall we come to a conclusion and
implement this. IMO this is vital to all the products that has jaggery
Hi,
It seems that Tomcat now supports the unpackWARs=true attribute for
unpacking wars outside the Host's appBase. So, in the context of AS, the
webapps deployed to tenants too will be unpacked by default. In the Tomcat
7.0.34 version we used before did not unpack the wars outside the Host's
Hi Chandana,
This looks good. Firstly, when we create the service asset in the store, we
need to think whether it is necessary for everything that you store in the
G-Reg's service asset to be listed here. I know it is useful to have an
asset in the repository that can capture everything, but in
Hi All,
How about adding a link like for example Show Advance Settings to list
all the information and only show the most required fields in the default
view.
Regards,
Pulasthi
On Mon, Feb 17, 2014 at 12:20 PM, Senaka Fernando sen...@wso2.com wrote:
Hi Chandana,
This looks good. Firstly,
Hi All,
In BPS when we directly copy a new zip ( which is identified by the md5sum
of the zip file ) file of an existing BPEL process to
/repository/deployment/server/bpel folder this will be picked up as an new
version of the process and the existing process will be kept as a retired
process (
Guys it would be awesome if you can describe how the patch directory in the
app works (I mean in detail). Then everyone will be clear about it.
Cheers~
On Tue, Feb 18, 2014 at 10:12 AM, Madhuka Udantha madh...@wso2.com wrote:
On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara nu...@wso2.com
Hi Nuwan and all,
If there is a patch which has a dependency to jar file(say a hostobject or
any other carbon bundle changed) which will be used in jaggery application,
In that case, we have a dependency between jaggery patch and usual
patch(patch). How does the dependency resolution works if
Hi Pulasthi,
Are you using the maven-bpel-plugin to build the zip file. It seems like
the plugin is generating a zip file which produces a different md5sum each
time even though the content of the bpel package has not changed at all.
This must be the reason for you issue.
Regards
Nandika
On
Hi,
If we are going with patching directory model, then following are my
initial thoughts.
- We will have a directory named .patches(or a better name) in the app
root
- Patches will have to be copied into that with directories named 0, 1,
2 ... n
- We can either ask them to
14 matches
Mail list logo
