No, that's not the correct bundle. May be a method in CarbonUtil would do
--
Afkham Azeez
Sent from my phone
On Feb 4, 2012 11:49 AM, Nirmal Fernando nir...@wso2.com wrote:
Hi,
On Mon, Jan 30, 2012 at 9:24 AM, Afkham Azeez az...@wso2.com wrote:
Please fix this to do the password
The whole integration module has been commented out it seems.
--
Afkham Azeez
Sent from my phone
On Feb 4, 2012 11:29 AM, Subash Chaturanga sub...@wso2.com wrote:
Hi Senaka
On Sat, Feb 4, 2012 at 2:16 AM, Senaka Fernando sen...@wso2.com wrote:
Hi Subash,
Where are we with the integration
Hi Dimuthu,
For in-memory you need it anyway, but even for Infinispan for example.
That's to maintain references of the Cache itself. We have more than one
named cache in Carbon. For example, one for registry resources, one for UM
etc. This gives better performance, since not everything is
On Sat, Feb 4, 2012 at 2:01 PM, Afkham Azeez az...@wso2.com wrote:
No, that's not the correct bundle. May be a method in CarbonUtil would do
+1. For cross-cutting concerns use CarbonUtil and CarbonUIUtil.
Thanks,
Senaka.
--
Afkham Azeez
Sent from my phone
On Feb 4, 2012 11:49 AM,
Hi Subash,
Please work on this and get this up and running, after your support work.
Thanks,
Senaka.
On Sat, Feb 4, 2012 at 2:04 PM, Afkham Azeez az...@wso2.com wrote:
The whole integration module has been commented out it seems.
--
Afkham Azeez
Sent from my phone
On Feb 4, 2012 11:29
Hi Nirmal,
By design the password length of Carbon platform is configurable. Please
have a look at user-mgt.xml
Property name=PasswordJavaScriptRegEx[\\S]{5,30}/Property
Since Java and JS use slightly different ways for expressing regular
expressions there should be another attribute in
Hi Dimuthu,
On Sat, Feb 4, 2012 at 2:40 PM, Dimuthu Leelarathne dimut...@wso2.comwrote:
Hi Nirmal,
By design the password length of Carbon platform is configurable. Please
have a look at user-mgt.xml
Property name=PasswordJavaScriptRegEx[\\S]{5,30}/Property
Since Java and JS use
On Sat, Feb 4, 2012 at 2:37 PM, Senaka Fernando sen...@wso2.com wrote:
On Sat, Feb 4, 2012 at 2:01 PM, Afkham Azeez az...@wso2.com wrote:
No, that's not the correct bundle. May be a method in CarbonUtil would do
+1. For cross-cutting concerns use CarbonUtil and CarbonUIUtil.
Thanks,
Hi Nirmal,
One more thing. You cannot add a dependency of CarbonUtils to User.Core, it
will create a cyclic dependency. So I would look at adding it to
UserCoreUtil and CarbonUIUtil.
thanks,
dimuthu
On Sat, Feb 4, 2012 at 2:55 PM, Nirmal Fernando nir...@wso2.com wrote:
On Sat, Feb 4, 2012
*Objective*:
Make Carbon core a top level project in WSO2 trunk. At the moment complete
Carbon platform code lies under
https://svn.wso2.org/repos/wso2/trunk/carbon/. This structure has its own
problems.
*Motivations*:
1) Carbon core can be treated as a separate product which has its own
+1
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Hi all,
I think we can focus on further reducing logs at start-up. For example, I'm
getting these logs when starting the ESB 4.0.3. I'm just taking this as an
example, but the same applies to other products as well.
[2012-02-04 17:35:43,674] INFO - InputOutputAdaptersComponent There is no
Hi Nirmal, Dimuthu,
In that case add it to CarbonBaseUtils in carbon.base.
The reason for introducing carbon.base is to exactly address the problem
you are expressing, where utils actually depends on some low-level bundles
in carbon, and therefore can't be used by lower-layer bundles such as
Hi Sameera, Pradeep,
+1, but X should probably be a name of a derivative/allotrope of Carbon
(like Diamond or Graphite) which makes our code names more meaningful.
I really like the idea of having two-levels of dependencies and orbits very
much, which simplifies the effort of doing a carbon
On Sat, Feb 4, 2012 at 2:39 PM, Senaka Fernando sen...@wso2.com wrote:
Hi Subash,
Please work on this and get this up and running, after your support work.
Sure, will do
Thanks,
Senaka.
On Sat, Feb 4, 2012 at 2:04 PM, Afkham Azeez az...@wso2.com wrote:
The whole integration module
Hi Senaka,
On Sat, Feb 4, 2012 at 5:50 PM, Senaka Fernando sen...@wso2.com wrote:
Hi Nirmal, Dimuthu,
In that case add it to CarbonBaseUtils in carbon.base.
Will use it then, thanks!
The reason for introducing carbon.base is to exactly address the problem
you are expressing, where utils
++1, for the execution
On Sat, Feb 4, 2012 at 5:57 PM, Senaka Fernando sen...@wso2.com wrote:
Hi Sameera, Pradeep,
+1, but X should probably be a name of a derivative/allotrope of Carbon
(like Diamond or Graphite) which makes our code names more meaningful.
I really like the idea of having
Hi all. I´m facing this issue in a scenario using ESB and MB.
The idea is that I send a message to a proxy service, and this proxy send the
message to a topic in MB. this topic send the soap message to their
subscribers.
I have two DS subscriber to the topic in MB.
In
I think first we need to remove the dependencies and orbit from the carbon
structure since they have nothing to do with carbon. Simply they produce a
set of
third party osgi bundles to be used with carbon.
Same thing may be applied to service stubs since they only depend on the
wsdl version. we
Hi Senaka,
+1 for the idea. I also feel that server start-up logs
get lengthier increasingly, So if we do not log some messages or redundant
messages, IMO, the strtup process will look as if its hanging at some
places, since anyway the activities are happening. So maybe we need to
change the way
20 matches
Mail list logo
