+1. We've faced many security issues, due this exposure of internal
packages. One such good example is, never expose your BundleActivator. It
might be keeping references to your BundleContext and the BundleContext
should never be shared with any other bundle.
Sameera
On Fri, Aug 6, 2010 at 8:53
So, as per the suggestions, I have set the fail-safe mode as the default
mode of the ESB(should disable in production env).Also, we can select the
required fail-safe level (i.e. endpoints, proxyservices or both) through the
synapse.properties file.
eg.
#(enabled by default)
I think we need to have this type of security checks in the unit tests that
use CarbonContext. This is one place where malicious code can get into a
running system.
/sumedha
On Sun, Aug 8, 2010 at 5:59 PM, Sameera Jayasoma same...@wso2.com wrote:
+1. We've faced many security issues, due this
There was a typo in the XML header introduced due to license being added. I
fixed it now.
On Sat, Aug 7, 2010 at 10:47 PM, Milinda Pathirage mili...@wso2.com wrote:
Looks to me like same code generation error we had with WSAS samples.
Milinda
On Sat, Aug 7, 2010 at 6:20 PM, Samisa
On Sun, Aug 8, 2010 at 8:21 PM, Kasun Indrasiri ka...@wso2.com wrote:
So, as per the suggestions, I have set the fail-safe mode as the default
mode of the ESB(should disable in production env).Also, we can select the
required fail-safe level (i.e. endpoints, proxyservices or both) through the
This is more about good encapsulation at the component level. The component
author should consciously decide which classes are bundle-local which
should be part of the API provided by the bundle. Having said that, I've
seen a lot of code where attributes that should have private scope, have
been
Please let us know why you are trying to do this.
It is always better to explain the problem first before describing the
solution so that others may be able to give you a better solution.
thanks
Azeez
On Sun, Aug 8, 2010 at 9:57 PM, Amila Jayasekara ami...@wso2.com wrote:
Hi Sameera,
I
This is possible. You need to configure the carbon-p2-plugin properly. I
will let you know how to do that.
Thanks
Sameera
On Mon, Aug 9, 2010 at 10:36 AM, Afkham Azeez az...@wso2.com wrote:
Please let us know why you are trying to do this.
It is always better to explain the problem first
Hi Azeez,
I think this is a valid requirement during a scenario like, we do not ship
a particular feature with any of our products and it's an optional feature
and during the installation of that particular feature we need to put some
configuration files or may be some jar files in to different
On Mon, Aug 9, 2010 at 10:33 AM, Afkham Azeez az...@wso2.com wrote:
This is more about good encapsulation at the component level. The component
author should consciously decide which classes are bundle-local which
should be part of the API provided by the bundle. Having said that, I've
seen
On Mon, Aug 9, 2010 at 12:15 AM, Sumedha Rubasinghe sume...@wso2.comwrote:
I think we need to have this type of security checks in the unit tests that
use CarbonContext. This is one place where malicious code can get into a
running system.
The better way to implement security is to move
I'm not questioning the validity of this scenario. I was wondering why a jar
needs to be placed into CARBON_HOME/lib which is outside the OSGi
environment.
Azeez
On Mon, Aug 9, 2010 at 10:59 AM, Lahiru Gunathilake lah...@wso2.com wrote:
Hi Azeez,
I think this is a valid requirement during a
12 matches
Mail list logo
