You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2005/06/13 09:17:47 UTC

[apacheds] Nestable InterceptorChains

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/

Re: [apacheds] Nestable InterceptorChains

Posted by Alex Karasulu <ao...@bellsouth.net>.
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

>On 6/13/05, Alex Karasulu <ao...@bellsouth.net> wrote:
>  
>
>>Marc Boorshtein wrote:
>>    
>>
>>>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.
>>    
>>

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


Re: [apacheds] Nestable InterceptorChains

Posted by Marc Boorshtein <mb...@gmail.com>.
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 <ao...@bellsouth.net> wrote:
> 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
> 
>

Re: [apacheds] Nestable InterceptorChains

Posted by Alex Karasulu <ao...@bellsouth.net>.
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


Re: [apacheds] Nestable InterceptorChains

Posted by Marc Boorshtein <mb...@gmail.com>.
>   
> http://www.archivum.info/dev@directory.apache.org/2005-06/msg00118.html
>  

This looks very interesting.  Unfortunatly I have to get back to work
:-( , so I'll take a look at it a bit later.

>  
> > 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

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?

Marc

Re: [apacheds] Nestable InterceptorChains

Posted by Trustin Lee <tr...@gmail.com>.
Please take a look at this:
 2005/6/13, Marc Boorshtein <mb...@gmail.com>:
 
> Where in the branch? The jira issue doesn't have a lot of explination.

 http://www.archivum.info/dev@directory.apache.org/2005-06/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/

Re: [Infrastructure] JIRA SVN Integration (was Re: [apacheds] Nestable InterceptorChains)

Posted by Trustin Lee <tr...@gmail.com>.
2005/6/14, Noel J. Bergman <no...@devtech.com>: 
> 
> Examples: http://issues.apache.org/jira/browse/DIRMINA-59
> 
> And PLEASE use real commit comments, not just "Fix <issue#>"!! Say what 
> you
> did, not just that you fixed something.

 I see. My bad! :)
 Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

RE: [Infrastructure] JIRA SVN Integration (was Re: [apacheds] Nestable InterceptorChains)

Posted by "Noel J. Bergman" <no...@devtech.com>.
See Message-ID: <20...@zeus.atlassian.com> on the
infrastructure mailing list.

Examples: http://issues.apache.org/jira/browse/DIRMINA-59

And PLEASE use real commit comments, not just "Fix <issue#>"!!  Say what you
did, not just that you fixed something.

	--- Noel


Re: [Infrastructure] JIRA SVN Integration (was Re: [apacheds] Nestable InterceptorChains)

Posted by Alex Karasulu <ao...@bellsouth.net>.
Noel J. Bergman wrote:

>Alex,
>
>How does this different from the SVN integration already present in JIRA?
>  
>
I did not know it had it.  Last I looked there was only CVS integ.  Am i 
missing something?

Alex


RE: [Infrastructure] JIRA SVN Integration (was Re: [apacheds] Nestable InterceptorChains)

Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,

How does this different from the SVN integration already present in JIRA?

	--- Noel

[Infrastructure] JIRA SVN Integration (was Re: [apacheds] Nestable InterceptorChains)

Posted by Alex Karasulu <ao...@bellsouth.net>.
Marc Boorshtein wrote:

>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.
>  
>
Good idea this would make for a useful way to associate commits with 
JIRA issues.  It might work well with hook scripts in SVN combined with 
JIRA developer interfaces.  Don't know if we turn these on though in our 
ASF JIRA because of security reasons.  Exposing these interfaces to only 
local interfaces or certain clients may be convinciing enough to 
infrastructure.

Also you might want to check with the folks on the #svn channel or 
mailing list to see if they already have something in the works.

Good luck and thanks,
Alex


Re: [apacheds] Nestable InterceptorChains

Posted by Marc Boorshtein <mb...@gmail.com>.
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 <tr...@gmail.com> wrote:
>  
> 2005/6/13, Marc Boorshtein <mb...@gmail.com>: 
> > 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/

Re: [apacheds] Nestable InterceptorChains

Posted by Trustin Lee <tr...@gmail.com>.
 2005/6/13, Marc Boorshtein <mb...@gmail.com>: 
> 
> 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/

Re: [apacheds] Nestable InterceptorChains

Posted by Marc Boorshtein <mb...@gmail.com>.
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 <tr...@gmail.com> wrote:
> 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 <mb...@gmail.com>: 
> > 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,myinterceptor2,...
> > 
> > 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/

Re: [apacheds] Nestable InterceptorChains

Posted by Trustin Lee <tr...@gmail.com>.
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 <mb...@gmail.com>: 
> 
> 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,myinterceptor2,...
> 
> 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/

Re: [apacheds] Nestable InterceptorChains

Posted by Marc Boorshtein <mb...@gmail.com>.
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,myinterceptor2,...

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.

Marc


On 6/13/05, Trustin Lee <tr...@gmail.com> wrote:
> 
>  
> 2005/6/13, Marc Boorshtein <mb...@gmail.com>: 
> > 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/

Re: [apacheds] Nestable InterceptorChains

Posted by Trustin Lee <tr...@gmail.com>.
2005/6/13, Marc Boorshtein <mb...@gmail.com>: 
> 
> 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/

Re: [apacheds] Nestable InterceptorChains

Posted by Marc Boorshtein <mb...@gmail.com>.
What was the original use case for nestable interceptor chains?

Marc


On 6/13/05, Trustin Lee <tr...@gmail.com> 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. 
>   
> Trustin
> -- 
> what we call human nature is actually human habit
> --
> http://gleamynode.net/

Re: [apacheds] Nestable InterceptorChains

Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:

> Hi Alex,
>
>  
> 2005/6/14, Alex Karasulu <aok123@bellsouth.net 
> <ma...@bellsouth.net>>:
>
>     > 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.
>
>  
> 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


Re: [apacheds] Nestable InterceptorChains

Posted by Trustin Lee <tr...@gmail.com>.
Hi Alex,

 2005/6/14, Alex Karasulu <ao...@bellsouth.net>: 
> 
> > 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.

 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/

Re: [apacheds] Nestable InterceptorChains

Posted by Alex Karasulu <ao...@bellsouth.net>.
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