|
Home > Archive > Apache Directory Project > June 2005 > [apacheds] Nestable InterceptorChains
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[apacheds] Nestable InterceptorChains
|
|
| Trustin Lee 2005-06-13, 2:45 am |
| Hi all,
I made InterceptorChains nestable when I first implement them, but now I
found they makes API more complicated and hard to configure from
configuration files. So I want to make InterceptorChains unnestable like
MINA is. I want to know everyone's opinion.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Marc Boorshtein 2005-06-13, 7:45 am |
| What was the original use case for nestable interceptor chains?
Marc
On 6/13/05, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi all,=20
> =20
> I made InterceptorChains nestable when I first implement them, but now I
> found they makes API more complicated and hard to configure from
> configuration files. So I want to make InterceptorChains unnestable like
> MINA is. I want to know everyone's opinion.=20
> =20
> Trustin
> --=20
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
| |
| Trustin Lee 2005-06-13, 7:45 am |
| 2005/6/13, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> What was the original use case for nestable interceptor chains?
We could create custom interceptor which is actually a chain of
sub-interceptors.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Marc Boorshtein 2005-06-13, 5:45 pm |
| So as in a "package" of interceptors? For instance there are 4 or 5
interceptors that are "default" interceptors, so that you could say in
your configuration:
server. interceptors=3Ddefault,myinterceptor1,my
interceptor2,...
and default would be a pre-configured (or user configured) chain? The
alternative would be
server. interceptors=3Dcontrols,schema,authoriza
tion,...,myinterceptor1,myin=
terceptor2,...
I could see where that would be usefull when packaging several
intercepts as a single unit. The default interceptors can either be
hardcoded or there can be a "hardcoded.props" to store all
configuration for a base system.
I haven't looked on this roadmap, is there a GUI in the works? I
suppose that would simplify the configuration.
Marc
On 6/13/05, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>=20
> =20
> 2005/6/13, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:=20
> =20
> =20
> We could create custom interceptor which is actually a chain of
> sub-interceptors.=20
> =20
> Trustin
> --=20
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
| |
| Trustin Lee 2005-06-13, 5:45 pm |
| The complexity of interceptor chain comes when we interpret the word
'nested' as nested. Let's assume that there are two interceptor chains in
top level chain. When we are using the word 'nested', it means something
hierarchical. So we can simply assume they are packaged like one interceptor
and works as a unit. But it is not true. They are expanded like this:
A -> A1 -> A2 -> B -> B1 -> B2 -> B3
A and B are interceptor chains and Ax and By are their childrens. Hierarchy
has no meaning here actually like above.
The most significant problem is to decide whether the nested chain is
interpreted as a chain, and therefore can work as 'before' and 'after'
pointcut. For example, if you added chain A as a 'after' pointcut, here is
new execution order:
A -> B -> B1 -> B2 -> B3 -> A1 -> A2
This completly breaks the meaning of 'nested', so it brings a lot of
complication. They are not nested actually, and makes the execution order
complicated.
Instead we could add a set of interceptors as a set of
InterceptorConfigurations. Here is the example:
MutableStartupConfiguration cfg = new MutableStartupConfiguration();
Set interceptorSet = GroupedInterceptor.INTERCEPTOR_SET;
cfg.setInterceptors( cfg.getInterceptord().addAll(interceptorSet) );
WDYT?
2005/6/13, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> So as in a "package" of interceptors? For instance there are 4 or 5
> interceptors that are "default" interceptors, so that you could say in
> your configuration:
>
> server. interceptors=default,myinterceptor1,myin
terceptor2,...
>
> and default would be a pre-configured (or user configured) chain? The
> alternative would be
>
> server.interceptors=controls
> ,schema,authorization,...,myinterceptor1,myinterceptor2,...
>
> I could see where that would be usefull when packaging several
> intercepts as a single unit. The default interceptors can either be
> hardcoded or there can be a "hardcoded.props" to store all
> configuration for a base system.
>
> I haven't looked on this roadmap, is there a GUI in the works? I
> suppose that would simplify the configuration.
There's no GUI works yet. I'm working on making ApacheDS configurable
easily via Spring Framework.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Trustin Lee 2005-06-13, 5:45 pm |
| 2005/6/13, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> Think it sounds like a great idea. What would the property config
> look like? I would suggest something similar to the partition config
> pattern (though I wouldn't have the interceptor specific properties in
> an external properties file).
Please take a look at the branch 'direve-158'. It already integrates with
Spring in ApacheDS/main
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Marc Boorshtein 2005-06-13, 5:45 pm |
| Where in the branch? The jira issue doesn't have a lot of explination.
As a side note, in the past when I have worked with Jira i have used a
nice system that takes my checkin comments and adds them to the
approriate jira issue (this was with perforce, not subversion though I
would think the same could be done). This made it easy to find
information about particuler checkins because each comment was linked
to both an issue and a revision and made documentation easier as i
could go through the auto generated release notes and see if there was
any new features that needed documenting. If you would like I can try
to dig up the perforce script (I think it was in perl) that was used
for this integration. I know a couple of other Jira/Perfoce customers
that did this integration as well.
Marc
On 6/13/05, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> =20
> 2005/6/13, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:=20
=20[vbcol=seagreen]
> =20
> =20
> Please take a look at the branch 'direve-158'. It already integrates wit=
h
> Spring in ApacheDS/main=20
> =20
> Trustin
> --=20
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
| |
| Trustin Lee 2005-06-13, 5:45 pm |
| Please take a look at this:
2005/6/13, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Where in the branch? The jira issue doesn't have a lot of explination.
http://www.archivum.info/dev-aYN4UC...6/msg00118.html
As a side note, in the past when I have worked with Jira i have used a
> nice system that takes my checkin comments and adds them to the
> approriate jira issue (this was with perforce, not subversion though I
> would think the same could be done). This made it easy to find
> information about particuler checkins because each comment was linked
> to both an issue and a revision and made documentation easier as i
> could go through the auto generated release notes and see if there was
> any new features that needed documenting. If you would like I can try
> to dig up the perforce script (I think it was in perl) that was used
> for this integration. I know a couple of other Jira/Perfoce customers
> that did this integration as well.
It would be nice if Apache Infra team can do this for us. 
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Marc Boorshtein 2005-06-13, 5:45 pm |
| > =20
> http://www.archivum.info/dev-aYN4UC...6/msg00118.html
> =20
This looks very interesting. Unfortunatly I have to get back to work
:-( , so I'll take a look at it a bit later.
> =20
> =20
> =20
> It would be nice if Apache Infra team can do this for us. =20
> Trustin
This is just my ignorence of the apache infrastructure...does the
apacheds team have control over it's own jira and subversion servers?=20
Or would this request need to be made to a "higher power" so to speak?
Marc
| |
| Marc Boorshtein 2005-06-13, 5:45 pm |
| Think it sounds like a great idea. What would the property config
look like? I would suggest something similar to the partition config
pattern (though I wouldn't have the interceptor specific properties in
an external properties file).
Marc
On 6/13/05, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> The complexity of interceptor chain comes when we interpret the word
> 'nested' as nested. Let's assume that there are two interceptor chains i=
n
> top level chain. When we are using the word 'nested', it means something
> hierarchical. So we can simply assume they are packaged like one
> interceptor and works as a unit. But it is not true. They are expanded
> like this:=20
> =20
> A -> A1 -> A2 -> B -> B1 -> B2 -> B3=20
> =20
> A and B are interceptor chains and Ax and By are their childrens. Hierar=
chy
> has no meaning here actually like above.=20
> =20
> The most significant problem is to decide whether the nested chain is
> interpreted as a chain, and therefore can work as 'before' and 'after'
> pointcut. For example, if you added chain A as a 'after' pointcut, here =
is
> new execution order:=20
> =20
> A -> B -> B1 -> B2 -> B3 -> A1 -> A2=20
> =20
> This completly breaks the meaning of 'nested', so it brings a lot of
> complication. They are not nested actually, and makes the execution orde=
r
> complicated.=20
> =20
> Instead we could add a set of interceptors as a set of
> InterceptorConfigurations. Here is the example:=20
> =20
> MutableStartupConfiguration cfg =3D new MutableStartupConfiguration();=20
> =20
> Set interceptorSet =3D GroupedInterceptor.INTERCEPTOR_SET;=20
> =20
> cfg.setInterceptors( cfg.getInterceptord().addAll(interceptorSet) );=20
> =20
> WDYT?=20
> =20
> 2005/6/13, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:=20
=20[vbcol=seagreen]
> server. interceptors=3Ddefault,myinterceptor1,my
interceptor2,...
> ,schema,authorization,...,myinterceptor1,myinterceptor2,...
> =20
> =20
> There's no GUI works yet. I'm working on making ApacheDS configurable
> easily via Spring Framework.=20
> =20
> Trustin=20
> --=20
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
| |
| Alex Karasulu 2005-06-13, 5:45 pm |
| Trustin Lee wrote:
> Hi all,
>
> I made InterceptorChains nestable when I first implement them, but now
> I found they makes API more complicated and hard to configure from
> configuration files. So I want to make InterceptorChains unnestable
> like MINA is. I want to know everyone's opinion.
>
+1
I agree there is no need to nest and that it adds complexity with
nesting semantics as you described later in this thread with Marc.
Alex
| |
| Alex Karasulu 2005-06-13, 5:45 pm |
| Marc Boorshtein wrote:
Snip ...
>This is just my ignorence of the apache infrastructure...does the
>apacheds team have control over it's own jira and subversion servers?
>Or would this request need to be made to a "higher power" so to speak?
>
>
A higher power would be need yes. We are users and infra administers a
shared svn for all public and private repositories at the ASF.
Alex
| |
| Marc Boorshtein 2005-06-13, 8:45 pm |
| OK. I'll see if I can dig up that script and sent it to you (or this
list?) and let you handle the powers that be should you want to use
it.
Marc
On 6/13/05, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
> Marc Boorshtein wrote:
>=20
> Snip ...
>=20
> A higher power would be need yes. We are users and infra administers a
> shared svn for all public and private repositories at the ASF.
>=20
> Alex
>=20
>
| |
| Alex Karasulu 2005-06-13, 8:45 pm |
| Marc Boorshtein wrote:
>OK. I'll see if I can dig up that script and sent it to you (or this
>list?)
>
See if you can add a JIRA issue to the infrastructure JIRA here and add
the file as an attachment with background info:
http://issues.apache.org/jira/browse/INFRA
[vbcol=seagreen]
>On 6/13/05, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
>
>
This way the request is on the infrastructure radar screen, infra has a
starting point to look at, and you can point SVN peeps too it if you
interface with them. Not to mention we can track status on the issue.
I know this feels like a bit of a run around and apologize for that but
I do assure you this is the most efficient pathway for getting things
done .
Thanks again,
Alex
| |
| Trustin Lee 2005-06-13, 8:45 pm |
| Hi Alex,
2005/6/14, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>:
>
>
> +1
>
> I agree there is no need to nest and that it adds complexity with
> nesting semantics as you described later in this thread with Marc.
Great. Then I'll make InterceptorChain unnestable and configurable now...
BTW Could you take a look at the changes I've made in branch 'DIREVE-158'
so that I can merge it and document it more?
Thanks in advance,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
| |
| Alex Karasulu 2005-06-13, 8:45 pm |
| Trustin Lee wrote:
> Hi Alex,
>
>
> 2005/6/14, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org
> <mailto:aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>>:
>
> but now
>
> +1
>
> I agree there is no need to nest and that it adds complexity with
> nesting semantics as you described later in this thread with Marc.
>
>
> Great. Then I'll make InterceptorChain unnestable and configurable now...
>
> BTW Could you take a look at the changes I've made in branch
> 'DIREVE-158' so that I can merge it and document it more?
>
Aye will try to look soon ... Let's meet 11pm EST on #directory-dev to
discuss this more. That's noon time KST 1 hour and 20 min from now.
Enrique will be there to discuss some OSGi stuff too.
C'ya there,
Alex
|
|
|
|
|