You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Vinod Panicker (JIRA)" <ji...@apache.org> on 2005/05/16 12:59:12 UTC
[jira] Created: (DIRMINA-40) Filter API needs callback for enabled notification
Filter API needs callback for enabled notification
--------------------------------------------------
Key: DIRMINA-40
URL: http://issues.apache.org/jira/browse/DIRMINA-40
Project: Directory MINA
Type: Improvement
Versions: 0.7, 0.7.1
Environment: All
Reporter: Vinod Panicker
Assigned to: Trustin Lee
Priority: Blocker
The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Vinod Panicker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_65642 ]
Vinod Panicker commented on DIRMINA-40:
---------------------------------------
The SSL/TLS filter needs to do a handshake when it is applied to a session and also may need to discard sensitive data when it is being removed. Currently this is not possible as isolated activities because if the filter is applied on an active session, the handshake process will not start unless any data is sent/received over the session.
Your previous comment also reminded me about something -The definition of a "Filter". For me, a filter is something that taps the session and monitors/modifies the data flowing over it. I've not been able to digest a ThreadPoolFilter. Thats actually an implementation of a concurrency mechanism rather than a Filter (according to my definition). Maybe if we separate it out into a separate entity, the problem with init() and destroy() might also be solved?
I'll have to check on the current implementation to grok what u're talking abt (filter chain reference counting et al.). Will do that and get back to you on other possible alternatives.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Summer of Code Application
Posted by Trustin Lee <tr...@gmail.com>.
Hello Mary,
2005/6/13, Mary Miller <ma...@hotmail.com>:
> Greetings,
>
> Per request from Alex, I am posting a request for help to apply for the
> Summer of Code program. In particular, how should I fill out the form at:
> http://code.google.com/soc_application.html
Do you want to know how to fill the project description field?
For my technical background, I have created a secure webmail website using
> Ant, Apache, Courier-IMAP, daemontools, djbdns, Java Mail, Kerberos,
> Netcat,
> OpenLDAP, OpenSSH, OpenSSL, Perl, PHP, Python, qmail, Red Hat Linux,
> S/MIME,
> SASL, Squirrelmail, Stunnel, TMDA, Tomcat, and UCSPI-TCP.
Sounds good.
I used Cyrus SASL and the GSSAPI interface to store the webmail user
> passwords securely in Kerberos instead of Berkeley DB. I would be
> delighted
> to work with Kerberos, but the other protocols are just as interesting.
Enrique is the guy who is on Kerberos. He might be able to help you.
I'm working on Apache Directory Server and MINA (network application
framework). Please tell me if you're interested.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Summer of Code Application
Posted by Alex Karasulu <ao...@bellsouth.net>.
Enrique Rodriguez wrote:
> Hey, Alex,
>
> I was reviewing the Summer of Code thread, below. I'd like to make
> sure this info gets captured and kept better up to date in JIRA. Can
> I get some projects created? Namely:
>
> 1) Directory DNS (DIRDNS)
> 2) Directory DHCP (DIRDHCP)
>
>
I created the JIRA projects here Enrique:
DNS ->
http://issues.apache.org/jira/secure/project/ViewProject.jspa?pid=12310064
DHCP ->
http://issues.apache.org/jira/secure/admin/ViewProject.jspa?pid=12310065
Cheers,
Alex
>
> Alex Karasulu wrote:
>
>> Enrique Rodriguez wrote:
>>
>>> Hi,
>>>
>>> Regarding the Summer of Code, I'll add a few points on ApacheDS
>>> projects and repeat what Trustin noted, for completeness.
>>>
>> Kudos to you Enrique for getting to this. I was just about to try to
>> summarize the candidate projects as promised to Mary in an email.
>> Thanks! Let me put some links to the repository where people can
>> actually start looking at the code to get some traction. Please look
>> in line for links to svn ...
>>
>>> 1) DHCP - DHCP codecs work, but without broadcast support in MINA
>>> and, fundamentally, in NIO, there isn't much to be done here until
>>> NIO2 in (hopefully) JDK 1.6. I stopped here, so the handler
>>> workflow isn't totally complete, but should be straight-forward once
>>> MINA/NIO supports broadcast. I consider this code dead until then
>>> and not a worthwhile project.
>>>
>> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dhcp/
>>
>> No common code yet!
>>
>>> 2) DNS - DNS codecs and workflow are in good shape. As Trustin
>>> mentioned, the handlers need to get wired into the ApacheDS backing
>>> store. Right now I have the handler stubbed out to simply echo the
>>> DNS query as the response, but it is actually decoding and
>>> encoding. Some time ago Alex added the DNS schema to the ApacheDS
>>> backend, so that should be ready to go. This is seriously only a
>>> couple days work, but we put it on hold for a number of other
>>> initiatives and lack of demand. What's missing, but probably not
>>> worth a summer of work, are the myriad of RFC's that add record
>>> types. I coded in the most widely used ones, the ones supported by
>>> the schema, such as A and MX, but there are quite a few more.
>>
>>
>>
>> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dns/
>>
>> No common code yet!
>>
>>>
>>> 3) Kerberos - Kerberos is also mostly working, and tested for
>>> interop with Windows and Linux. The major feature missing from RFC
>>> 1510 is cross realm authentication, aka trust relationships. I have
>>> this on my plate already, and it is mostly backend work, figuring
>>> out now how I want to lay this out in the DIT. From more recent
>>> clarifications documents, we are missing more modern encryption
>>> types, but these look to be basic assembly based on crypto in the
>>> JDK or Bouncy Castle.
>>>
>> Protocol Provider (MINA):
>> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/kerberos/
>>
>> Shared (Common Code):
>> http://svn.apache.org/viewcvs.cgi/directory/shared/kerberos/?rev=190518
>>
>>> 4) NTP - NTP is pretty much done. It really just needs to be wired
>>> into the ApacheDS server at some point. One possible project here
>>> is NTP authentication. I didn't do any work on that, but the field
>>> is supported by the codecs. NTP has no configuration, so part of
>>> tying it into ApacheDS would be to at least make the port configurable.
>>
> <snip/>
>
>
Re: Summer of Code Application
Posted by Enrique Rodriguez <en...@gmail.com>.
Hey, Alex,
I was reviewing the Summer of Code thread, below. I'd like to make sure
this info gets captured and kept better up to date in JIRA. Can I get
some projects created? Namely:
1) Directory DNS (DIRDNS)
2) Directory DHCP (DIRDHCP)
The rest of the thread seems to fall pretty well into existing projects.
Enrique
Alex Karasulu wrote:
> Enrique Rodriguez wrote:
>
>> Hi,
>>
>> Regarding the Summer of Code, I'll add a few points on ApacheDS
>> projects and repeat what Trustin noted, for completeness.
>>
> Kudos to you Enrique for getting to this. I was just about to try to
> summarize the candidate projects as promised to Mary in an email.
> Thanks! Let me put some links to the repository where people can
> actually start looking at the code to get some traction. Please look in
> line for links to svn ...
>
>> 1) DHCP - DHCP codecs work, but without broadcast support in MINA
>> and, fundamentally, in NIO, there isn't much to be done here until
>> NIO2 in (hopefully) JDK 1.6. I stopped here, so the handler workflow
>> isn't totally complete, but should be straight-forward once MINA/NIO
>> supports broadcast. I consider this code dead until then and not a
>> worthwhile project.
>>
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dhcp/
>
> No common code yet!
>
>> 2) DNS - DNS codecs and workflow are in good shape. As Trustin
>> mentioned, the handlers need to get wired into the ApacheDS backing
>> store. Right now I have the handler stubbed out to simply echo the
>> DNS query as the response, but it is actually decoding and encoding.
>> Some time ago Alex added the DNS schema to the ApacheDS backend, so
>> that should be ready to go. This is seriously only a couple days
>> work, but we put it on hold for a number of other initiatives and lack
>> of demand. What's missing, but probably not worth a summer of work,
>> are the myriad of RFC's that add record types. I coded in the most
>> widely used ones, the ones supported by the schema, such as A and MX,
>> but there are quite a few more.
>
>
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dns/
>
> No common code yet!
>
>>
>> 3) Kerberos - Kerberos is also mostly working, and tested for interop
>> with Windows and Linux. The major feature missing from RFC 1510 is
>> cross realm authentication, aka trust relationships. I have this on
>> my plate already, and it is mostly backend work, figuring out now how
>> I want to lay this out in the DIT. From more recent clarifications
>> documents, we are missing more modern encryption types, but these look
>> to be basic assembly based on crypto in the JDK or Bouncy Castle.
>>
> Protocol Provider (MINA):
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/kerberos/
>
> Shared (Common Code):
> http://svn.apache.org/viewcvs.cgi/directory/shared/kerberos/?rev=190518
>
>> 4) NTP - NTP is pretty much done. It really just needs to be wired
>> into the ApacheDS server at some point. One possible project here is
>> NTP authentication. I didn't do any work on that, but the field is
>> supported by the codecs. NTP has no configuration, so part of tying
>> it into ApacheDS would be to at least make the port configurable.
<snip/>
Re: Summer of Code Application
Posted by Enrique Rodriguez <en...@gmail.com>.
Alex Karasulu wrote:
> Enrique Rodriguez wrote:
>
>> Alex Karasulu wrote:
>> > ...
>>
>>> 2). More backend partition types as noted above by Enrique.
>>> BTW the Prevayler based in memory backend will save major disk IO
>>> down the line when used to replace the system backend partition. All
>>> major subsystems that will be made more robust after subentries are
>>> implemented will most likely use the system partition to store
>>> persistent information. Prevayler from my understanding puts an
>>> entire db into memory loading it on startup. On shutdown changes
>>> are persisted or synch operations can be made intermittently ...
>>
>>
>>
>> Just want to correct a common misconception about Prevayler, since
>> I've done a couple impl's with it. Prevayler transactions (more like
>> "operations," not to be confused with formal J2EE transactions) ARE
>> immediately persisted to disk. It's the entire store, which yes is in
>> memory, that can be configured to periodically full-synch to disk,
>> generally 24hrs. Upon crash or other restart scenario the
>> transactions can be replayed against the last full-synch, ensuring no
>> loss of data.
>
>
>
> Thanks for the clarification Enrique. I have never used Prevayler but
> have looked at it's documentation thanks to your references. It sounds
> like a great candidate.
> Does it use HOWL for its transaction log?
Nope. You write "transactions" using the Command pattern and the state
of the command object is serialized to disk using JDK object
serialization. There's an option to serialize with XML, too.
-enrique
>
> Alex
>
>
Re: Summer of Code Application
Posted by Alex Karasulu <ao...@bellsouth.net>.
Enrique Rodriguez wrote:
> Alex Karasulu wrote:
> > ...
>
>> 2). More backend partition types as noted above by Enrique.
>> BTW the Prevayler based in memory backend will save major disk IO
>> down the line when used to replace the system backend partition. All
>> major subsystems that will be made more robust after subentries are
>> implemented will most likely use the system partition to store
>> persistent information. Prevayler from my understanding puts an
>> entire db into memory loading it on startup. On shutdown changes
>> are persisted or synch operations can be made intermittently ...
>
>
> Just want to correct a common misconception about Prevayler, since
> I've done a couple impl's with it. Prevayler transactions (more like
> "operations," not to be confused with formal J2EE transactions) ARE
> immediately persisted to disk. It's the entire store, which yes is in
> memory, that can be configured to periodically full-synch to disk,
> generally 24hrs. Upon crash or other restart scenario the
> transactions can be replayed against the last full-synch, ensuring no
> loss of data.
Thanks for the clarification Enrique. I have never used Prevayler but
have looked at it's documentation thanks to your references. It sounds
like a great candidate.
Does it use HOWL for its transaction log?
Alex
Re: Summer of Code Application
Posted by Enrique Rodriguez <en...@gmail.com>.
Alex Karasulu wrote:
> ...
> 2). More backend partition types as noted above by Enrique.
> BTW the Prevayler based in memory backend will save major disk IO down
> the line when used to replace the system backend partition. All major
> subsystems that will be made more robust after subentries are
> implemented will most likely use the system partition to store
> persistent information. Prevayler from my understanding puts an entire
> db into memory loading it on startup. On shutdown changes are
> persisted or synch operations can be made intermittently ...
Just want to correct a common misconception about Prevayler, since I've
done a couple impl's with it. Prevayler transactions (more like
"operations," not to be confused with formal J2EE transactions) ARE
immediately persisted to disk. It's the entire store, which yes is in
memory, that can be configured to periodically full-synch to disk,
generally 24hrs. Upon crash or other restart scenario the transactions
can be replayed against the last full-synch, ensuring no loss of data.
Enrique
Re: Summer of Code Application
Posted by Alex Karasulu <ao...@bellsouth.net>.
Mary Miller wrote:
> Hi,
>
> I appreciate everyone's help today.
>
> The Apache Directory is an impressive project.
>
> I have just submitted my Google Summer of Code application.
Good luck!
Alex
Re: Summer of Code Application
Posted by Mary Miller <ma...@hotmail.com>.
Hi,
I appreciate everyone's help today.
The Apache Directory is an impressive project.
I have just submitted my Google Summer of Code application.
Thank you very much,
Mary
----Original Message Follows----
From: Trustin Lee <tr...@gmail.com>
Reply-To: Trustin Lee <tr...@gmail.com>
To: Apache Directory Developers List <de...@directory.apache.org>
Subject: Re: Summer of Code Application
Date: Tue, 14 Jun 2005 10:11:56 +0900
+1
It would be nice if all persons who are interested with Summer of Code are
looking at this thread!
Trustin
2005/6/14, Alex Karasulu <ao...@bellsouth.net>:
>
> Enrique Rodriguez wrote:
>
> > Hi,
> >
> > Regarding the Summer of Code, I'll add a few points on ApacheDS
> > projects and repeat what Trustin noted, for completeness.
> >
> Kudos to you Enrique for getting to this. I was just about to try to
> summarize the candidate projects as promised to Mary in an email.
> Thanks! Let me put some links to the repository where people can
> actually start looking at the code to get some traction. Please look in
> line for links to svn ...
>
> > 1) DHCP - DHCP codecs work, but without broadcast support in MINA
> > and, fundamentally, in NIO, there isn't much to be done here until
> > NIO2 in (hopefully) JDK 1.6. I stopped here, so the handler workflow
> > isn't totally complete, but should be straight-forward once MINA/NIO
> > supports broadcast. I consider this code dead until then and not a
> > worthwhile project.
> >
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dhcp/
>
> No common code yet!
>
> > 2) DNS - DNS codecs and workflow are in good shape. As Trustin
> > mentioned, the handlers need to get wired into the ApacheDS backing
> > store. Right now I have the handler stubbed out to simply echo the
> > DNS query as the response, but it is actually decoding and encoding.
> > Some time ago Alex added the DNS schema to the ApacheDS backend, so
> > that should be ready to go. This is seriously only a couple days
> > work, but we put it on hold for a number of other initiatives and lack
> > of demand. What's missing, but probably not worth a summer of work,
> > are the myriad of RFC's that add record types. I coded in the most
> > widely used ones, the ones supported by the schema, such as A and MX,
> > but there are quite a few more.
>
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dns/
>
> No common code yet!
>
> >
> > 3) Kerberos - Kerberos is also mostly working, and tested for interop
> > with Windows and Linux. The major feature missing from RFC 1510 is
> > cross realm authentication, aka trust relationships. I have this on
> > my plate already, and it is mostly backend work, figuring out now how
> > I want to lay this out in the DIT. From more recent clarifications
> > documents, we are missing more modern encryption types, but these look
> > to be basic assembly based on crypto in the JDK or Bouncy Castle.
> >
> Protocol Provider (MINA):
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/kerberos/
>
> Shared (Common Code):
> http://svn.apache.org/viewcvs.cgi/directory/shared/kerberos/?rev=190518
>
> > 4) NTP - NTP is pretty much done. It really just needs to be wired
> > into the ApacheDS server at some point. One possible project here is
> > NTP authentication. I didn't do any work on that, but the field is
> > supported by the codecs. NTP has no configuration, so part of tying
> > it into ApacheDS would be to at least make the port configurable.
> >
> > So, same projects that would be good to do over the summer:
>
>
>
http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/ntp/?rev=190518
>
> No common code yet!
>
> >
> >
> > 5) DNS GSS-TSIG - RFC 3645 - Generic Security Service Algorithm for
> > Secret Key Transaction Authentication for DNS (GSS-TSIG). I would be
> > willing to mentor someone on this:
> >
> > http://www.faqs.org/rfcs/rfc3645.html
> >
> > 6) Kerberos RC4-HMAC encryption type. This would be a nice project
> > and would require next to zero messy integration work. The package
> >
>
directory/shared/kerberos/trunk/common/src/java/org/apache/kerberos/crypto
> > has the encryption engines, and you'd be writing a new one of these to
> > produce Kerberos Cipher Text based on the RC4-HMAC algorithm.
> >
> >
>
http://mirror.aarnet.edu.au/pub/samba/specs/draft-brezak-win2k-krb-rc4-hmac-02.txt
> >
> >
> > There are also a couple "new" encryption types based on AES that we
> > don't support, but combined with this RC4-HMAC engine, would add up to
> > a nice-sized project.
> >
> > 7) LDAP ACL - I know we want this but I'm no expert here, just
> > familiar from a usage standpoint with OpenLDAP. In the past Alex has
> > mentioned RFC's 2820, 2829, 3112, and 3062.
>
> See LDAP section below ...
>
> > 8) ApacheDS backing store - We don't talk about this much, but I
> > don't think many of us like the JDBM backing store. We've talked
> > about doing versions with Derby or Prevayler. JDBM has not had a
> > release since 2001 and doesn't appear to be in active development. I
> > seem to recall also that the performance stats were poor.
>
> Also we'd like to see an in memory store but I guess Prevayler covers
> this. WRT Derby I've inquired with DeBruiner (sorry if I spelled the
> name wrong) at last ApCon about efficiency of hierarchical data storage
> and it did not look good ... this was one of the weaker points to Derby
> integration.
>
> WRT to JDBM I agree its been lagging and is slow especially on writes
> but this is ok. I think there are more efficient ways we can be using
> JDBM too however that needs more exploration. Regardless we have yet
> another option since backends are pluggable: using SleepyCat's JE in
> place of JDBM. A common interface for all BTree based stores can be
> used to switch between JE and JDBM. However this may not be necessary
> since the plugability is achieved at the backend partition level.
>
> >
> > 9) SASL - SASL has been discussed a bunch on this list. I refer you
> > to the archives. Specifically, we'd like to add GSS-API/Kerberos
> > support.
>
> General
> =====
>
> Generally for all ApacheDS backed services I recommend building out a
> configuration OU under the ou=system context/partition. Services like
> Kerberos can use the Preferences API to manage their configuration
> information there on changes to defaults. It's like our own registry.
> Here's the code location for a Preferences implementation within the
> ApacheDS server core:
>
>
>
http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/prefs/
>
> ASN.1 Libraries
> ==========
>
> 1). Runtime
>
> Currently Emmanuel is working in the sandbox to replace the existing
> ASN.1 libraries. He has a solution that is 8x faster than the present
> implementation. The present implementation implements a digester
> approach (yes like one used in commons for XML) but is based on matching
> patterns in the hierarchy of streaming tags: turns out to be a poor
> approach from a performance standpoint. It uses rules to that push pop
> objects and operate on them. It's dynamic and in theory thought to be
> more flexible. It turned out to be a nightmare in terms of code
> management. A finite state machine is much faster.
>
> 2). Stub compiler
>
> Some theories and experiments but we're still deciding on the direction.
>
> 3). More LDAP controls in Emmanuel's code and in present day library if
> the new code base will take more time.
>
> People interested in ASN.1 (BER and DER encoding) and a stub compiler
> should connect with Emmanuel Lecharny and Alan Cabrera.
>
> LDAP Agenda, Direction, Road map etc ...
> =========================
>
> 1). Subentries
>
> In short we need to implement the subentries RFC to get to the next
> level where we can introduce Administrative Areas for various aspects:
> authorization, schema, collective attributes, replication etc..
> Administrative Areas are defined by subentries. Kurt Zeilenga from
> OpenLDAP worked on the RFC on subentries which can be found here:
>
> http://www.faqs.org/rfcs/rfc3672.html
>
> As you read into this various requirements will become apparent ... I
> have noted some here on the wiki but it is anemic to say the least:
>
> http://wiki.apache.org/directory/SubtreeRefinements
>
> I started out by adding code to parse and represent a refinement so they
> can be handled by the server in the shared code base since this might be
> used by clients as well later to interpret subentry information. Here's
> a the new package location in SVN where I had started adding this
> stuff. Not much is there so don't get excited :(.
>
>
>
http://svn.apache.org/viewcvs.cgi/directory/shared/ldap/trunk/common/src/java/org/apache/ldap/common/subtree/
>
> TODO:
>
> * parser needs to be completed with these primitives.
> * add internal representation or data structure for quickly looking up
> an entries inclusion set within subtrees for evaluating different
> aspects of administration
> * add subsystems using interceptors to handle aspects:
> - authorization
> - collective attributes
> - schema
>
> 2). More backend partition types as noted above by Enrique.
>
> BTW the Prevayler based in memory backend will save major disk IO down
> the line when used to replace the system backend partition. All major
> subsystems that will be made more robust after subentries are
> implemented will most likely use the system partition to store
> persistent information. Prevayler from my understanding puts an entire
> db into memory loading it on startup. On shutdown changes are
> persisted or synch operations can be made intermittently.
>
> Right now to solve this problem I usually setup the system partition
> parameters for JDBM to use as much cache as needed. This should result
> in theory to a similar behavior but I have not seen this to be the case.
>
> 3). Possible replacement for AspectJ.
>
> The JDK version issues with AspectJ have started to annoy me as they
> will others. Perhaps we can remove the use of aspects all together
> since the point cuts are all static. Don't know. Perhaps we can use
> lower level libraries to achieve this effect with better efficiency.
> AspectJ runtime is not the fastest out there.
>
> 4). Support for LDAP Controls (implementation in server not in ASN.1
> runtime)
>
> o Persistent search control
> o Sort control
> o Named References/ManageDsaIT
>
> 5). The core JNDI provider needs some more work.
>
> The provider lacks full functionality for referrals and other features.
> It would also be nice to be able to get namespace federation working so
> we can bridge the gap between the Naming code and the ApacheDS core
> code. This way we can traverse namespaces and switch providers
> dynamically between namespaces.
>
> 6). Better transaction management and ACIDity instead of using buffer
> cache like mechanism with synch method calls
>
> 7). Triggers, views and stored procedures
>
> Once subentries are in place I would like to have AAA's managing
> information for trigger, view and proc specifications. Nothing like
> this is formalized yet in LDAP so its great material for potentially new
> IETF standards around these constructs. The RDBMS world has em why not
> LDAP?
>
> 8). Correct Abandon operation handling
>
> The Abandon request does not work in the server. Low hanging fruit here
> but it needs to be done right since another thread has to be stopped.
>
> 9). Correct handling of time and size limits
>
> The search request currently does not time out search requests that
> exceed these limits. Search filters can be used to limit these for each
> entry requested since entries are streamed out of the server one at a
> time as they are requested by the JNDI. Search does not load all
> candidate entries selected by a filter into memory then return them: the
> server would croak if we did that.
>
> 10). Complete support for most schema checking constructs
>
> Everything is in place for schema checking but nothing exists today.
> The reason being I did not waste time on schema subsystem since it would
> need to be revamped once we implemented subentries. Subentries for
> schema AAAs would store the schema info there rather than having one
> schema for the entire DIT mastered by a DSA.
>
> Basically an interceptor for schema management would use the subentry
> information to check for correct schema usage in different schema AAAs
> in the DIT.
>
> 11). Better error handling and easily understood messages
>
> 12). Logging
>
> I personally did a poor job of this To my credit much of the logging
> lines were added and removed while moving from one IoC container to the
> next during the Avalon days.
>
> 13). Possible IoC Container Strategy
>
> ApacheDS does not use a container and we have tried to be container
> independent to avoid introducing specificities.
>
> We want the server to be as embeddable as possible WRT the existing
> containers out there. Hence we do not want say the Geronimo folks to
> have to introduce container specific code if they want to embed
> ApacheDS. Plus we don't want protocol implementors and committers on
> the core to have to worry about learning a new container and its
> semantics. Things are already hard.
>
> If we can keep the container code separated from the core then perhaps
> we can ship with a default container for the final executable service.
> Why try? We loose a lot not having a default container. What do we loose:
>
> Aspects like ...
>
> o management interfaces
> o logging
> o configuration
> o hot deployment of components
> o ...
>
> Right now Enrique has attracted my attention to OSGi. He makes
> excellent points about it. It's the container of choice for embedding
> in appliances and other devices. Plus it's got a written specification
> to it endorsed by major companies like IBM, Cisco and many others. This
> is what makes it unique in comparison to the Geronimo GBeans, Spring and
> other Avalon, ComponentHaus productions. All these containers are great
> btw so I'm not putting them down and we still reserve the right to
> integrate with them as well. However OSGi seems like the best candidate
> to Enrique and I.
>
> Enrique,
>
> Perhaps (in a separate mail thread) you can elaborate a bit on OSGi
> advantages and the wrapper code you have introduced in the sandbox?
>
> 14). Language Tags
>
> I'd like to see language tags implemented for LDAP so pulling an
> attribute based on user profile locale can result in the correct value.
> For more info on language tags look here:
>
> http://www.faqs.org/rfcs/rfc3866.html
>
> Yum another fresh new LDAP RFC. Kudos to Zeilenga and friends at
> OpenLDAP. So now the core JNDI provider can be used
> *java.naming.language property and search recall attributes based on a
> language.
>
> http://java.sun.com/j2se/1.3/docs/api/javax/naming/Context.html#LANGUAGE*
>
> 15). Support for collective attributes
>
> K. Zeilenga is unstoppable: another great LDAP specification.
> Unfortunately this is also missing in ApacheDS:
>
> http://www.faqs.org/rfcs/rfc3671.html
>
> Again we need subentries implemented first to do this correctly.
>
> 16). SASL/GSSAPI/Kerberos support
>
> Nice to have some support for this. Insecure LDAP is not LDAP according
> to the security requirements set forth in v3 specifications. Related
> RFCs in LDAP land specifically include:
>
> o http://www.faqs.org/rfcs/rfc3062.html
> o http://rfc3829.x42.com/
>
> 17). DNS-based service location
>
> o http://www.faqs.org/rfcs/rfc3958.html
>
> Comments thoughts with LDAP relationship?
>
> LDAP: Summary
> ==========
>
> The LDAP space is huge and ripe for the pickings. Directories represent
> a cornerstone technology so it is naturally vast and there are even more
> RFCs out there on LDAP. I just hit upon perhaps a third to one half of
> them either directly or indirectly. Step one is not to freak. Step two
> is to start looking for simple areas where you can start working without
> dependencies. As noted several things are dependent on subentry
> implementation but there are other independent efforts that can be
> concurrently developed as well.
>
> In General: Summary
> =============
>
> When looking at these lists try to isolate your interest if any and
> interface with us on the list to see how we can put your feet on the
> ground reading the existing code and formalizing an approach. It's all
> about working together as a community to help one another see the best
> possibilities. Meaning your efforts should not be in a vacuum.
> Otherwise you might be choosing implementation pathways leading to a
> dead end or incorrectly presuming things regarding the current operation
> of the server. We can help you out but cannot read your mind: just your
> emails.
>
> Ask questions! Post to the list and don't feel self conscious. I know
> many people get intimidated posting to these lists. No one will haze
> you for trying to be involved or if you don't have sufficient
> information. We will try to point you to the proper resources if not
> explain things ourselves hopefully adding to those resources.
>
> Good luck,
> Alex
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Summer of Code Application
Posted by Trustin Lee <tr...@gmail.com>.
+1
It would be nice if all persons who are interested with Summer of Code are
looking at this thread!
Trustin
2005/6/14, Alex Karasulu <ao...@bellsouth.net>:
>
> Enrique Rodriguez wrote:
>
> > Hi,
> >
> > Regarding the Summer of Code, I'll add a few points on ApacheDS
> > projects and repeat what Trustin noted, for completeness.
> >
> Kudos to you Enrique for getting to this. I was just about to try to
> summarize the candidate projects as promised to Mary in an email.
> Thanks! Let me put some links to the repository where people can
> actually start looking at the code to get some traction. Please look in
> line for links to svn ...
>
> > 1) DHCP - DHCP codecs work, but without broadcast support in MINA
> > and, fundamentally, in NIO, there isn't much to be done here until
> > NIO2 in (hopefully) JDK 1.6. I stopped here, so the handler workflow
> > isn't totally complete, but should be straight-forward once MINA/NIO
> > supports broadcast. I consider this code dead until then and not a
> > worthwhile project.
> >
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dhcp/
>
> No common code yet!
>
> > 2) DNS - DNS codecs and workflow are in good shape. As Trustin
> > mentioned, the handlers need to get wired into the ApacheDS backing
> > store. Right now I have the handler stubbed out to simply echo the
> > DNS query as the response, but it is actually decoding and encoding.
> > Some time ago Alex added the DNS schema to the ApacheDS backend, so
> > that should be ready to go. This is seriously only a couple days
> > work, but we put it on hold for a number of other initiatives and lack
> > of demand. What's missing, but probably not worth a summer of work,
> > are the myriad of RFC's that add record types. I coded in the most
> > widely used ones, the ones supported by the schema, such as A and MX,
> > but there are quite a few more.
>
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dns/
>
> No common code yet!
>
> >
> > 3) Kerberos - Kerberos is also mostly working, and tested for interop
> > with Windows and Linux. The major feature missing from RFC 1510 is
> > cross realm authentication, aka trust relationships. I have this on
> > my plate already, and it is mostly backend work, figuring out now how
> > I want to lay this out in the DIT. From more recent clarifications
> > documents, we are missing more modern encryption types, but these look
> > to be basic assembly based on crypto in the JDK or Bouncy Castle.
> >
> Protocol Provider (MINA):
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/kerberos/
>
> Shared (Common Code):
> http://svn.apache.org/viewcvs.cgi/directory/shared/kerberos/?rev=190518
>
> > 4) NTP - NTP is pretty much done. It really just needs to be wired
> > into the ApacheDS server at some point. One possible project here is
> > NTP authentication. I didn't do any work on that, but the field is
> > supported by the codecs. NTP has no configuration, so part of tying
> > it into ApacheDS would be to at least make the port configurable.
> >
> > So, same projects that would be good to do over the summer:
>
>
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/ntp/?rev=190518
>
> No common code yet!
>
> >
> >
> > 5) DNS GSS-TSIG - RFC 3645 - Generic Security Service Algorithm for
> > Secret Key Transaction Authentication for DNS (GSS-TSIG). I would be
> > willing to mentor someone on this:
> >
> > http://www.faqs.org/rfcs/rfc3645.html
> >
> > 6) Kerberos RC4-HMAC encryption type. This would be a nice project
> > and would require next to zero messy integration work. The package
> >
> directory/shared/kerberos/trunk/common/src/java/org/apache/kerberos/crypto
> > has the encryption engines, and you'd be writing a new one of these to
> > produce Kerberos Cipher Text based on the RC4-HMAC algorithm.
> >
> >
> http://mirror.aarnet.edu.au/pub/samba/specs/draft-brezak-win2k-krb-rc4-hmac-02.txt
> >
> >
> > There are also a couple "new" encryption types based on AES that we
> > don't support, but combined with this RC4-HMAC engine, would add up to
> > a nice-sized project.
> >
> > 7) LDAP ACL - I know we want this but I'm no expert here, just
> > familiar from a usage standpoint with OpenLDAP. In the past Alex has
> > mentioned RFC's 2820, 2829, 3112, and 3062.
>
> See LDAP section below ...
>
> > 8) ApacheDS backing store - We don't talk about this much, but I
> > don't think many of us like the JDBM backing store. We've talked
> > about doing versions with Derby or Prevayler. JDBM has not had a
> > release since 2001 and doesn't appear to be in active development. I
> > seem to recall also that the performance stats were poor.
>
> Also we'd like to see an in memory store but I guess Prevayler covers
> this. WRT Derby I've inquired with DeBruiner (sorry if I spelled the
> name wrong) at last ApCon about efficiency of hierarchical data storage
> and it did not look good ... this was one of the weaker points to Derby
> integration.
>
> WRT to JDBM I agree its been lagging and is slow especially on writes
> but this is ok. I think there are more efficient ways we can be using
> JDBM too however that needs more exploration. Regardless we have yet
> another option since backends are pluggable: using SleepyCat's JE in
> place of JDBM. A common interface for all BTree based stores can be
> used to switch between JE and JDBM. However this may not be necessary
> since the plugability is achieved at the backend partition level.
>
> >
> > 9) SASL - SASL has been discussed a bunch on this list. I refer you
> > to the archives. Specifically, we'd like to add GSS-API/Kerberos
> > support.
>
> General
> =====
>
> Generally for all ApacheDS backed services I recommend building out a
> configuration OU under the ou=system context/partition. Services like
> Kerberos can use the Preferences API to manage their configuration
> information there on changes to defaults. It's like our own registry.
> Here's the code location for a Preferences implementation within the
> ApacheDS server core:
>
>
> http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/prefs/
>
> ASN.1 Libraries
> ==========
>
> 1). Runtime
>
> Currently Emmanuel is working in the sandbox to replace the existing
> ASN.1 libraries. He has a solution that is 8x faster than the present
> implementation. The present implementation implements a digester
> approach (yes like one used in commons for XML) but is based on matching
> patterns in the hierarchy of streaming tags: turns out to be a poor
> approach from a performance standpoint. It uses rules to that push pop
> objects and operate on them. It's dynamic and in theory thought to be
> more flexible. It turned out to be a nightmare in terms of code
> management. A finite state machine is much faster.
>
> 2). Stub compiler
>
> Some theories and experiments but we're still deciding on the direction.
>
> 3). More LDAP controls in Emmanuel's code and in present day library if
> the new code base will take more time.
>
> People interested in ASN.1 (BER and DER encoding) and a stub compiler
> should connect with Emmanuel Lecharny and Alan Cabrera.
>
> LDAP Agenda, Direction, Road map etc ...
> =========================
>
> 1). Subentries
>
> In short we need to implement the subentries RFC to get to the next
> level where we can introduce Administrative Areas for various aspects:
> authorization, schema, collective attributes, replication etc..
> Administrative Areas are defined by subentries. Kurt Zeilenga from
> OpenLDAP worked on the RFC on subentries which can be found here:
>
> http://www.faqs.org/rfcs/rfc3672.html
>
> As you read into this various requirements will become apparent ... I
> have noted some here on the wiki but it is anemic to say the least:
>
> http://wiki.apache.org/directory/SubtreeRefinements
>
> I started out by adding code to parse and represent a refinement so they
> can be handled by the server in the shared code base since this might be
> used by clients as well later to interpret subentry information. Here's
> a the new package location in SVN where I had started adding this
> stuff. Not much is there so don't get excited :(.
>
>
> http://svn.apache.org/viewcvs.cgi/directory/shared/ldap/trunk/common/src/java/org/apache/ldap/common/subtree/
>
> TODO:
>
> * parser needs to be completed with these primitives.
> * add internal representation or data structure for quickly looking up
> an entries inclusion set within subtrees for evaluating different
> aspects of administration
> * add subsystems using interceptors to handle aspects:
> - authorization
> - collective attributes
> - schema
>
> 2). More backend partition types as noted above by Enrique.
>
> BTW the Prevayler based in memory backend will save major disk IO down
> the line when used to replace the system backend partition. All major
> subsystems that will be made more robust after subentries are
> implemented will most likely use the system partition to store
> persistent information. Prevayler from my understanding puts an entire
> db into memory loading it on startup. On shutdown changes are
> persisted or synch operations can be made intermittently.
>
> Right now to solve this problem I usually setup the system partition
> parameters for JDBM to use as much cache as needed. This should result
> in theory to a similar behavior but I have not seen this to be the case.
>
> 3). Possible replacement for AspectJ.
>
> The JDK version issues with AspectJ have started to annoy me as they
> will others. Perhaps we can remove the use of aspects all together
> since the point cuts are all static. Don't know. Perhaps we can use
> lower level libraries to achieve this effect with better efficiency.
> AspectJ runtime is not the fastest out there.
>
> 4). Support for LDAP Controls (implementation in server not in ASN.1
> runtime)
>
> o Persistent search control
> o Sort control
> o Named References/ManageDsaIT
>
> 5). The core JNDI provider needs some more work.
>
> The provider lacks full functionality for referrals and other features.
> It would also be nice to be able to get namespace federation working so
> we can bridge the gap between the Naming code and the ApacheDS core
> code. This way we can traverse namespaces and switch providers
> dynamically between namespaces.
>
> 6). Better transaction management and ACIDity instead of using buffer
> cache like mechanism with synch method calls
>
> 7). Triggers, views and stored procedures
>
> Once subentries are in place I would like to have AAA's managing
> information for trigger, view and proc specifications. Nothing like
> this is formalized yet in LDAP so its great material for potentially new
> IETF standards around these constructs. The RDBMS world has em why not
> LDAP?
>
> 8). Correct Abandon operation handling
>
> The Abandon request does not work in the server. Low hanging fruit here
> but it needs to be done right since another thread has to be stopped.
>
> 9). Correct handling of time and size limits
>
> The search request currently does not time out search requests that
> exceed these limits. Search filters can be used to limit these for each
> entry requested since entries are streamed out of the server one at a
> time as they are requested by the JNDI. Search does not load all
> candidate entries selected by a filter into memory then return them: the
> server would croak if we did that.
>
> 10). Complete support for most schema checking constructs
>
> Everything is in place for schema checking but nothing exists today.
> The reason being I did not waste time on schema subsystem since it would
> need to be revamped once we implemented subentries. Subentries for
> schema AAAs would store the schema info there rather than having one
> schema for the entire DIT mastered by a DSA.
>
> Basically an interceptor for schema management would use the subentry
> information to check for correct schema usage in different schema AAAs
> in the DIT.
>
> 11). Better error handling and easily understood messages
>
> 12). Logging
>
> I personally did a poor job of this To my credit much of the logging
> lines were added and removed while moving from one IoC container to the
> next during the Avalon days.
>
> 13). Possible IoC Container Strategy
>
> ApacheDS does not use a container and we have tried to be container
> independent to avoid introducing specificities.
>
> We want the server to be as embeddable as possible WRT the existing
> containers out there. Hence we do not want say the Geronimo folks to
> have to introduce container specific code if they want to embed
> ApacheDS. Plus we don't want protocol implementors and committers on
> the core to have to worry about learning a new container and its
> semantics. Things are already hard.
>
> If we can keep the container code separated from the core then perhaps
> we can ship with a default container for the final executable service.
> Why try? We loose a lot not having a default container. What do we loose:
>
> Aspects like ...
>
> o management interfaces
> o logging
> o configuration
> o hot deployment of components
> o ...
>
> Right now Enrique has attracted my attention to OSGi. He makes
> excellent points about it. It's the container of choice for embedding
> in appliances and other devices. Plus it's got a written specification
> to it endorsed by major companies like IBM, Cisco and many others. This
> is what makes it unique in comparison to the Geronimo GBeans, Spring and
> other Avalon, ComponentHaus productions. All these containers are great
> btw so I'm not putting them down and we still reserve the right to
> integrate with them as well. However OSGi seems like the best candidate
> to Enrique and I.
>
> Enrique,
>
> Perhaps (in a separate mail thread) you can elaborate a bit on OSGi
> advantages and the wrapper code you have introduced in the sandbox?
>
> 14). Language Tags
>
> I'd like to see language tags implemented for LDAP so pulling an
> attribute based on user profile locale can result in the correct value.
> For more info on language tags look here:
>
> http://www.faqs.org/rfcs/rfc3866.html
>
> Yum another fresh new LDAP RFC. Kudos to Zeilenga and friends at
> OpenLDAP. So now the core JNDI provider can be used
> *java.naming.language property and search recall attributes based on a
> language.
>
> http://java.sun.com/j2se/1.3/docs/api/javax/naming/Context.html#LANGUAGE*
>
> 15). Support for collective attributes
>
> K. Zeilenga is unstoppable: another great LDAP specification.
> Unfortunately this is also missing in ApacheDS:
>
> http://www.faqs.org/rfcs/rfc3671.html
>
> Again we need subentries implemented first to do this correctly.
>
> 16). SASL/GSSAPI/Kerberos support
>
> Nice to have some support for this. Insecure LDAP is not LDAP according
> to the security requirements set forth in v3 specifications. Related
> RFCs in LDAP land specifically include:
>
> o http://www.faqs.org/rfcs/rfc3062.html
> o http://rfc3829.x42.com/
>
> 17). DNS-based service location
>
> o http://www.faqs.org/rfcs/rfc3958.html
>
> Comments thoughts with LDAP relationship?
>
> LDAP: Summary
> ==========
>
> The LDAP space is huge and ripe for the pickings. Directories represent
> a cornerstone technology so it is naturally vast and there are even more
> RFCs out there on LDAP. I just hit upon perhaps a third to one half of
> them either directly or indirectly. Step one is not to freak. Step two
> is to start looking for simple areas where you can start working without
> dependencies. As noted several things are dependent on subentry
> implementation but there are other independent efforts that can be
> concurrently developed as well.
>
> In General: Summary
> =============
>
> When looking at these lists try to isolate your interest if any and
> interface with us on the list to see how we can put your feet on the
> ground reading the existing code and formalizing an approach. It's all
> about working together as a community to help one another see the best
> possibilities. Meaning your efforts should not be in a vacuum.
> Otherwise you might be choosing implementation pathways leading to a
> dead end or incorrectly presuming things regarding the current operation
> of the server. We can help you out but cannot read your mind: just your
> emails.
>
> Ask questions! Post to the list and don't feel self conscious. I know
> many people get intimidated posting to these lists. No one will haze
> you for trying to be involved or if you don't have sufficient
> information. We will try to point you to the proper resources if not
> explain things ourselves hopefully adding to those resources.
>
> Good luck,
> Alex
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Summer of Code Application
Posted by Marc Boorshtein <mb...@gmail.com>.
> 7). Triggers, views and stored procedures
>
> Once subentries are in place I would like to have AAA's managing
> information for trigger, view and proc specifications. Nothing like
> this is formalized yet in LDAP so its great material for potentially new
> IETF standards around these constructs. The RDBMS world has em why not
> LDAP?
>
is the openldap license compatable with apache lic 2.0? If so you
could probably use the jdbc-ldap bridge as a starting point on this
(implementing the bridge is how i learned ldap, i think the legacy in
summer of code would be quite appropriate :-)). It's pretty moduler,
with the parser being seperate from the LDAP client api (JLDAP). It
use to be based on JNDI, so if you go through the cvs history you
should be able to find the JNDI based backend that could probably fit
into apacheds quite nicely.
Marc
Re: [general] Using OSGi with ApacheDS (was Re: Summer of Code Application)
Posted by Trustin Lee <tr...@gmail.com>.
2005/6/14, Alex Karasulu <ao...@bellsouth.net>:
>
> > What do we loose:
> >
> > Aspects like ...
> >
> > o management interfaces
> > o logging
> > o configuration
> > o hot deployment of components
> > o ...
> >
> > Right now Enrique has attracted my attention to OSGi. He makes
> > excellent points about it. It's the container of choice for embedding
> > in appliances and other devices. Plus it's got a written
> > specification to it endorsed by major companies like IBM, Cisco and
> > many others. This is what makes it unique in comparison to the
> > Geronimo GBeans, Spring and other Avalon, ComponentHaus productions.
> > All these containers are great btw so I'm not putting them down and we
> > still reserve the right to integrate with them as well. However OSGi
> > seems like the best candidate to Enrique and I.
I like the basic idea of using OSGi, but many ppl prefers to use
lightweight IoC containers or hard-code it to use OSGi framework until now.
So I think we can approach in both way actually.
Possible way is to embed OSGi framework and provide frontend POJO, or we
could provide limited funcionality in POJO, and full in OSGi.
WDYT?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
RE: [general] Using OSGi with ApacheDS (was Re: Summer of Code Application)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Are you suggesting adding JMX alone will solve these problem
> minus the logging?
Possibly, yes. See also: JSR-77 and JSR-88. And talk with Dain. But I
would go for a container that supports JMX, and then use JMX.
--- Noel
Re: [general] Using OSGi with ApacheDS (was Re: Summer of Code Application)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Noel J. Bergman wrote:
>>>What do we loose:
>>>Aspects like ...
>>>o management interfaces
>>>o logging
>>>o configuration
>>>o hot deployment of components
>>>
>>>
>
>Except for logging, that sounds like JMX.
>
Are you suggesting adding JMX alone will solve these problem minus the
logging?
-Alex
Re: [general] Using OSGi with ApacheDS (was Re: Summer of Code Application)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Noel J. Bergman wrote:
>>>What do we loose:
>>>Aspects like ...
>>>o management interfaces
>>>o logging
>>>o configuration
>>>o hot deployment of components
>>>
>>>
>
>Except for logging, that sounds like JMX.
>
Are you suggesting adding JMX alone will solve these problem minus the
logging?
-Alex
RE: [general] Using OSGi with ApacheDS (was Re: Summer of Code Application)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > What do we loose:
> > Aspects like ...
> > o management interfaces
> > o logging
> > o configuration
> > o hot deployment of components
Except for logging, that sounds like JMX.
--- Noel
[general] Using OSGi with ApacheDS (was Re: Summer of Code Application)
Posted by Alex Karasulu <ao...@bellsouth.net>.
I thought I'd open up a separate thread wrt using an OSGi based container.
Alex Karasulu wrote:
> 13). Possible IoC Container Strategy
>
> ApacheDS does not use a container and we have tried to be container
> independent to avoid introducing specificities.
> We want the server to be as embeddable as possible WRT the existing
> containers out there. Hence we do not want say the Geronimo folks to
> have to introduce container specific code if they want to embed
> ApacheDS. Plus we don't want protocol implementors and committers on
> the core to have to worry about learning a new container and its
> semantics. Things are already hard.
> If we can keep the container code separated from the core then perhaps
> we can ship with a default container for the final executable
> service. Why try? We loose a lot not having a default container.
> What do we loose:
>
> Aspects like ...
>
> o management interfaces
> o logging
> o configuration
> o hot deployment of components
> o ...
>
> Right now Enrique has attracted my attention to OSGi. He makes
> excellent points about it. It's the container of choice for embedding
> in appliances and other devices. Plus it's got a written
> specification to it endorsed by major companies like IBM, Cisco and
> many others. This is what makes it unique in comparison to the
> Geronimo GBeans, Spring and other Avalon, ComponentHaus productions.
> All these containers are great btw so I'm not putting them down and we
> still reserve the right to integrate with them as well. However OSGi
> seems like the best candidate to Enrique and I.
Thoughts, comments?
BTW OSGi is a spec and many container implementations exist out there.
That's just one of the many reasons why it is so attractive. Enrique
has pointed me to the Oscar and Knopplerfish implementations.
Some folks in both these communities were interested in the idea of an
ASF based implementation. Perhaps we can cross post or get some
specific email addresses to include these people.
Alex
Re: Summer of Code Application
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex, what a mail ! This is almost a roadmap for the next three
years :-)
On Mon, 2005-06-13 at 19:40 -0400, Alex Karasulu wrote:
> WRT to JDBM I agree its been lagging and is slow especially on writes
> but this is ok. I think there are more efficient ways we can be using
> JDBM too however that needs more exploration.
JDBM seems to work well, but at a point it will need to be brought back
to life as an open source project.
> Regardless we have yet another option since backends are pluggable: using
> SleepyCat's JE in place of JDBM.
I don't konw if SleepyCat's licence allow us to embed it into an Apache
project, but at least we can offer an interface. This would be very cool
to have an abstract layer above two kind of database : BTree based
databases and standard relational database (Postgresql, ...)
> ASN.1 Libraries
> ==========
<snip/>
> 2). Stub compiler
>
> Some theories and experiments but we're still deciding on the direction.
Lot of work has to be done... The next version of LDAP ASN.1 codec will
be a step in this direction, and could perfectly well fit with a
compiler.
I will add that we also need two things :
4) A tool to test codec (basically, we need to implement something that
takes a PDU and the expecting decoded value, and checks that the
decoding generates the expected value). It could be XML based.
5) A proxy which shows incoming requests and outgoing responses. Cool to
debug LDAP exchanges.
> People interested in ASN.1 (BER and DER encoding) and a stub compiler
> should connect with Emmanuel Lecharny and Alan Cabrera.
No pb ! (Emmanuel)
> LDAP Agenda, Direction, Road map etc ...
> =========================
> 3). Possible replacement for AspectJ.
Do we need AspectJ ?
> 6). Better transaction management and ACIDity instead of using buffer
> cache like mechanism with synch method calls
Definitively. And we will need it deadly if dealing with replication !
> 11). Better error handling and easily understood messages
+1 :)
> 12). Logging
>
> I personally did a poor job of this To my credit much of the logging
> lines were added and removed while moving from one IoC container to the
> next during the Avalon days.
We have to decide which login mechanism we will use, should it be log4j
or Java log.
I would like to add some items to Alex's list :
18) JMX.
The ApacheDS need to me managed, and JMX is the Java way to do it. I
don't know how long it could take to extend MC4J to handle an ApacheDS
server...
19) Replication
This is something that need to be somwhere in the ApacheDS landscape.
There were some discussion on the dev-list, but I didn't had time to
check where we are going on this subject.
20) Samples
It could be very cool to have some 'real life' samples. Not just ten
entries, but something like 10K entries, with images, and not a flat
tree.
21) Performances/Benchmark
We don't have any benchmark available (expect micro-benchmark). It would
be valuable to expose a performance test to see what king of beast
ApacheDS really is !
Thanks a lot Alex for all these items you added! That's a hudge
roadmap !
Emmanuel Lécharny
Re: Summer of Code Application
Posted by Alex Karasulu <ao...@bellsouth.net>.
Enrique Rodriguez wrote:
> Hi,
>
> Regarding the Summer of Code, I'll add a few points on ApacheDS
> projects and repeat what Trustin noted, for completeness.
>
Kudos to you Enrique for getting to this. I was just about to try to
summarize the candidate projects as promised to Mary in an email.
Thanks! Let me put some links to the repository where people can
actually start looking at the code to get some traction. Please look in
line for links to svn ...
> 1) DHCP - DHCP codecs work, but without broadcast support in MINA
> and, fundamentally, in NIO, there isn't much to be done here until
> NIO2 in (hopefully) JDK 1.6. I stopped here, so the handler workflow
> isn't totally complete, but should be straight-forward once MINA/NIO
> supports broadcast. I consider this code dead until then and not a
> worthwhile project.
>
http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dhcp/
No common code yet!
> 2) DNS - DNS codecs and workflow are in good shape. As Trustin
> mentioned, the handlers need to get wired into the ApacheDS backing
> store. Right now I have the handler stubbed out to simply echo the
> DNS query as the response, but it is actually decoding and encoding.
> Some time ago Alex added the DNS schema to the ApacheDS backend, so
> that should be ready to go. This is seriously only a couple days
> work, but we put it on hold for a number of other initiatives and lack
> of demand. What's missing, but probably not worth a summer of work,
> are the myriad of RFC's that add record types. I coded in the most
> widely used ones, the ones supported by the schema, such as A and MX,
> but there are quite a few more.
http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dns/
No common code yet!
>
> 3) Kerberos - Kerberos is also mostly working, and tested for interop
> with Windows and Linux. The major feature missing from RFC 1510 is
> cross realm authentication, aka trust relationships. I have this on
> my plate already, and it is mostly backend work, figuring out now how
> I want to lay this out in the DIT. From more recent clarifications
> documents, we are missing more modern encryption types, but these look
> to be basic assembly based on crypto in the JDK or Bouncy Castle.
>
Protocol Provider (MINA):
http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/kerberos/
Shared (Common Code):
http://svn.apache.org/viewcvs.cgi/directory/shared/kerberos/?rev=190518
> 4) NTP - NTP is pretty much done. It really just needs to be wired
> into the ApacheDS server at some point. One possible project here is
> NTP authentication. I didn't do any work on that, but the field is
> supported by the codecs. NTP has no configuration, so part of tying
> it into ApacheDS would be to at least make the port configurable.
>
> So, same projects that would be good to do over the summer:
http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/ntp/?rev=190518
No common code yet!
>
>
> 5) DNS GSS-TSIG - RFC 3645 - Generic Security Service Algorithm for
> Secret Key Transaction Authentication for DNS (GSS-TSIG). I would be
> willing to mentor someone on this:
>
> http://www.faqs.org/rfcs/rfc3645.html
>
> 6) Kerberos RC4-HMAC encryption type. This would be a nice project
> and would require next to zero messy integration work. The package
> directory/shared/kerberos/trunk/common/src/java/org/apache/kerberos/crypto
> has the encryption engines, and you'd be writing a new one of these to
> produce Kerberos Cipher Text based on the RC4-HMAC algorithm.
>
> http://mirror.aarnet.edu.au/pub/samba/specs/draft-brezak-win2k-krb-rc4-hmac-02.txt
>
>
> There are also a couple "new" encryption types based on AES that we
> don't support, but combined with this RC4-HMAC engine, would add up to
> a nice-sized project.
>
> 7) LDAP ACL - I know we want this but I'm no expert here, just
> familiar from a usage standpoint with OpenLDAP. In the past Alex has
> mentioned RFC's 2820, 2829, 3112, and 3062.
See LDAP section below ...
> 8) ApacheDS backing store - We don't talk about this much, but I
> don't think many of us like the JDBM backing store. We've talked
> about doing versions with Derby or Prevayler. JDBM has not had a
> release since 2001 and doesn't appear to be in active development. I
> seem to recall also that the performance stats were poor.
Also we'd like to see an in memory store but I guess Prevayler covers
this. WRT Derby I've inquired with DeBruiner (sorry if I spelled the
name wrong) at last ApCon about efficiency of hierarchical data storage
and it did not look good ... this was one of the weaker points to Derby
integration.
WRT to JDBM I agree its been lagging and is slow especially on writes
but this is ok. I think there are more efficient ways we can be using
JDBM too however that needs more exploration. Regardless we have yet
another option since backends are pluggable: using SleepyCat's JE in
place of JDBM. A common interface for all BTree based stores can be
used to switch between JE and JDBM. However this may not be necessary
since the plugability is achieved at the backend partition level.
>
> 9) SASL - SASL has been discussed a bunch on this list. I refer you
> to the archives. Specifically, we'd like to add GSS-API/Kerberos
> support.
General
=====
Generally for all ApacheDS backed services I recommend building out a
configuration OU under the ou=system context/partition. Services like
Kerberos can use the Preferences API to manage their configuration
information there on changes to defaults. It's like our own registry.
Here's the code location for a Preferences implementation within the
ApacheDS server core:
http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/prefs/
ASN.1 Libraries
==========
1). Runtime
Currently Emmanuel is working in the sandbox to replace the existing
ASN.1 libraries. He has a solution that is 8x faster than the present
implementation. The present implementation implements a digester
approach (yes like one used in commons for XML) but is based on matching
patterns in the hierarchy of streaming tags: turns out to be a poor
approach from a performance standpoint. It uses rules to that push pop
objects and operate on them. It's dynamic and in theory thought to be
more flexible. It turned out to be a nightmare in terms of code
management. A finite state machine is much faster.
2). Stub compiler
Some theories and experiments but we're still deciding on the direction.
3). More LDAP controls in Emmanuel's code and in present day library if
the new code base will take more time.
People interested in ASN.1 (BER and DER encoding) and a stub compiler
should connect with Emmanuel Lecharny and Alan Cabrera.
LDAP Agenda, Direction, Road map etc ...
=========================
1). Subentries
In short we need to implement the subentries RFC to get to the next
level where we can introduce Administrative Areas for various aspects:
authorization, schema, collective attributes, replication etc..
Administrative Areas are defined by subentries. Kurt Zeilenga from
OpenLDAP worked on the RFC on subentries which can be found here:
http://www.faqs.org/rfcs/rfc3672.html
As you read into this various requirements will become apparent ... I
have noted some here on the wiki but it is anemic to say the least:
http://wiki.apache.org/directory/SubtreeRefinements
I started out by adding code to parse and represent a refinement so they
can be handled by the server in the shared code base since this might be
used by clients as well later to interpret subentry information. Here's
a the new package location in SVN where I had started adding this
stuff. Not much is there so don't get excited :(.
http://svn.apache.org/viewcvs.cgi/directory/shared/ldap/trunk/common/src/java/org/apache/ldap/common/subtree/
TODO:
* parser needs to be completed with these primitives.
* add internal representation or data structure for quickly looking up
an entries inclusion set within subtrees for evaluating different
aspects of administration
* add subsystems using interceptors to handle aspects:
- authorization
- collective attributes
- schema
2). More backend partition types as noted above by Enrique.
BTW the Prevayler based in memory backend will save major disk IO down
the line when used to replace the system backend partition. All major
subsystems that will be made more robust after subentries are
implemented will most likely use the system partition to store
persistent information. Prevayler from my understanding puts an entire
db into memory loading it on startup. On shutdown changes are
persisted or synch operations can be made intermittently.
Right now to solve this problem I usually setup the system partition
parameters for JDBM to use as much cache as needed. This should result
in theory to a similar behavior but I have not seen this to be the case.
3). Possible replacement for AspectJ.
The JDK version issues with AspectJ have started to annoy me as they
will others. Perhaps we can remove the use of aspects all together
since the point cuts are all static. Don't know. Perhaps we can use
lower level libraries to achieve this effect with better efficiency.
AspectJ runtime is not the fastest out there.
4). Support for LDAP Controls (implementation in server not in ASN.1
runtime)
o Persistent search control
o Sort control
o Named References/ManageDsaIT
5). The core JNDI provider needs some more work.
The provider lacks full functionality for referrals and other features.
It would also be nice to be able to get namespace federation working so
we can bridge the gap between the Naming code and the ApacheDS core
code. This way we can traverse namespaces and switch providers
dynamically between namespaces.
6). Better transaction management and ACIDity instead of using buffer
cache like mechanism with synch method calls
7). Triggers, views and stored procedures
Once subentries are in place I would like to have AAA's managing
information for trigger, view and proc specifications. Nothing like
this is formalized yet in LDAP so its great material for potentially new
IETF standards around these constructs. The RDBMS world has em why not
LDAP?
8). Correct Abandon operation handling
The Abandon request does not work in the server. Low hanging fruit here
but it needs to be done right since another thread has to be stopped.
9). Correct handling of time and size limits
The search request currently does not time out search requests that
exceed these limits. Search filters can be used to limit these for each
entry requested since entries are streamed out of the server one at a
time as they are requested by the JNDI. Search does not load all
candidate entries selected by a filter into memory then return them: the
server would croak if we did that.
10). Complete support for most schema checking constructs
Everything is in place for schema checking but nothing exists today.
The reason being I did not waste time on schema subsystem since it would
need to be revamped once we implemented subentries. Subentries for
schema AAAs would store the schema info there rather than having one
schema for the entire DIT mastered by a DSA.
Basically an interceptor for schema management would use the subentry
information to check for correct schema usage in different schema AAAs
in the DIT.
11). Better error handling and easily understood messages
12). Logging
I personally did a poor job of this To my credit much of the logging
lines were added and removed while moving from one IoC container to the
next during the Avalon days.
13). Possible IoC Container Strategy
ApacheDS does not use a container and we have tried to be container
independent to avoid introducing specificities.
We want the server to be as embeddable as possible WRT the existing
containers out there. Hence we do not want say the Geronimo folks to
have to introduce container specific code if they want to embed
ApacheDS. Plus we don't want protocol implementors and committers on
the core to have to worry about learning a new container and its
semantics. Things are already hard.
If we can keep the container code separated from the core then perhaps
we can ship with a default container for the final executable service.
Why try? We loose a lot not having a default container. What do we loose:
Aspects like ...
o management interfaces
o logging
o configuration
o hot deployment of components
o ...
Right now Enrique has attracted my attention to OSGi. He makes
excellent points about it. It's the container of choice for embedding
in appliances and other devices. Plus it's got a written specification
to it endorsed by major companies like IBM, Cisco and many others. This
is what makes it unique in comparison to the Geronimo GBeans, Spring and
other Avalon, ComponentHaus productions. All these containers are great
btw so I'm not putting them down and we still reserve the right to
integrate with them as well. However OSGi seems like the best candidate
to Enrique and I.
Enrique,
Perhaps (in a separate mail thread) you can elaborate a bit on OSGi
advantages and the wrapper code you have introduced in the sandbox?
14). Language Tags
I'd like to see language tags implemented for LDAP so pulling an
attribute based on user profile locale can result in the correct value.
For more info on language tags look here:
http://www.faqs.org/rfcs/rfc3866.html
Yum another fresh new LDAP RFC. Kudos to Zeilenga and friends at
OpenLDAP. So now the core JNDI provider can be used
*java.naming.language property and search recall attributes based on a
language.
http://java.sun.com/j2se/1.3/docs/api/javax/naming/Context.html#LANGUAGE*
15). Support for collective attributes
K. Zeilenga is unstoppable: another great LDAP specification.
Unfortunately this is also missing in ApacheDS:
http://www.faqs.org/rfcs/rfc3671.html
Again we need subentries implemented first to do this correctly.
16). SASL/GSSAPI/Kerberos support
Nice to have some support for this. Insecure LDAP is not LDAP according
to the security requirements set forth in v3 specifications. Related
RFCs in LDAP land specifically include:
o http://www.faqs.org/rfcs/rfc3062.html
o http://rfc3829.x42.com/
17). DNS-based service location
o http://www.faqs.org/rfcs/rfc3958.html
Comments thoughts with LDAP relationship?
LDAP: Summary
==========
The LDAP space is huge and ripe for the pickings. Directories represent
a cornerstone technology so it is naturally vast and there are even more
RFCs out there on LDAP. I just hit upon perhaps a third to one half of
them either directly or indirectly. Step one is not to freak. Step two
is to start looking for simple areas where you can start working without
dependencies. As noted several things are dependent on subentry
implementation but there are other independent efforts that can be
concurrently developed as well.
In General: Summary
=============
When looking at these lists try to isolate your interest if any and
interface with us on the list to see how we can put your feet on the
ground reading the existing code and formalizing an approach. It's all
about working together as a community to help one another see the best
possibilities. Meaning your efforts should not be in a vacuum.
Otherwise you might be choosing implementation pathways leading to a
dead end or incorrectly presuming things regarding the current operation
of the server. We can help you out but cannot read your mind: just your
emails.
Ask questions! Post to the list and don't feel self conscious. I know
many people get intimidated posting to these lists. No one will haze
you for trying to be involved or if you don't have sufficient
information. We will try to point you to the proper resources if not
explain things ourselves hopefully adding to those resources.
Good luck,
Alex
Re: Summer of Code Application
Posted by Trustin Lee <tr...@gmail.com>.
2005/6/14, Evgeniy Sinev <es...@gmail.com>:
>
> At this time I implementing BIO (old socket I/O) support for MINA
> (with some limitations).
Please make sure you're working on trunk. We have no plan to support BIO
for 0.7 stream, and we'll migrate to 0.9 stream sooner or later one we
release it.
Keep up the good work, please! :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Summer of Code Application
Posted by Evgeniy Sinev <es...@gmail.com>.
Hi,
> 1) DHCP - DHCP codecs work, but without broadcast support in MINA and,
> fundamentally, in NIO, there isn't much to be done here until NIO2 in
> (hopefully) JDK 1.6. I stopped here, so the handler workflow isn't
> totally complete, but should be straight-forward once MINA/NIO supports
> broadcast. I consider this code dead until then and not a worthwhile
> project.
At this time I implementing BIO (old socket I/O) support for MINA
(with some limitations).
Broadcast IP message in this API also not available (under linux), but
DHCP-service may work sending multicast IP messages on the same
ETHERNET network.
For IP routed network (dhcp-relay agents) needs some testing.
Ethernet broadcast messages sends ok.
--
Evgeniy Sinev
Re: Summer of Code Application
Posted by Enrique Rodriguez <en...@gmail.com>.
Hi,
Regarding the Summer of Code, I'll add a few points on ApacheDS projects
and repeat what Trustin noted, for completeness.
1) DHCP - DHCP codecs work, but without broadcast support in MINA and,
fundamentally, in NIO, there isn't much to be done here until NIO2 in
(hopefully) JDK 1.6. I stopped here, so the handler workflow isn't
totally complete, but should be straight-forward once MINA/NIO supports
broadcast. I consider this code dead until then and not a worthwhile
project.
2) DNS - DNS codecs and workflow are in good shape. As Trustin
mentioned, the handlers need to get wired into the ApacheDS backing
store. Right now I have the handler stubbed out to simply echo the DNS
query as the response, but it is actually decoding and encoding. Some
time ago Alex added the DNS schema to the ApacheDS backend, so that
should be ready to go. This is seriously only a couple days work, but
we put it on hold for a number of other initiatives and lack of demand.
What's missing, but probably not worth a summer of work, are the
myriad of RFC's that add record types. I coded in the most widely used
ones, the ones supported by the schema, such as A and MX, but there are
quite a few more.
3) Kerberos - Kerberos is also mostly working, and tested for interop
with Windows and Linux. The major feature missing from RFC 1510 is
cross realm authentication, aka trust relationships. I have this on my
plate already, and it is mostly backend work, figuring out now how I
want to lay this out in the DIT. From more recent clarifications
documents, we are missing more modern encryption types, but these look
to be basic assembly based on crypto in the JDK or Bouncy Castle.
4) NTP - NTP is pretty much done. It really just needs to be wired
into the ApacheDS server at some point. One possible project here is
NTP authentication. I didn't do any work on that, but the field is
supported by the codecs. NTP has no configuration, so part of tying it
into ApacheDS would be to at least make the port configurable.
So, same projects that would be good to do over the summer:
5) DNS GSS-TSIG - RFC 3645 - Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS (GSS-TSIG). I would be
willing to mentor someone on this:
http://www.faqs.org/rfcs/rfc3645.html
6) Kerberos RC4-HMAC encryption type. This would be a nice project and
would require next to zero messy integration work. The package
directory/shared/kerberos/trunk/common/src/java/org/apache/kerberos/crypto
has the encryption engines, and you'd be writing a new one of these to
produce Kerberos Cipher Text based on the RC4-HMAC algorithm.
http://mirror.aarnet.edu.au/pub/samba/specs/draft-brezak-win2k-krb-rc4-hmac-02.txt
There are also a couple "new" encryption types based on AES that we
don't support, but combined with this RC4-HMAC engine, would add up to a
nice-sized project.
7) LDAP ACL - I know we want this but I'm no expert here, just familiar
from a usage standpoint with OpenLDAP. In the past Alex has mentioned
RFC's 2820, 2829, 3112, and 3062.
8) ApacheDS backing store - We don't talk about this much, but I don't
think many of us like the JDBM backing store. We've talked about doing
versions with Derby or Prevayler. JDBM has not had a release since 2001
and doesn't appear to be in active development. I seem to recall also
that the performance stats were poor.
9) SASL - SASL has been discussed a bunch on this list. I refer you to
the archives. Specifically, we'd like to add GSS-API/Kerberos support.
-enrique
Summer of Code Application
Posted by Mary Miller <ma...@hotmail.com>.
Greetings,
Per request from Alex, I am posting a request for help to apply for the
Summer of Code program. In particular, how should I fill out the form at:
http://code.google.com/soc_application.html
For my technical background, I have created a secure webmail website using
Ant, Apache, Courier-IMAP, daemontools, djbdns, Java Mail, Kerberos, Netcat,
OpenLDAP, OpenSSH, OpenSSL, Perl, PHP, Python, qmail, Red Hat Linux, S/MIME,
SASL, Squirrelmail, Stunnel, TMDA, Tomcat, and UCSPI-TCP.
I used Cyrus SASL and the GSSAPI interface to store the webmail user
passwords securely in Kerberos instead of Berkeley DB. I would be delighted
to work with Kerberos, but the other protocols are just as interesting.
I appreciate your help.
Thanks in advance,
Mary Miller
marycmiller@hotmail.com
[jira] Resolved: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=all ]
Trustin Lee resolved DIRMINA-40:
--------------------------------
Resolution: Fixed
I added init() and destroy() callback to IoFilter. They are automatically called when a filter is added to or removed from filter chain. AbstractIoFilterChain counts reference count of filters to prevent chain from calling init() or destroy() multiple times in case that filters are added more than once to different chain.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7.1, 0.7
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_12359005 ]
Trustin Lee commented on DIRMINA-40:
------------------------------------
I changed IoFilter more while revolsing DIRMINA-123
http://svn.apache.org/viewcvs.cgi/directory/network/trunk/src/java/org/apache/mina/common/IoFilter.java?rev=350169&view=markup
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7.1, 0.7
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=all ]
Trustin Lee updated DIRMINA-40:
-------------------------------
Fix Version: 0.9
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_12315042 ]
Trustin Lee commented on DIRMINA-40:
------------------------------------
I replaced ini() and destroy() with filterAdded() and filterRemoved() as you requested. Please check my changes in the trunk. It now passes IoSession or IoSessionManager as a parameter whenever it is added to them. :)
Please close this issue after reviewing it.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7.1, 0.7
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_65586 ]
Trustin Lee commented on DIRMINA-40:
------------------------------------
Please look at DIRMINA-43. I forgot to call createSSLSessionHandler instead of getSSLSessionHandler.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Vinod Panicker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_12313962 ]
Vinod Panicker commented on DIRMINA-40:
---------------------------------------
init() and destroy() without any input parameters are not useful esp for filters such as the SSLFilter.
Taking the example of SSLFilter, an instance of SSLHandler should be logically created in init() if the filter is being applied on a Session that is already active. But in this case, since no Session object is being passed, the filter cant do anything. Also, what should be passed in init() when the filter is being applied on an Acceptor?
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_65629 ]
Trustin Lee commented on DIRMINA-40:
------------------------------------
There was init() and destroy() method long time ago. But I removed them because a filter instances can be used by more than one session managers. For example, thread pool filters could be shared by all acceptors and connectors. filter chains will have to maintain the glocal reference count of filters to call init() and destroy() only once for each. Do you agree?
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Vinod Panicker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_66271 ]
Vinod Panicker commented on DIRMINA-40:
---------------------------------------
This fix doesn't work in required circumstances.
Basically this depends on one of the endpoints writing some data on to the session to start the ssl/tls handshake process.
According to the SSL/TLS RFC, the client initiates the handshake process. If the handshake fails for some reason, the connection is typically terminated.
In the case of the MINA SSLFilter, the handshake can begin only when one of the entities writes data to the session. And if the server writes data first, that data is never sent across since the handshake is pending. In other words, it becomes imperative that the client send some data first. If the application protocol mandates that the server first write some data, the MINA SSLFilter won't work.
The only good fix would be to move the handshake process into an init() method that would get called automatically when the filter is applied. destroy() should also be provided to remove any sensitive information that is stored. Also, the filter should have a callback mechanism by way of which it can notify the handler that the initialization process is complete and actual data transmission can take place. This would be required for proper error handling in the application protocol.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_12355926 ]
Trustin Lee commented on DIRMINA-40:
------------------------------------
I've renamed IoFilter.filterAdded() and filterRemoved() to init() and destroy() to avoid name confusion.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_65582 ]
Trustin Lee commented on DIRMINA-40:
------------------------------------
I modified SSLFilter to create SSLHandler at every events to resolve that issue. SSLHandler is created when SSLHandler interface is not found in its internal map now.
FilterEnabled() and filterDisabled() is a good idea, but adding a filter to an acceptor causes some problem:
* A lot of events are fired at once to cause overload
* SessionManagers have to manage the list of sessions, and we have to handle concurrecy issues while iterating session list.
I think it is best for filter developers to check any data associated with session is initialized before filtering IMHO.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Vinod Panicker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=comments#action_65590 ]
Vinod Panicker commented on DIRMINA-40:
---------------------------------------
Your fix solves the problem. Thanks.
My rationale behind having filterEnabled() and filterDisabled() was to have something like a constructor/destructor for a filter. The filter programmer can do all setup/teardown work in the respective callbacks.
Even if the filter gets applied to an Acceptor, filterEnabled() would get called only once for its lifetime and not for each accepted connection.
This helps a lot in having a clean filter implementation IMO.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7, 0.7.1
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DIRMINA-40) Filter API needs callback for enabled notification
Posted by "Vinod Panicker (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-40?page=all ]
Vinod Panicker closed DIRMINA-40:
---------------------------------
SSLFilter will need to be updated to use filterAdded and filterRemoved.
> Filter API needs callback for enabled notification
> --------------------------------------------------
>
> Key: DIRMINA-40
> URL: http://issues.apache.org/jira/browse/DIRMINA-40
> Project: Directory MINA
> Type: Improvement
> Versions: 0.7.1, 0.7
> Environment: All
> Reporter: Vinod Panicker
> Assignee: Trustin Lee
> Priority: Blocker
> Fix For: 0.9
>
> The Filter api currently assumes that it would be applied only on unopened sessions. Eg - the SSL filter currently starts its work on the sessionOpened() callback. This is an incorrect assumption since the SSL filter could be applied on an existing plain TCP connection as well.
> It would be great if there were new callbacks defined - something like filterEnabled() and filterDisabled()
> This would allow us to use the filters on existing sessions as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira