That sounds much better to me.
I've had the same problem with encrypted passwords and i've created a
property placeholder.
It's quite easy to chain the placeholders, so it's slightly more
verbose, but a bit cleaner.
See ENC(${foo}) in he following example:
http://svn.apache.org/repos/asf/karaf/trunk/jaas/jasypt/src/test/resources/org/apache/karaf/jaas/jasypt/handler/test.xml
On Fri, Sep 9, 2011 at 12:36, Alasdair Nottingham <[email protected]> wrote:
> Hi,
>
> I have thought of a possible update we could do that would enable this
> without a new namespace. I'll outline it here. Make a minor update to the
> ext schema (making it 1.2.0) so we can do the following:
>
> <property-placeholder evaluator="jexl">
> <default-properties>
> <property name="name" value="value" />
> </default-properties>
> <location>file:///url</ext:location>
> </property-placeholder>
>
> The namespace handler then inserts a synthetic service dependency on a
> service of type PropertyProcessor with the service property "type=jexl".
> This means the blueprint container would only be configured while the
> desired processor is available. Then we update the code where we do the
> processing to use the PropertyProcessor service instead of having it
> hardcoded.
>
> This solves my issues around correct modularity, your issues around
> programming model simplicity, and it would also allow us to plug other
> processors/evaluators such as groovy in the future very easily.
>
> Thoughts?
> Alasdair
>
> On 9 September 2011 10:39, Timothy Ward <[email protected]> wrote:
>
>>
>> Alasdair,
>>
>> Thanks for taking the time to write a test that answers my question. I had
>> a suspicion that this sort of thing would happen. It needs to be possible
>> for the blueprint bundle to behave consistently whether JEXL is installed or
>> not.
>>
>> Regards,
>>
>> Tim
>>
>> > Date: Thu, 8 Sep 2011 23:26:18 +0100
>> > Subject: Re: [Release Discussion] ship maintenance releases of
>> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> > From: [email protected]
>> > To: [email protected]
>> >
>> > Hi,
>> >
>> > So lets get real with an example to start illustrating my issues. We have
>> a
>> > release already and the release is used by people, quite a few people. We
>> > don't know what they are doing. I have written a test. The test uses the
>> > sample blueprint bundle. It contains the following blueprint xml:
>> >
>> > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
>> >
>> > <property name="value" value="${a+b}"/>
>> >
>> > </bean>
>> >
>> > The setValue method takes a String. I have run these tests in two ways.
>> The
>> > first with jexl and the second without. If jexl isn't installed I get:
>> >
>> > ${a+b}
>> >
>> > when jexl is installed I get:
>> >
>> > 0
>> >
>> > Irrespective of how useful this is to people who want the behaviour it is
>> a
>> > huge problem for those people who do NOT want this behaviour. It is easy
>> to
>> > say "well don't install jexl then", but consider this. I have written a
>> > blueprint bundle that expects to have ${a+b} injected. I deploy it in
>> one
>> > runtime and it works the way I expect. Now I drop it into Geronimo and I
>> get
>> > 0 instead. So I now need to go back and rewrite my bundle to work in
>> > geronimo and I have two different bundles for each environment. This is
>> > wrong.
>> >
>> > As said before I think we need this enabled via a namespace handler and
>> an
>> > attribute. I would require the following to be added to the blueprint
>> > element:
>> >
>> > <blueprint jexl:enable="true" xmlns:jexl="
>> > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
>> >
>> > any existing application will then behave consistently irrespective of
>> what
>> > is installed in the surrounding framework. Even the one I just created.
>> If
>> > the jexl bundle isn't installed then the jexl namespace handler is not
>> > installed so the blueprint bundle will not be processed until it is in
>> the
>> > normal way. The code in question can remain where it is, but it would
>> only
>> > be enabled if the jexl namespace is configured. Ideally we would be able
>> to
>> > parameterise the value processing in a pluggable way, but as long as the
>> > externals are right we can refactor the internals at our leisure.
>> >
>> > We are creating a programming model for OSGi here and that means we need
>> to
>> > get the modularity right. Currently it is not right, not only is the
>> > modularity wrong but this makes a breaking change to the way a
>> blueprint.xml
>> > is processed in what is a bug release. Irrespective of how useful this is
>> I
>> > do not think it is important enough to warrant a breaking change when we
>> can
>> > make it work without breaking existing bundles.
>> >
>> > To address your question of "Do you think it is a good idea to support
>> > this?" I do think it is a good idea, if I didn't I would have -1ed the
>> > commit rather than engaged in an email discussion to get it right.
>> >
>> > Thanks
>> > Alasdair
>> >
>> > On 8 September 2011 14:35, Rex Wang <[email protected]> wrote:
>> >
>> > > 2011/9/8 Alasdair Nottingham <[email protected]>
>> > >
>> > > > On 8 September 2011 10:10, Rex Wang <[email protected]> wrote:
>> > > >
>> > > > > 2011/9/8 Timothy Ward <[email protected]>
>> > > > >
>> > > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > I'm afraid I've not been paying as much attention as I should to
>> this
>> > > > > > thread. Reading back over the issues. I would currently vote -1
>> on
>> > > this
>> > > > > > release. I am not at all happy with the fact that users of this
>> > > support
>> > > > > will
>> > > > > > see different, potentially erroneous, behaviour depending on the
>> > > > presence
>> > > > > or
>> > > > > > absence of an optional dependency. Our previous statement has
>> always
>> > > > been
>> > > > > > "If a blueprint bundle wants to use some non-standard function it
>> > > > should
>> > > > > > declare that using an additional namespace".
>> > > > > >
>> > > > > Do you mean the statement in spec 121.4:
>> > > > > "The Blueprint XML resources in a bundle are the definitions. Each
>> > > > > definition can include multiple
>> > > > > namespaces. Implementations of the Blueprint core namespace must
>> > > strictly
>> > > > > follow this specification,
>> > > > > if they add additional behavior they must add additional namespaces
>> > > that
>> > > > > are
>> > > > > actually used in
>> > > > > the definitions to signal the deviation from this specification."?
>> > > > >
>> > > > > We are improving the blueprint-ext, which has been already an
>> > > additional
>> > > > > namespace to blueprint core schema. Why must we add a new namespace
>> to
>> > > > > extend the ability of blueprint-ext?
>> > > > >
>> > > > >
>> > > > Blueprint ext is a part of our core implementation. Adding it to
>> > > > blueprint-ext means that if you want to use ANY part of blueprint ext
>> you
>> > > > MUST have apache-jexl even if you don't wan to use the ${a+b} syntax.
>> > > This
>> > > > is wrong.
>> > > >
>> > >
>> > > Hi Alasdair,
>> > > The itests passes without adding the commons-jexl bundle now.
>> > > If you don't have commons-jexl installed, the current code can work as
>> > > before. Unless you want to use ${a+b}, you need guarantee the
>> commons-jexl
>> > > is present. Otherwise it will record this exception in logger. I know
>> this
>> > > is not that convenient, but at least user can know what he need to do
>> to
>> > > get
>> > > things right from the log..
>> > >
>> > > On the other hand, Java EE EL supports such style of calculation
>> natively,
>> > > I
>> > > think we should support it in blueprint-ext directly to keep the
>> consistent
>> > > of the current development experiences. In other words, if we don't use
>> > > commons-jexl to implement such ability, instead, we write codes by
>> > > ourselves
>> > > to do that. Do you think it is a good idea to support this? After all,
>> > > there
>> > > is no spec for blueprint-ext.
>> > >
>> > > thanks,
>> > > -Rex
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > >
>> > > > >
>> > > > > > In my view this new function should only be available if the
>> optional
>> > > > > > dependency is satisfied, and blueprint bundles must enable this
>> > > > function
>> > > > > > using a custom namespace. Otherwise I see two problems.
>> > > > > >
>> > > > > >
>> > > > > > I want this new support, but have no way to ensure it is present,
>> as
>> > > a
>> > > > > > result I am sometimes injected with "1+2" instead of "3". This
>> leads
>> > > to
>> > > > > > intermittent NumberFormatExceptions
>> > > > > >
>> > > > > I do not want this new support, but as the dependency is available
>> I
>> > > am
>> > > > > > injected with "3" instead of "1+2". This leads to inconsistent
>> and
>> > > > > confusing
>> > > > > > behaviour.
>> > > > > >
>> > > > > I am not sure I understand this..
>> > > > > If you want 3, you need <xxx value="${1+2}">
>> > > > > If you want 1+2, you should use <xxx value="1+2">
>> > > > > Only the expression in ${..} will trigger the calculation, no
>> matter if
>> > > > the
>> > > > > dependency if available.
>> > > > >
>> > > > >
>> > > > I think tim is saying you want the string literal "${1+2}" not the
>> string
>> > > > 1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}.
>> > > This
>> > > > is a change in behaviour and should be enabled using a new namespace.
>> Of
>> > > > course you could just reversion the namespace from v1.x to v2 as a
>> > > breaking
>> > > > change, but we would need to support both versions of the schema.
>> > > >
>> > > > As with Tim I would currently -1 any release of blueprint 3.2 until
>> this
>> > > is
>> > > > addressed.
>> > > >
>> > > > Alasdair
>> > > >
>> > > > -Rex
>> > > > >
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > Adding a namespace for this function elegantly solves both these
>> > > issues
>> > > > > in
>> > > > > > a way that is consistent with other blueprint extensions, and I
>> think
>> > > > is
>> > > > > > essential before this function can be released.
>> > > > > >
>> > > > > > Regards,
>> > > > > >
>> > > > > > Tim
>> > > > > >
>> > > > > >
>> > > > > > > From: [email protected]
>> > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
>> > > > > > > Subject: Re: [Release Discussion] ship maintenance releases of
>> > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> > > > > > > To: [email protected]
>> > > > > > >
>> > > > > > > I still think adding a new namespace only for such simple
>> > > calculation
>> > > > > is
>> > > > > > too
>> > > > > > > heavy and not consumalbe for users..
>> > > > > > >
>> > > > > > > Anyway, could anybody help with the release of *
>> > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
>> > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone
>> help
>> > > > > check
>> > > > > > why
>> > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
>> > > > release
>> > > > > > the 2
>> > > > > > > components. Geronimo does not have much time targeting the
>> 3.0-beta
>> > > > > > release.
>> > > > > > >
>> > > > > > > thanks,
>> > > > > > >
>> > > > > > > -Rex
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > 2011/9/7 Alasdair Nottingham <[email protected]>
>> > > > > > >
>> > > > > > > > If we release blueprint as is we will never be able to make
>> the
>> > > > > change
>> > > > > > as
>> > > > > > > > we
>> > > > > > > > would cause a major breaking change. I think we need to get
>> this
>> > > > > right
>> > > > > > > > before a release is done.
>> > > > > > > >
>> > > > > > > > On 6 September 2011 04:37, Rex Wang <[email protected]>
>> wrote:
>> > > > > > > >
>> > > > > > > > > 2011/9/6 Alasdair Nottingham <[email protected]>
>> > > > > > > > >
>> > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
>> > > > > > [email protected]
>> > > > > > > > > > >wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Comments inline :)
>> > > > > > > > > > >
>> > > > > > > > > > > Kind regards,
>> > > > > > > > > > >
>> > > > > > > > > > > Valentin
>> > > > > > > > > > >
>> > > > > > > > > > > On 31 Aug 2011, at 20:02, Alasdair Nottingham wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > > I'm sorry for being slow I'm on holiday with limited
>> > > access
>> > > > > to
>> > > > > > > > email.
>> > > > > > > > > > > >
>> > > > > > > > > > > > The goal (I thought) was to ensure that the support
>> for
>> > > > > ${a+b}
>> > > > > > > > would
>> > > > > > > > > be
>> > > > > > > > > > > > optional. When we make it optional we have two
>> problems:
>> > > > > > > > > > > >
>> > > > > > > > > > > > 1. How do we make it optional (usually gate any
>> call
>> > > with
>> > > > a
>> > > > > > > > > > > > Class.forName check to ensures we can load a
>> class.
>> > > > > > > > > > > > 2. How do we fail when the support isn't there and
>> > > > someone
>> > > > > is
>> > > > > > > > using
>> > > > > > > > > > it.
>> > > > > > > > > > > >
>> > > > > > > > > > > > The first problem is trivial to fix, the latter is
>> harder
>> > > > to
>> > > > > > > > define.
>> > > > > > > > > It
>> > > > > > > > > > > > isn't until you build the bean that you find the
>> ${a+b}
>> > > > > doesn't
>> > > > > > > > work
>> > > > > > > > > > and
>> > > > > > > > > > > > with lazy activation that could take a while. I would
>> > > > suggest
>> > > > > > that
>> > > > > > > > if
>> > > > > > > > > > we
>> > > > > > > > > > > > have ${a+b} in use, and the apache-jexl bundle is not
>> > > > > present,
>> > > > > > then
>> > > > > > > > > the
>> > > > > > > > > > > bean
>> > > > > > > > > > > > creation would most likely fail (or you would get the
>> > > wrong
>> > > > > > > > > behaviour).
>> > > > > > > > > > > This
>> > > > > > > > > > > > is obviously not desirable.
>> > > > > > > > > > > >
>> > > > > > > > > > > > An alternative would be to make use of the default
>> > > > behaviour
>> > > > > of
>> > > > > > > > > > blueprint
>> > > > > > > > > > > > for namespace extensions. By using a separate
>> namespace
>> > > to
>> > > > > > indicate
>> > > > > > > > > the
>> > > > > > > > > > > > desire to use this behaviour blueprint will delay
>> > > > > > initialisation of
>> > > > > > > > a
>> > > > > > > > > > > > bundle's blueprint container until the namespace is
>> > > > > available.
>> > > > > > The
>> > > > > > > > > > result
>> > > > > > > > > > > > would be if apache-jexl is not present the namespace
>> > > > handler
>> > > > > > would
>> > > > > > > > > not
>> > > > > > > > > > be
>> > > > > > > > > > > > registered and the blueprint container would not be
>> > > > > configured.
>> > > > > > In
>> > > > > > > > > > > addition
>> > > > > > > > > > > > you can now register the namesake when apache-jexl
>> > > becomes
>> > > > > > > > available
>> > > > > > > > > > > > allowing it to be brought up later.
>> > > > > > > > > > >
>> > > > > > > > > > > I think that this definitely the right way to go. In
>> > > > practical
>> > > > > > terms
>> > > > > > > > > > though
>> > > > > > > > > > > it might be quite a bit tricky to implement.
>> > > > > > > > > > > In particular I am wondering how to link the usage of
>> the
>> > > > > > extended
>> > > > > > > > > > property
>> > > > > > > > > > > replacement syntax to a namespace reference. I can
>> think of
>> > > > > > > > > > > the following ways to do this:
>> > > > > > > > > > >
>> > > > > > > > > > > a) Have two different property placeholder brackets
>> like
>> > > > > ${...}
>> > > > > > for
>> > > > > > > > > the
>> > > > > > > > > > > non-arithmetic one and $[...] for the one doing
>> arithmetic.
>> > > > The
>> > > > > > > > second
>> > > > > > > > > > > one is defined via a tag from the new namespace.
>> > > > > > > > > > > b) Support property placeholders only if we can support
>> the
>> > > > > whole
>> > > > > > > > > shebang
>> > > > > > > > > > > (which is kind of step back?)
>> > > > > > > > > > > c) Have a kind of unrelated namespace import which we
>> check
>> > > > for
>> > > > > > when
>> > > > > > > > we
>> > > > > > > > > > > decide whether to do arithmetic (that could be quite
>> > > > > non-obvious
>> > > > > > to
>> > > > > > > > the
>> > > > > > > > > > > user).
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > The blueprint specification says any non-standard
>> extensions
>> > > to
>> > > > > > > > blueprint
>> > > > > > > > > > must be enabled via namespace handlers. I don't like the
>> ext
>> > > of
>> > > > > cm
>> > > > > > > > > > namespaces to require apache-jexl since it means more
>> > > > > dependencies
>> > > > > > are
>> > > > > > > > > > pulled in when they may never be used.
>> > > > > > > > > >
>> > > > > > > > > Hi Alasdair,
>> > > > > > > > > Since the current code does not hard depend on the
>> > > commons-jexl,
>> > > > > and
>> > > > > > I
>> > > > > > > > > think
>> > > > > > > > > the only difference from your desire is adding a new
>> namespace
>> > > > > which
>> > > > > > can
>> > > > > > > > > delay the blueprint container initialization if the
>> > > commons-jexl
>> > > > is
>> > > > > > not
>> > > > > > > > > present,
>> > > > > > > > > I consider this as an improvement to the current solution.
>> And
>> > > I
>> > > > > > think it
>> > > > > > > > > would be better to let user hold the option that if he
>> would
>> > > use
>> > > > > the
>> > > > > > new
>> > > > > > > > > namespace, and if he don't use it, the ${a+b} can still
>> work.
>> > > > Hope
>> > > > > > the
>> > > > > > > > > current solution meets the criteria to start release..
>> > > > > > > > >
>> > > > > > > > > BTW, seems Aries community is not that active in last two
>> > > month.
>> > > > Is
>> > > > > > there
>> > > > > > > > > still a release manager help the release works?
>> > > > > > > > >
>> > > > > > > > > -Rex
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Looking at your options a) doesn't work because it isn't
>> > > using
>> > > > > > > > namespace
>> > > > > > > > > > handlers, b) sucks big time and would mean to meat the
>> spec
>> > > we
>> > > > > > would
>> > > > > > > > > need
>> > > > > > > > > > apache-jexl and the whole point is to allow the spec to
>> be
>> > > > > > implemented
>> > > > > > > > > > without apache-jexl being required. So I think something
>> > > like
>> > > > > > option c
>> > > > > > > > > > should be gone for. For instance you could add an
>> attribute
>> > > in
>> > > > a
>> > > > > > > > > > non-standard namespace that says to enable this
>> capability.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > > Is any of that what you were thinking of?
>> > > > > > > > > > >
>> > > > > > > > > > > > Does that make any sense?
>> > > > > > > > > > > >
>> > > > > > > > > > > > Alasdair
>> > > > > > > > > > > >
>> > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <[email protected]>
>> > > > wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > >> Sorry, I will add the corresponding tests. But I am
>> not
>> > > > > quite
>> > > > > > > > > > > understanding
>> > > > > > > > > > > >> your suggestion in Aries-727 of "use a different
>> > > > namespace
>> > > > > to
>> > > > > > the
>> > > > > > > > > ext
>> > > > > > > > > > > >> one". The current implement add the ability to
>> > > > > blueprint-ext
>> > > > > > and
>> > > > > > > > > also
>> > > > > > > > > > > >> blueprint-cm, because the CmPropertyPlaceholder is
>> the
>> > > > > > subclass of
>> > > > > > > > > the
>> > > > > > > > > > > >> PropertyPlaceholder. Could a different namespace
>> handle
>> > > > > this?
>> > > > > > > > > > > >> After the change is final, will definitely port it
>> to
>> > > the
>> > > > > > trunk.
>> > > > > > > > > > > >>
>> > > > > > > > > > > >> thanks,
>> > > > > > > > > > > >> -Rex
>> > > > > > > > > > > >>
>> > > > > > > > > > > >> 2011/8/30 Alasdair Nottingham <[email protected]>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >>> Hi,
>> > > > > > > > > > > >>>
>> > > > > > > > > > > >>> I'm not happy with the current fix for ARIES-727.
>> There
>> > > > are
>> > > > > > no
>> > > > > > > > > tests
>> > > > > > > > > > > and
>> > > > > > > > > > > >> as
>> > > > > > > > > > > >>> I commented on the bug the dependency on jexl is
>> not
>> > > > > optional
>> > > > > > > > when
>> > > > > > > > > it
>> > > > > > > > > > > >> should
>> > > > > > > > > > > >>> be. It also doesn't exist in trunk which is
>> dangerous.
>> > > > This
>> > > > > > > > affects
>> > > > > > > > > > the
>> > > > > > > > > > > >>> programming model so it needs to be right.
>> > > > > > > > > > > >>>
>> > > > > > > > > > > >>> Alasdair Nottingham
>> > > > > > > > > > > >>>
>> > > > > > > > > > > >>> On 29 Aug 2011, at 23:17, Rex Wang <
>> [email protected]>
>> > > > > wrote:
>> > > > > > > > > > > >>>
>> > > > > > > > > > > >>>> Hi Devs,
>> > > > > > > > > > > >>>>
>> > > > > > > > > > > >>>> Geronimo 3.0-beta has passed the Java EE 6 full
>> > > profile
>> > > > > tck,
>> > > > > > and
>> > > > > > > > > is
>> > > > > > > > > > > >>> going
>> > > > > > > > > > > >>>> to release soon. But some dependencies are from
>> Aries
>> > > > > > project,
>> > > > > > > > so
>> > > > > > > > > we
>> > > > > > > > > > > >> are
>> > > > > > > > > > > >>>> requesting your supports to release the following
>> 3
>> > > > > > components
>> > > > > > > > > with
>> > > > > > > > > > > the
>> > > > > > > > > > > >>>> important fixes to our users. Could anybody please
>> > > help?
>> > > > > > > > > > > >>>>
>> > > > > > > > > > > >>>> *1. **org.apache.aries.application/0.2.2-SNAPSHOT*
>> > > > > > > > > > > >>>> ARIES-521: handles zip files without directory
>> entries
>> > > > > > > > > > > >>>> ARIES-635: Move the resource bundle to the right
>> > > > directory
>> > > > > > > > > > > >>>> ARIES-638: Logging improvements for
>> > > > > > AriesApplicationManagerImpl
>> > > > > > > > > > > >>>> ARIES-667: OBRAriesResolver can return bundle
>> > > > information
>> > > > > > for
>> > > > > > > > > > bundles
>> > > > > > > > > > > >>> with
>> > > > > > > > > > > >>>> higher version than expected
>> > > > > > > > > > > >>>> ARIES-689: Application OBR resolution fails for
>> > > optional
>> > > > > > imports
>> > > > > > > > > > > >>>> ARIES-734: Back port improvements made to
>> resolution
>> > > > error
>> > > > > > > > > messages
>> > > > > > > > > > in
>> > > > > > > > > > > >>> OBR
>> > > > > > > > > > > >>>> application resolver
>> > > > > > > > > > > >>>>
>> > > > > > > > > > > >>>> *2. org.apache.aries.util/0.2.1-SNAPSHOT*
>> > > > > > > > > > > >>>> ARIES-667: OBRAriesResolver can return bundle
>> > > > information
>> > > > > > for
>> > > > > > > > > > bundles
>> > > > > > > > > > > >>> with
>> > > > > > > > > > > >>>> higher version than expected
>> > > > > > > > > > > >>>>
>> > > > > > > > > > > >>>> *3. org.apache.aries.blueprint/0.3.2-SNAPSHOT*
>> > > > > > > > > > > >>>> ARIES-727 support syntax : ${a+b} in blueprint-ext
>> > > > > > > > > > > >>>>
>> > > > > > > > > > > >>>> regards,
>> > > > > > > > > > > >>>> --
>> > > > > > > > > > > >>>> Lei Wang (Rex)
>> > > > > > > > > > > >>>> rwonly AT apache.org
>> > > > > > > > > > > >>>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >> --
>> > > > > > > > > > > >> Lei Wang (Rex)
>> > > > > > > > > > > >> rwonly AT apache.org
>> > > > > > > > > > > >>
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > --
>> > > > > > > > > > > > Alasdair Nottingham
>> > > > > > > > > > > > [email protected]
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > --
>> > > > > > > > > > Alasdair Nottingham
>> > > > > > > > > > [email protected]
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > Lei Wang (Rex)
>> > > > > > > > > rwonly AT apache.org
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Alasdair Nottingham
>> > > > > > > > [email protected]
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Lei Wang (Rex)
>> > > > > > > rwonly AT apache.org
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Lei Wang (Rex)
>> > > > > rwonly AT apache.org
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Alasdair Nottingham
>> > > > [email protected]
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Lei Wang (Rex)
>> > > rwonly AT apache.org
>> > >
>> >
>> >
>> >
>> > --
>> > Alasdair Nottingham
>> > [email protected]
>>
>>
>
>
>
> --
> Alasdair Nottingham
> [email protected]
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
