Re: Discuss: Move Geronimo to Attic

[Alex Karasulu]

I think more important than whether or not JEE is popular (or whatever
along those lines), are the questions about community health and is the PMC
still capable of fulfilling its duties.

My 2 cents,
--Alex

On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  wrote:

> Romain and I went through the Geronimo SVN and made a list of which
> components are used by other projects.
>
>
> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/
>
> https://svn.apache.org/repos/asf/geronimo/KEYS
>
> https://svn.apache.org/repos/asf/geronimo/components/txmanager
> • TomEE (txmgr+connector)
> • Meecrowave (txmgr)
> • Aries (txmgr)
>
> https://svn.apache.org/repos/asf/geronimo/components/
> geronimo-schema-javaee_6
>
> https://svn.apache.org/repos/asf/geronimo/genesis/
> • Maven parents for geronimo-specs
>
> https://svn.apache.org/repos/asf/geronimo/javamail/
> • TomEE as delivery
> • Lot of standalone
> • -> we can ask Hendrik pby
>
> https://svn.apache.org/repos/asf/geronimo/specs/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • OpenJPA
> • Johnzon
> • BatchEE
> • Karaf
> • Aries
> • Tons of external customer projects which don’t want to use some
> official javax jars due to licensing concerns
>
> https://svn.apache.org/repos/asf/geronimo/xbean/
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • Aries
> • Karaf
> • OpenJPA
> • CXF (supported)
>
> Osgi-locator too but guess this one can drop and belong to karaf or
> servicemix.
> Q: well we need the osgi locator in our geronimo-specs, isn’t?
>
>
> I've created a google doc. Just ping me if you want to edit something and
> I'll share it.
>
> David, you mentioned JASPIC. I could not find that even. Is this inside
> the geronimo-server probably?
> Are there other gems which are not maintained as components but just
> inside geronimo?
>
> txs and LieGrue,
> strub
>
>
> > Am 09.03.2017 um 08:44 schrieb David Jencks :
> >
> > I go back and forth on whether to shut G down completely.  Perhaps it
> would be useful to inventory which parts are used by which other projects?
> Off the top of my head….
> >
> > Specs …. who uses G’s and who has their own?
> >
> > Components…. I think there are several users of the transaction manager,
> I don’t know about the connector framework, and I’m pretty sure no one uses
> my jaspic implementation.  The TM is stable but now that faster than
> spinning rust persistent memory is popular the logger could probably be
> rewritten to be much faster.
> >
> > xbean …. tomee I believe, anyone else?  Does activemq still use
> xbean-spring?  Knowing more about osgi now I might be able to gets
> xbean-blueprint to work:-)
> >
> > yoko is used by IBM, I doubt anyone else will get all excited about
> CORBA and start contributing.
> >
> > Any other bits being used?
> >
> > If we kept G around in a reduced state, how will we maintain enough
> interest to file the board reports?  Some days  I think I might have enough
> interest and some days not.
> >
> > If we did not shut down the whole project would we mark the removed bits
> (server primarily) as not being developed or move them to the attic?
> >
> > thanks
> > david jencks
> >
> >> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau 
> wrote:
> >>
> >> A valid point is activity related to G happens elsewhere, However
> elsewhere is not "tomee" which would make things simple to move but A, B, C
> so shutting down G is likely the easiest solution for G itself but also the
> worse for all its dependent projects - and ASF consistency since G is now
> seen as the owner of specs, xbean etcToday G is the result of
> communities and I don't see it as a bad thing even if not common @ASF. It
> allows new interactions with sometimes completely different area of
> knowledge which is actually great and can't happen elsewhere IMHO (the dead
> of G would mean fork per project probably).
> >>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >>
> >> 2017-03-09 5:13 GMT+01:00 Matt Hogstrom :
> >> I’ve monitored G for several years since my departure.  For me, JEE is
> not my main area of focus and as such, I’ve invested little time in the
> project apart from reading the e-mail threads.  This is a community
> decision and posting the discussion to dev@ is the right venue.
> >>
> >> As an inactive member I don’t have a strong vote, but, my observation
> is that most of the community has moved on and there is little activity.
> If those that are still active want to keep going then God’s speed.
> >>
> >> Matt Hogstrom
> >> m...@hogstrom.org
> >> +1-919-656-0564
> >> PGP Key: 0x90ECB270
> >> Facebook  LinkedIn  Twitter
> >>
> >> "I’m smart enough to know how dumb I am."
> >> -  Hogstrom
> >>
> >>
> >>
> >>> On Mar 9, 2017, at 08:47, Jason Dillon  wrote:
> >>>
> >>> On

Re: LDAP on Geronimo via the directory plugin and the LDAP sample app

[Alex Karasulu]

FYI we're currently in the process of releasing ApacheDS 1.5.4 which should
have serious improvements.  Will be out the door in about 1-2 hours.

Alex

On Wed, Sep 10, 2008 at 10:05 PM, Donald Woods <[EMAIL PROTECTED]> wrote:

> Agree.  Once we're in release mode, rolling back to genesis 1.4 is fine.
>
>
> -Donald
>
>
> Joe Bohn wrote:
>
>> Right ... but we're trying to release a non-snapshot version of the
>> samples.  So, I don't see the harm in rolling it back to genesis 1.4 for the
>> release if the only value add was for snapshot processing.
>>
>> Joe
>>
>>
>>
>> Donald Woods wrote:
>>
>>> 1.5-SNAPSHOT includes the settings to not generate timestamped snapshot
>>> artifacts, as requested by infra.
>>>
>>>
>>> -Donald
>>>
>>>
>>> Joe Bohn wrote:
>>>
 Donald Woods wrote:

> I'd vote for going with 1a) over 1b) and 1c) is not an option in my
> mind.  If someone ever does 1b) then great, but lets not hold up the 
> samples
> over it.
>
>
> BTW - Should we start a Genesis 1.5 vote, since Samples is currently
> using and needs the 1.5-SNAPSHOT level?
>

 Oh yes, I forgot that you had updated that for 1.5-SNAPSHOT. What was
 the rationale in doing that again over 1.4?  I had updated it to 1.4 
 earlier
 and it seemed to be working fine.  Was it just for the snapshot processing?
  If that was the case then there doesn't seem to be much value in moving to
 1.5-SNAPSHOT and making that a prereq for a samples release.

 Joe


>
> -Donald
>
>
> Joe Bohn wrote:
>
>>
>> Two issues here that I hit while attempting to validate the LDAP
>> sample and get it ready for release.
>>
>> 1) The directory plugin won't install on Geronimo 2.1.2.  At the
>> moment, one of the easiest ways to leverage the sample if you don't 
>> already
>> have an external directory server is via the directory plugin.  However,
>> this plugin was last released for Geronimo 2.1.  It fails to install on
>> 2.1.1 or 2.1.2 due to dependencies on 2.1 artifacts.  2.1.2 was our 
>> latest
>> target release for samples.   With the inclusion of the alias entries it
>> deploys fine in Geronimo 2.1.3.  So I think we have the following
>> options:
>>
>> a) Require an external directory server for the sample rather than
>> using the directory plugin if installing on a Geronimo 2.1.2 server
>> b) Release a new version of the directory plugin with dependencies on
>> Geronimo 2.1.2 which would install in both 2.1.2 & 2.1.3
>> c) Push our samples support out from 2.1.2 to 2.1.3
>> d) other choices (such as creating a compatibility plugin for this on
>> 2.1.2 and using that for a 2.1.2 install) or any other ideas?
>>
>> I personally hate c).  We keep pushing samples to later releases ...
>> but it does make sense that samples are most valuable for new users on 
>> the
>> latest release so I see the logic.  d) doesn't seem any better than 
>> creating
>> a new version of the directory plugin for 2.1.2 (and it's more 
>> complicated
>> for the user).  a) isn't very user friendly either and doesn't help users
>> with a need to run directory on Geronimo 2.1.2.
>>
>> - So all in all, I'm thinking b) makes the most sense given that it
>> has broader use beyond just the sample.  What are your thoughts?
>>
>>
>>
>> 2) While testing the sample I noticed the following error on the
>> console.  I couldn't tie it to any particular activity ... it seemed that
>> the sample was working as expected.  Any ideas?
>>
>> 15:06:18,110 ERROR [UnbindHandler] failed to unbind session properly
>> org.apache.directory.shared.ldap.exception.LdapNameNotFoundException:
>> uid=admin,ou=system
>>at
>> org.apache.directory.server.core.partition.DefaultPartitionNexus.getPartition(DefaultPartitionNexus.java:1114)
>>
>>at
>> org.apache.directory.server.core.partition.DefaultPartitionNexus.unbind(DefaultPartitionNexus.java:773)
>>
>>at
>> org.apache.directory.server.core.interceptor.InterceptorChain$1.unbind(InterceptorChain.java:210)
>>
>>at
>> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind(InterceptorChain.java:1412)
>>
>>at
>> org.apache.directory.server.core.interceptor.BaseInterceptor.unbind(BaseInterceptor.java:229)
>>
>>at
>> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind(InterceptorChain.java:1412)
>>
>>at
>> org.apache.directory.server.core.interceptor.BaseInterceptor.unbind(BaseInterceptor.java:229)
>>
>>at
>> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind(InterceptorChain.java:1412)
>>
>>at
>> org.apache.directory.server.core.interceptor.BaseInterceptor.unbind(BaseIntercept

Re: [ANN] Geronimo -ApacheDS plugin 1.0 released

[Alex Karasulu]

We should be thanking you David, for your hard work to just get this done.

Thanks,
Alex

On Mon, Mar 17, 2008 at 1:53 AM, David Jencks <[EMAIL PROTECTED]>
wrote:

> The Geronimo team is pleased to announce the release of the Apache
> Geronimo - Apache Directory Server plugin 1.0
>
> This plugin allows installing and running the ApacheDS server version
> 1.5.1 in an Apache Geronimo 2.1 server.  The ApacheDS server can be
> configured through a server.xml file just as with a standalone server.
>
> This is the initial release of this plugin.
>
> Many thanks
>
> -The Geronimo team
>

Re: [DISCUSS] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Alex Karasulu]

This is a minor and harmless bug in the server.  It occurs on all unbinds
and you might specifically want to make sure it is not allowed to log.
We're aware of it and will fix this shortly over at Apache Directory.

Alex

On Wed, Mar 12, 2008 at 2:26 PM, David Jencks <[EMAIL PROTECTED]>
wrote:

> I believe I've seen this with standalone apacheds 1.5.1 as well, I don't
> think it is the plugin's fault.  I don't see any geronimo-controlled classes
> in this stack trace.
> anyone able to verify?
>
> thanks
> david jencks
>
> On Mar 12, 2008, at 10:55 AM, Vamsavardhana Reddy wrote:
>
> The statement about the User DN may not be correct.  Will reverify.
>
> Problem may not be with the directory plugin, but, when ever there is a
> login failure with the LDAP realm, the following error is logged (don't
> remember seeing this error earlier):
>
> 23:16:52,671 ERROR [UnbindHandler] failed to unbind session properly
> org.apache.directory.shared.ldap.exception.LdapNameNotFoundException:
> uid=admin,ou=system
> at
> org.apache.directory.server.core.partition.DefaultPartitionNexus.getPartition
> (DefaultPartitionNexus.java:1114)
> at
> org.apache.directory.server.core.partition.DefaultPartitionNexus.unbind(
> DefaultPartitionNexus.java:773)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$1.unbind(
> InterceptorChain.java:210)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.unbind
> (InterceptorChain.java:1412)
> at org.apache.directory.server.core.interceptor.BaseInterceptor.unbind
> (BaseInterceptor.java:229)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain.unbind(
> InterceptorChain.java:794)
> at
> org.apache.directory.server.core.partition.PartitionNexusProxy.unbind(
> PartitionNexusProxy.java:684)
> at
> org.apache.directory.server.core.partition.PartitionNexusProxy.unbind(
> PartitionNexusProxy.java:701)
> at org.apache.directory.server.core.jndi.ServerLdapContext.ldapUnbind(
> ServerLdapContext.java:210)
> at
> org.apache.directory.server.ldap.support.UnbindHandler.messageReceived(
> UnbindHandler.java:58)
> at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(
> DemuxingIoHandler.java:141)
> at
> org.apache.directory.server.ldap.LdapProtocolProvider$LdapProtocolHandler.messageReceived
> (LdapProtocolProvider.java:428)
> at
> org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived
> (AbstractIoFilterChain.java:570)
> at
> or

Re: [VOTE] Geronimo 2.1 plugin for Apache Directory 1.5.1 version 1.0

[Alex Karasulu]

+1 :)

On Wed, Mar 12, 2008 at 3:19 PM, Dan Becker <[EMAIL PROTECTED]> wrote:

> David Jencks wrote:
> > The directory plugin is finally ready to go.  This vote includes the
> > directory gbean and a plugin to install it.  There's also a sample
> > server that is not being voted on for release: i'm uploading it to
> > http://people.apache.org/~djencks/samples
>
> +1
>
> --
> Thanks, Dan Becker
>

Re: directory plugin

[Alex Karasulu]

On Sat, Mar 8, 2008 at 7:44 PM, Kevan Miller <[EMAIL PROTECTED]> wrote:

>
>
>  !? ./directory/src/main/resources/META-INF/server.xml
>  !? ./geronimo-directory/src/test/resources/server.xml
>  !? ./geronimo-directory-server/pom.xml
>
> The pom.xml file needs a src license header. I'm going to add that.
> I'm not sure about the other two. Did they come from the directory
> project?
>
>
Yes that's from the server-xml module of ApacheDS.  Right now it seems to
have been released that way since G depends on 1.5.1.  We'll make sure this
is not the case with a soon to be released 1.5.2.

Alex

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu]

Kevan,

Thanks for taking the time to respond.  More inline ...

On Jan 30, 2008 1:08 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:
...

>
> So, as we discussed the last time, the community members that have been
> active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You
> already know Jeff. Have you reached out to Sangjin and Rick?
> I'd urge them both to become involved in the Mina community, as their time
> and interest permit.
>

Right very good point.

So Sangjin and Rick are you interested in working on this with the rest of
the asyncweb crew at MINA?


>
> I can understand, however, if Rick and Sangjin see value in the current
> codebase
>

NP that's something to consider and evaluate.  And regardless of the code in
general we can share knowledge and expertise.  I'm sure experiences will rub
off and this is the most important part of it.  The code here is small
compared to the collaborative potential.


>
> So, one possible solution that occurs to me is to transfer the current
> 1.1.x code in Geronimo sandbox to the Mina project. This might allow Rick
> and Sangjin to complete their work on the current codebase and also ease
> their transition towards merging code and fixes into the Mina 2.xcodebase. 
> Alternatively, we can leave the code in Geronimo sandbox while
> Sangjin and Rick transition their focus to the Mina 2.x support.
>
> Will leave it to the Mina project, Rick, and Sangjin to say what makes the
> most sense.
>

I think all options are open for us.

Thanks for your help towards fostering greater community.

Alex

[AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu]

Hi,

Please excuse the cross post but it's quite necessary. Furthermore people
should not feel like they cannot cross post responses so please feel free.

It looks like the two versions of the http client based on MINA are starting
to diverge.  I've noticed the other day that some of the fixes for bugs
already solved by one group are being re-implement all over again over again
by another.  It's a shame to have that happen so perhaps we can take some
concrete steps to prevent this divergence from progressing.

As a first step I've cleaned up and restructured the Asyncweb code base and
posted this email here on the new directory structure in Subversion:

  *http://tinyurl.com/ypmbd3

*So I'm sending out this cross post in the hopes of bringing the two groups
together as one unified community which apparently has the same goal in
mind: a fast low-resource consuming asynchronous http client.  What ever it
takes, I'm sure the MINA PMC is more than willing to accommodate.  If you
have trusted committers already working on this in the Geronimo community
there is no reason why we cannot trust them to continue working on it here
at MINA's Asyncweb project.  Let's open up discussions on this.

Specifically I ask the Geronimo committers working on AHC to let us know
what we can do to take concrete next steps.

Thanks,
Alex

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Alex Karasulu]

I think Jeff started working on some of it over at MINA btw.  Excuse the
cross post.

Alex

On Jan 9, 2008 4:10 PM, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

> If it is better and easier than http-client are they interested in
> it?  Seems like a logical fit.  That said, I think Genender boy wanted
> to melt some metal when he started this work.  If it remains without a
> home I'd put it in components and let folks pick it up if they are
> interested.
>
> On Jan 9, 2008, at 9:55 AM, Kevan Miller wrote:
>
> >
> > On Jan 8, 2008, at 9:59 AM, Donald Woods wrote:
> >
> >> #3 is okay with me.  Was just thinking that #2 (plugin) would allow
> >> us to expose it on our plugin website and allow other users to just
> >> place a dependency on it in their plugins
> >
> > Oops. Got distracted and forgot to reply...
> >
> > I was thinking that AHC functionality could be released under
> > components (and thus easier to consume by other projects). We can
> > then create a plugin which includes this component. So, really a
> > combination of 2 and 3.
> >
> > --kevan
> >
> >
> >>
> >>
> >> -Donald
> >>
> >> Kevan Miller wrote:
> >>> On Jan 5, 2008, at 2:45 PM, Donald Woods wrote:
>  There has been a lot of ongoing work by Jeff, Prasad, Rick,
>  Sangjin and others on the AsyncHttpClient (aka. AHC) code in the
>  sandbox and I'd like to start the discussion on moving it from
>  sandbox into trunk.
> 
>  There are a couple options as to where it could reside -
>  1) under server/trunk/applications
>  2) under server/trunk/plugins
>  3) under geronimo/components/
> 
>  What are everyone's thoughts?  I'd like to get this into our 2.1
>  release and possibly into the 2.0.x branch if time allows.
> >>> Personally, I don't think it should go into server/trunk.
> >>> There's a 4'th option -- create a subproject (e.g. geronimo/ahc).
> >>> The only real difference,  between this and 3) is web site, jira,
> >>> etc.
> >>> At the moment, I'm leaning towards 3) -- geronimo/components/ahc
> >>> (or some more descriptive name), but could probably be swayed...
> >>> --kevan
> >
> >
>
>

Account for [EMAIL PROTECTED] down for few hrs.

[Alex Karasulu]

Hello world,

I had an unfortunate problem with my gmail account today.  It is
currently being repaired.  During this
time any emails received may be > /dev/null.  Please do not use this
account for the next 8 hours.

If you need to reach me via email please send your email to
[EMAIL PROTECTED] This email address
always forwards to a funcational email account that I monitor.

Thank you, and sorry for the noise,
Alex Karasulu

Re: Security for dynamic content apps -- gettogether at ApacheCon?

[Alex Karasulu]

Unfortunately I'm not going to be going to ApacheCon's in the US but to the
EU ones
from now on.  However I would love to either get a summary or partake in the
discussion
if someone can ping me from IRC or via skype.  This is something I think
will benefit us
all.  Thanks David for driving these talks.

Alex

On 11/5/07, David Jencks <[EMAIL PROTECTED]> wrote:
>
> I've worked a bit on integrating Roller and Jetspeed2 into Geronimo
> and one thing that quickly becomes clear is that the authorization
> security requirements of these "dynamic content" applications are
> almost completely unrelated to the javaee security specifications.
> One small possible overlap is that the JACC spec supplies the
> possibility of pluggable policies for authorization evaluation.
>
> I wondered if people would be interested in getting together to
> discuss how app servers such as geronimo and security products such
> as TripleSec could support these non-javaee security requirements and
> how much commonality there might be across different types of
> application.  I'll be at ApacheCon all week and would be happy to
> talk to everyone individually or in an informal meeting.
>
> Some of the things I've been wondering about are:
>
> - permission definition
> - user administration: how are users added and removed or have their
> permissions changed.
> - resource administration: how are resources such as blogs, portal
> pages, or portlets added or removed or have their user access changed
> - specification of "default policy" for new users and new resources:
> e.g. when a new user signs up what can they do?
>
> thanks!
> david jencks
>
>

Re: Apache Directory in g. is antique.... what to do for 2.0?

[Alex Karasulu]

Excellent and thanks!
Alex

On 7/13/07, Jeff Genender <[EMAIL PROTECTED]> wrote:


I think the Directory folks are working on it.  They pinged me a few
weeks ago about it and said they were going to take a swipe at it.

I would be happy to help get this updated as well.

Jeff

David Jencks wrote:
> Geronimo apache directory support is stuck at 0.9.2 which is antique to
> be charitable.  I'm not sure we want to ship something so old.
>
> should we
> - move it to an optional plugin and ship it when we update it?
> - update to apacheds 1.5 now?
> - leave as is?
>
> I think I'm in favor of 1 & 2 and may take a shot at updating it if no
> one beats me to it.
>
> thanks
> david jencks

Re: Apache Directory in g. is antique.... what to do for 2.0?

[Alex Karasulu]

Jeff G. could you see if you and Stefan Z. can do something about this to
help David?

Alex

On 7/13/07, David Jencks <[EMAIL PROTECTED]> wrote:


Geronimo apache directory support is stuck at 0.9.2 which is antique
to be charitable.  I'm not sure we want to ship something so old.

should we
- move it to an optional plugin and ship it when we update it?
- update to apacheds 1.5 now?
- leave as is?

I think I'm in favor of 1 & 2 and may take a shot at updating it if
no one beats me to it.

thanks
david jencks

Re: [Code donation] J2G Conversion tool

[Alex Karasulu]

+1 on the CCLA's with a patch submission.  If it's a considerable piece of
code perhaps a software grant may be in order.

There is no reason why something this small should incubate.

Regards,
Alex

On 1/17/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:


Dain Sundstrom wrote:
> On Jan 16, 2007, at 12:19 PM, Filip Hanik - Dev Lists wrote:
>
>> IBM has together with in a joint effort with Covalent developed a
>> JBoss to Geronimo conversion tool. This tool is used when converting
>> applications from JBoss to Geronimo, and automatically converts the
>> configuration file from one app server to the other.
>>
>> We feel that this piece of software adds value to Geronimo and users
>> adopting Geronimo and would like to see this effort continue as part
>> of the Geronimo project, a plugin or a sub project of Geronimo.
>>
>> The initial donation is for version 1.0 of this tool, and while a 1.1
>> is in the making to improve 1.0, 1.1 is not yet complete but will be
>> donated as soon as the community feels that this tool belongs at the
>> ASF, more specifically within the Geronimo project.
>>
>> If you'd think this tool is valuable, but believe it should go
>> through incubation, we would hope that a Geronimo committer would
>> step up and champion this effort.
>>
>> The tool, including IBM's CCLA, can be found at
>> http://people.apache.org/~fhanik/j2g/j2g.html (Covalent will file the
>> CCLA upon request)
>
> I suggest you file one regardless.  Apache likes to see CCLAs for any
> non trivial donation.
>
> -dain
will do as soon as JIRA comes back up.
Filip

Triplesec JACC Provider

[Alex Karasulu]

D. Jencks,

Sorry for not contacting you sooner but I'm getting buried with things 
to do lately.  Although I've cleared all the IP for the Triplesec import 
I still have significant work remaining to actually complete the import.


I just wanted to give you some status on where I am in case you're 
wondering what happened.  I'm still very interested in starting on this 
JACC provider.  Perhaps things will clear up within the next week or too.


Regards,
Alex

Re: Help: Mapping to Apache Directory project's new groupId:artifactId

[Alex Karasulu]

Sorry I missed this email.  I was on vacation and focusing less on G 
emails these past few busy weeks. My mail filter put it in the Geronimo 
folder regardless of the addresses included.


The ApacheDS dependencies you guys are looking for are in the repo here:

http://www.ibiblio.org/maven2/org/apache/directory/

The latest release was 1.0-RC3.  We highly recommend using this latest 
release.


Alex


anita kulshreshtha wrote:

inline..

--- Prasad Kashyap <[EMAIL PROTECTED]> wrote:


If we don't use the  in our assembly descriptor to copy
the modules from the local repo to geronimo repo, then we won't see
this problem of an invalid pom. Since installing the car will install
almost all of the modules into the geronimo repository for us,





Which modules did not get installed?

Thanks
Anita


 we can

skip  for now. Moreover, I have learnt that using the
 to copy all modules into G repo was only a convenience
feature. It is not actually needed for the server to start.

So for now, we don't have to worry about moving to the latest apache
directory version. It doesn't affect our m2 migration work. But
eventually we will have to contend this issue and then we'll have to
map those 4 artifacts to their latest equivalents.

Thanx
Prasad

On 7/7/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:

Here's another idea. We could just fix the pom for
directory-protocols:ldap-protocol:0.9.2 and publish it to one of

our

repos. This will be a quick fix and we could get on with our

assembly

work. But we will be staying at whatever versions of the Apache
directory artifacts that we had in 1.1

I guess eventually we'll have to move to the latest version of

Apache

directory in our 1.2.

Cheers
Prasad

On 7/6/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:

Alex, Enrique,

The assembly of G in m2 is failing because we can't find valid

poms

for Apache directory artifacts. Our module geronimo-directory

depends

on apache directory artifacts. The Apache directory artifacts now

have

moved under the groupId "org.apache.directory"
http://www.ibiblio.org/maven2/org/apache/directory/

I have begun changing geronimo/directory/pom.xml to refelct the

new

groupId:artifactId of the Apache directory artifacts.

After those changes, the java code in geronimo-directory module

has to

be changed to reflect the new package names in the dependencies.

Below, you'll see an excerpt of the geronimo/directory/pom.xml

listing

the directory dependencies. I think I was able to map most of the
dependencies to the new groupId:artifactId. Please see comments

inline

and verify those.

I wasn't able to do so for the first 4 dependencies. Any help

there

would be appreciated.



directory-asn1
asn1-codec
${asn1Version}



directory-asn1
asn1-ber
${asn1Version}



directory-asn1
asn1-der
${asn1Version}



directory-shared
apache-ldapber-provider
${apachedsVersion}




org.apache.directory.server
apacheds-core
${apachedsVersion}



org.apache.directory.server

apacheds-core-shared
${apachedsVersion}



org.apache.directory.shared

shared-ldap
${apachedsVersion}



org.apache.directory.mina

mina-core
${minaVersion}



org.apache.directory.server

apacheds-kerberos-shared
${kerberosCommonVersion}



org.apache.directory.server

apacheds-protocol-kerberos
${kerberosProtocolVersion}



org.apache.directory.server

apacheds-protocol-ldap
${ldapProtocolVersion}





__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Directory Update (Jeff?)

[Alex Karasulu]

Alexei,

Sorry but we have not looked back after the M2 conversion.   Our poms 
have changed much since then because of transitive deps so it would take 
a significant effort to produce the M1 poms again.


Really wish we had a tool for this.

Regards,
Alex

Alexei Zakharov wrote:

BTW, Alex, are there plans to propagate ADS jars to maven1 repo?
Geronimo 1.1 currently supports maven1 only.

Thanks,

2006/5/6, Alexei Zakharov <[EMAIL PROTECTED]>:

Alex,

Oh, I've been searching in old "directory" and "directory-network"
groups rather than "org/apache/directory/server/apacheds-core". Thank
you for pointing the right group id.

2006/5/5, Alex Karasulu <[EMAIL PROTECTED]>:
> Alexei Zakharov wrote:
> > Hi,
> >
> > I have created a patch to move the G directory module to ApacheDS 
1.0

> > RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at
> > /maven nor at /maven2. The most recent version is 0.9.3. The same
> > situation for MINA. So I can't post the patch right now since it 
will

> > not work without these jars.
> > Alex, I just want to let you know about this situation.
> >
> Hmmm I'm seeing the RC2 jars just fine.  Take a look here at the core
> jar for example:
>
> 
http://www.ibiblio.org/maven2/org/apache/directory/server/apacheds-core/1.0-RC2/ 


>
> Also MINA stuff is here:
>
> 
http://www.ibiblio.org/maven2/org/apache/directory/mina/mina-core/0.9.4/

>
> HTH,
> Alex
>
>
> > 2006/4/24, Alex Karasulu <[EMAIL PROTECTED]>:
> >> Aaron Mulder wrote:
> >> > I know 0.9.3 is there (in the /maven2 repo).  Not sure about 
the RC's.

> >> >
> >> Ya all including RC1 should be in the M2 repo if not let me know.
> >>
> >> Alex
> >> > Thanks,
> >> >  Aaron
> >> >
> >> > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
> >> >
> >> >> Alex,
> >> >>
> >> >> Can you get the jars in ibiblio and I can get the integration
> >> going?  I
> >> >> am only seeing 0.9.2 in ibiblio at the moment.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Jeff
> >> >>
> >> >> Alex Karasulu wrote:
> >> >>
> >> >>> Jeff Genender wrote:
> >> >>>
> >> >>>> If the changes are not huge, I can probably do it.  Alex, 
are the

> >> >>>> updates significant?
> >> >>>>
> >> >>> Since 0.9.2 I'd say RC1 is a significant update.  There are
> >> package name
> >> >>> changes to comply with Directory's TLP domain name which are
> >> perhaps the
> >> >>> most significant changes.  There are changes to a couple
> >> dependencies.
> >> >>> For the most part the code has been cleaned up and several
> >> *severe* bugs
> >> >>> have been corrected and tested.  RC1 is also an order of
> >> magnitude faster.
> >> >>>
> >> >>> We plan to get another 1.0 release candidate (RC2) out soon
> >> perhaps by
> >> >>> the end of this week coming week or week there after.  But
> >> looking at
> >> >>> emails out there from Dain and Aaron it sounds to me like the
> >> update to
> >> >>> G can take place any time after the 1.1 release.  Let us 
know if you

> >> >>> have any problems or need a hand while performing an upgrade
> >> either to
> >> >>> RC1 or RC2 when it comes out.
> >> >>>
> >> >>> Regards,
> >> >>> Alex

Re: Directory Update (Jeff?)

[Alex Karasulu]

Alexei Zakharov wrote:

Hi,

I have created a patch to move the G directory module to ApacheDS 1.0
RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at
/maven nor at /maven2. The most recent version is 0.9.3. The same
situation for MINA. So I can't post the patch right now since it will
not work without these jars.
Alex, I just want to let you know about this situation.

Hmmm I'm seeing the RC2 jars just fine.  Take a look here at the core 
jar for example:


http://www.ibiblio.org/maven2/org/apache/directory/server/apacheds-core/1.0-RC2/

Also MINA stuff is here:

http://www.ibiblio.org/maven2/org/apache/directory/mina/mina-core/0.9.4/

HTH,
Alex



2006/4/24, Alex Karasulu <[EMAIL PROTECTED]>:

Aaron Mulder wrote:
> I know 0.9.3 is there (in the /maven2 repo).  Not sure about the RC's.
>
Ya all including RC1 should be in the M2 repo if not let me know.

Alex
> Thanks,
>  Aaron
>
> On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
>
>> Alex,
>>
>> Can you get the jars in ibiblio and I can get the integration 
going?  I

>> am only seeing 0.9.2 in ibiblio at the moment.
>>
>> Thanks,
>>
>> Jeff
>>
>> Alex Karasulu wrote:
>>
>>> Jeff Genender wrote:
>>>
>>>> If the changes are not huge, I can probably do it.  Alex, are the
>>>> updates significant?
>>>>
>>> Since 0.9.2 I'd say RC1 is a significant update.  There are 
package name
>>> changes to comply with Directory's TLP domain name which are 
perhaps the
>>> most significant changes.  There are changes to a couple 
dependencies.
>>> For the most part the code has been cleaned up and several 
*severe* bugs
>>> have been corrected and tested.  RC1 is also an order of 
magnitude faster.

>>>
>>> We plan to get another 1.0 release candidate (RC2) out soon 
perhaps by
>>> the end of this week coming week or week there after.  But 
looking at
>>> emails out there from Dain and Aaron it sounds to me like the 
update to

>>> G can take place any time after the 1.1 release.  Let us know if you
>>> have any problems or need a hand while performing an upgrade 
either to

>>> RC1 or RC2 when it comes out.
>>>
>>> Regards,
>>> Alex



--
Alexei Zakharov,
Intel Middleware Product Division

Re: Directory Update (Jeff?)

[Alex Karasulu]

Aaron Mulder wrote:

I know 0.9.3 is there (in the /maven2 repo).  Not sure about the RC's.
  

Ya all including RC1 should be in the M2 repo if not let me know.

Alex

Thanks,
 Aaron

On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
  

Alex,

Can you get the jars in ibiblio and I can get the integration going?  I
am only seeing 0.9.2 in ibiblio at the moment.

Thanks,

Jeff

Alex Karasulu wrote:


Jeff Genender wrote:
  

If the changes are not huge, I can probably do it.  Alex, are the
updates significant?


Since 0.9.2 I'd say RC1 is a significant update.  There are package name
changes to comply with Directory's TLP domain name which are perhaps the
most significant changes.  There are changes to a couple dependencies.
For the most part the code has been cleaned up and several *severe* bugs
have been corrected and tested.  RC1 is also an order of magnitude faster.

We plan to get another 1.0 release candidate (RC2) out soon perhaps by
the end of this week coming week or week there after.  But looking at
emails out there from Dain and Aaron it sounds to me like the update to
G can take place any time after the 1.1 release.  Let us know if you
have any problems or need a hand while performing an upgrade either to
RC1 or RC2 when it comes out.

Regards,
Alex

  


  

Re: Directory Update (Jeff?)

[Alex Karasulu]

Jeff Genender wrote:
If the changes are not huge, I can probably do it.  Alex, are the 
updates significant?
Since 0.9.2 I'd say RC1 is a significant update.  There are package name 
changes to comply with Directory's TLP domain name which are perhaps the 
most significant changes.  There are changes to a couple dependencies. 
For the most part the code has been cleaned up and several *severe* bugs 
have been corrected and tested.  RC1 is also an order of magnitude faster.


We plan to get another 1.0 release candidate (RC2) out soon perhaps by 
the end of this week coming week or week there after.  But looking at 
emails out there from Dain and Aaron it sounds to me like the update to 
G can take place any time after the 1.1 release.  Let us know if you 
have any problems or need a hand while performing an upgrade either to 
RC1 or RC2 when it comes out.


Regards,
Alex

Re: Directory Update (Jeff?)

[Alex Karasulu]

You guys have time for the latest RC2 release of Directory?  We could 
push this release for G to get a bunch of fixes and performance 
enhancements in there.


Alex

Jeff Genender wrote:

Yeah, I can take a look.

Jeff

Aaron Mulder wrote:

All,

While working on the plugins I found that our Directory is out of date
(0.9.2 vs latest 0.9.3 on iBiblio).  I also found that if we just
"take the latest of everything Directory-related" it blows up (in
particular, mina 0.9.0 doesn't work, but 0.8.2 appears to).

Can someone test a good combination of all the Directory-related libs
and update our etc/project.properties accordingly?

Jeff, I think you did the original Directory integration, I'm not sure
if you want to bite on this.

It's not a huge deal if we ship G 1.1 a point release of Directory
behind, but it would be nice if we could update.

Thanks,
Aaron

Re: Embedded LDAP Server Viewer Portlet

[Alex Karasulu]

Chris Cardona wrote:

Hello Alex,

Thanks for offering some help. My idea for this
portlet is a simple way of viewing the contents of the
ApacheDS. A tree widget will be used to navigate the
entries and a table to list attributes of an entry. I
also intend to add a way to do ldap searches and
refesh data. 
Nice! You could also use persistent search with JNDI notifications to 
update your UI if other external clients change the DIT.  ApacheDS 
supports this control.   Added it myself I think in 1.0-RC1.  We need to 
get G up to date with the latest and greatest tho.

If would be nice to include a way to add
and modify entries. Not sure if ApacheDS includes APIs
to accomplish such tasks (e.g. process an ldif file
for adding entries, etc). 
There is a server side JNDI provider that mimics an on the wire LDAP 
JNDI provider but taps directly into the database for requests.  But I'd 
recommend just using simple JNDI LDAP connectivity with a local socket 
to the server just for now until some of the classloader issues are 
clear between ADS and G.  If designed properly you can just plugin the 
serverside provider in place of the SUN JNDI provider later.

Please let me know if you
have other ideas for this portlet so we can coordinate
work.
  
Sure will do.  Some ideas that occurred to me are doing LDIF imports and 
exports.  This is pretty easy to do once you have the UI setup though.  
Keep me updated on your progress.  This is exciting.


Alex


Thanks,
Chris


--- Alex Karasulu <[EMAIL PROTECTED]> wrote:

  

Chris Cardona wrote:


Hello All (Aaron, Joe, Paul),

I would like to work on a new portlet for the
  

console


which can be used to view/explore the contents of
  

the


embedded LDAP server (Apache DS). This can be
  

added


under Misc > Embedded LDAP Server. I plan to use
  

Dojo


javascript toolkit and DWR to accomplish this
  

task.


Since we are already using DWR for our Ajax stuff
  

my


only question is the use of Dojo. Is it ok to
  

include


Dojo to the console? Your comments and suggestions
  

are


most welcome.
  
  

Let us know what we can do to help with this.  We
were also working on 
UI tools for ApacheDS so I think there can be good
collaboration here.  
It would be nice to be able to run this GUI both in
Geronimo and within 
an embedded Jetty instance running inside a

standalone ApacheDS server.

I've CC'd a couple people who have been interested
in doing this.  
Excuse the cross post to [EMAIL PROTECTED]


Regards,
Apache Directory Team







__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

  

Re: Embedded LDAP Server Viewer Portlet

[Alex Karasulu]

Chris Cardona wrote:

Hello All (Aaron, Joe, Paul),

I would like to work on a new portlet for the console
which can be used to view/explore the contents of the
embedded LDAP server (Apache DS). This can be added
under Misc > Embedded LDAP Server. I plan to use Dojo
javascript toolkit and DWR to accomplish this task.
Since we are already using DWR for our Ajax stuff my
only question is the use of Dojo. Is it ok to include
Dojo to the console? Your comments and suggestions are
most welcome.
  
Let us know what we can do to help with this.  We were also working on 
UI tools for ApacheDS so I think there can be good collaboration here.  
It would be nice to be able to run this GUI both in Geronimo and within 
an embedded Jetty instance running inside a standalone ApacheDS server.


I've CC'd a couple people who have been interested in doing this.  
Excuse the cross post to [EMAIL PROTECTED]


Regards,
Apache Directory Team

Re: [Apache DS] Shall we go JDK 1.5 in 1.1 branch

[Alex Karasulu]

John Sisson wrote:

Alex,

Cross posting to [EMAIL PROTECTED] since Geronimo has been mentioned a 
few times in this thread.


AFAIK the statement below that Geronimo's latest development branch 
will use JDK 1.5 does not reflect past discussions on the [EMAIL PROTECTED] 
thread  http://thread.gmane.org/gmane.comp.java.geronimo.devel/22157 
.  Where JEE 5 support will be developed is yet to be decided.


Can you confirm that you are proposing that both Apache DS 1.0, 1.1 & 
1.2 will be embeddable in Geronimo on JDK 1.4.2 .

Hiya John,

Yes you are right.  Both stable (GA) releases of ApacheDS, 1.0 and 1.2, 
will be JDK 1.4 compatible.  A jump to JDK 5 is probably a year out.  In 
any case, we will make sure we provide 1.4 JDK compatibility with a 
living GA branch for Geronimo and JetSpeed.  A JDK 5 minimum requirement 
would appear with a 2.0 release of ApacheDS.  Apache 2.0 will not 
necessarily kill the latest 1.x branch.


Note that 1.0 is not even released yet.  So in other words, I would not 
worry too much :).  We still have much work to do.  However I did make a 
mistake thinking Geronimo's JEE 5 support was going to be J2SE 5.0 
based.  My bad.


Please excuse the confusion,
Alex


Thanks,

John

Alex Karasulu wrote:

I was going to write a long email about this but let me condense it.
(1) JDK 1.4 and up is supported for all user types (including 
embedding users) in 1.0 branch and this will never change.  This 
branch is alive and well and will be maintained with bug fixes.  
There already are features in this branch that are 1.5 specific and 
you can get those by adding some extra "components" but must run them 
on JDK 1.5 (SSL is the only JDK 1.5 requirement at this point).


(2) The 1.1 branch is an experimental/feature addition branch.  Even 
Geronimo will not look back and will use JDK 1.5 for there latest 
development branch.  Does this mean we have to?  Not necessarily.  
This branch will most likely add compliance with OpenGroup.  It will 
also introduce enhancements for performance in the database, DN 
handling and in the asn1 subsystems.  This branch will release often 
hopefully but that does not mean users should use it.  The real 
culmination of this branch will be the stable release of 1.2.  This 
will take 4-6 months at a minimum.  In that time more users will be 
on JDK 1.5 but we will still have most users on 1.4.


(3) A clean break is always better than a half assed job period.  
However we need to get our timing straight.  That's all this JDK 
discussion is really about.  So we have to pick just when we make 
this jump.


So now here's my opinion:

(a) MINA sticks to 1.4 support without messing with byte code and 
experiments with retroweaver.  She should release a 1.0 and have a 
solid stable API for 1.4 and 1.5 support.  At this point I'd like to 
see mina graduate incubation and start a new branch 1.1 which focuses 
on JDK1.5 with mina 1.0 as 1.4 fall back.  This can occur in about 
4-6 months IMHO.


(b) ApacheDS sticks to 1.4 support in the 1.1 and 1.2 branches.  For 
1.5 needs it juggles new components and leverages OSGi to help manage 
this.  SASL, SSL, Crypto libs and other features that may need 1.5 
can load 1.5 specific bundles to do this.  This sucks and is going to 
be a pita for us the developers but we can do it and we have OSGi to 
help. At this point 1.0 dies and 1.2 becomes the main supported branch.
(c) Once MINA graduates and starts work on a pure JDK 1.5+ branch we 
can start a new experimental branch for ApacheDS, branch 1.5 skipping 
1.3 altogether.  Here we redesign the server to use all 1.5 
features.  The design/architecture and readability, maintainability 
greatly improves.  We then bump up the GA release branch to 2.0.  
This is a year out in the making.  Plus it will coincide with mina 
1.1 or whatever we choose it to be designated as for jdk 1.5 
support.  At this point we can decide to kill 1.2 or to keep on 
supporting bug fixes in it for 6 more months (recommended) until SUN 
puts an EOL on jdk 1.4.



Summary
===

(1) Users are happy, embedding and standalone users
(2) Developers deal with the burden but use OSGi to alleviate the pain
(3) We have a clean manageable break which will make life bearable
(4) MINA progresses forward with 1.0 and 1.1 jdk 5 support with a 
nice clean break and gets a new home as it should
(5) ApacheDS 1.2 will pretty much have the same functionality as 2.0 
so there will be little complains.  The server will just be 
redesigned to make it easier for developers.  There is only so much 
you can do with LDAP, DNS and Kerberos.


DHCP is another story but we can talk later about this one.

Heh we can deal later with these headaches 1.6 will bring a year from 
now.


Cheers,
Alex

P.S. Can we agree on this and forge ahead please?

Re: [ApacheDS] Requesting feedback on ApacheDS move to JDK 1.5

[Alex Karasulu]

John Sisson wrote:


Alex Karasulu wrote:


Hi all,

Over at Directory we're discussing the use of JDK 1.5 specific API's 
for some critical functionality needed for a 1.0 release of the 
directory server.  We find ourselves in a Catch-22 where LDAPv3 
compliance requires support for SSL and SASL.  Use of these API's 
would make ApacheDS 1.4 incompatible.  We are currently looking for 
alternatives so embedding projects like Geronimo are not affected.



I had a quick look at http://www.ietf.org/rfc/rfc2251.txt and it says 
SASL mechanisms *may* be used with LDAP.  Is it possible to just 
support simple authentication and not require the use of SASL if 
running on JDK 1.4?


Actually other RFCs since then have come out to basically say that you 
need either SSL or SASL.  If you're curious you can look at the RFC here 
http://www.faqs.org/rfcs/rfc2829.html which talks about this.


Alex

Re: [ApacheDS] Requesting feedback on ApacheDS move to JDK 1.5

[Alex Karasulu]

Jeff Genender wrote:


-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED] 

   

Also is there a way in which ApacheDS integration can be made 
pluggable and available when running under a 1.5 JVM?


   



Please explain your question.  Currently it is pluggable (via the Gbean),
but I think I need to understand your question a little better.
 

I was wondering if a runtime decision can be made to load ApacheDS or 
not based on the version of the JVM.  I guess this is more a 
configuration time option rather than runtime pluggability?


Alex

[ApacheDS] Requesting feedback on ApacheDS move to JDK 1.5

[Alex Karasulu]

Hi all,

Over at Directory we're discussing the use of JDK 1.5 specific API's for 
some critical functionality needed for a 1.0 release of the directory 
server.  We find ourselves in a Catch-22 where LDAPv3 compliance 
requires support for SSL and SASL.  Use of these API's would make 
ApacheDS 1.4 incompatible.  We are currently looking for alternatives so 
embedding projects like Geronimo are not affected.


If we have no choice but to use 1.5 APIs in future releases of ApacheDS 
what impact will this have on Geronimo?


Does Geronimo run on JDK 1.5?  If so is binary compatibility with 1.4 a 
requirement?  (I'm guessing yes.)


Also is there a way in which ApacheDS integration can be made pluggable 
and available when running under a 1.5 JVM?


Thanks,
Alex

Re: Kernel now JMX free

[Alex Karasulu]

Hi,
I'm ignant so in lay terms what is it that we have here?  A generic 
server side platform? An IoC container?

Could someone elaborate a lil bit more on the evolution that is taking 
place or point me to any documentation.  It's very interesting and I'm 
curious about the big picture.

Alex
David Blevins wrote:
Woohooo!
-David
On Mon, Dec 06, 2004 at 10:53:59PM -0800, Dain Sundstrom wrote:
 

Last night I committed the changes to the Kernel to remove the 
dependencies on JMX.  The Kernel still uses ObjectName and 
MalformedObjectNameException, and those will go when we add GBeanName.  
My change notes follow:

Kernel is not totally decoupled from JMX.  By default the kernel will 
no longer boot an MBeanServer.  The only place we boot the MBean server 
is when we are booting a full blown long running Geronimo server.

Introduced GBeanRegistry which manages the map ObjectName to 
GBeanInstance.

Added BasicGBeanRegistry which manages the map with no dependency on 
JMX.

Added JMXGBeanRegistry which creates an MBeanServer on startup.  It 
mounts a o.a.g.kernel.jmx.GBeanMBean into an MBeanServer for each 
GBeanInstance registered.  The a o.a.g.kernel.jmx.GBeanMBean does not 
interact directly with GBeanInstances, instead it simply redirects all 
calls to a GBean.  GBeanMBean in the o.a.g.gbean.jmx package is just a 
proxy for a GBeanData, and should be removed soon.

Added KernelDelegate which replaces the MBeanServerFactory use on the 
client side to create a proxy to the server side geronimo kernel.

Added MBeanServerDelegate which is used to provide apis such as the JSR 
88 MEJB which needs a something that implements MBeanServer.  The 
MBeanServerDelegate only implements the operations of the MBeanServer 
that easily map to Kernel.  All unimplemented methods throw a 
SecurityException.

Moved Lifecycle* classes to o.a.g.kernel.lifecycle
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
   

 

Re: adding support for pluggable authenticators (HTTP) (adding support for SPNEGO/Kerberos)

[Alex Karasulu]

Alan D. Cabrera wrote:
Actually, maybe writing a SPNEGOHandler would do the trick.
 

You go dawg!
Regards,
Alan
 

RE: Eve integration with Geronimo

[Alex Karasulu]

James,

Sorry for taking so long to get back to you.  

On Fri, 2004-09-10 at 16:05, [EMAIL PROTECTED] wrote:
> Hey Alex
> 
>  > From: Alex Karasulu <[EMAIL PROTECTED]>
>  > Also we have begun to separate out frontend plumbing from LDAP  
> specific code in Eve's frontend.  This code is a TCP specific SEDA  
> framework.
>  > We're going to make this into a subproject on its own so we can reuse  
> it for a Eve integrated Kerberos server without tight coupling (it can  
> also be
>  > standalone).  Trustin Lee (guy who did Netty) will be looking into  
> adding UDP support to this in project.
>  >
>  > So what does this all mean for integration?  Well we want to write  
> wrappers for this SEDA framework where Eve just plugs in as another  
> simple
>  > protocol to be able to benefit from those wrappers.  By writing a  
> geronimo wrapper for SEDA rather than an Eve specific frontend we now  
> allow any
>  > protocol to be fired up within geronimo without having to  
> specifically integrate that protocols frontend.  WDYT?
>  >
>  > So we really want to write a SEDA framework wrapper intead of one  
> specifically for Eve.  This also makes me think if its worth writting  
> wrappers for the > backend of Eve and this raises several questions I  
> still don't have answers to but these I'll leave for other emails.
> 
> I guess it depends what you mean by SEDA. Mostly I tend to think of the  
> Channel abstraction in the concurrent.jar as being a pretty good  
> abstraction for SEDA, where the channels can be local in VM or remote  
> and you can put/take/poll objects - then the rest is just  

That's cool stuff for doing scatter gather like operations where a
rendezvous point is needed.  Looking back on Matt Welsh's paper on SEDA
I can see how this is just a queue within a stage. 

> implementation details. Or some folks like to abstract away the low  
> level SEDA like protocol of sync/async send behind a dynamic proxy to  
> make SEDA invisible as it were. e.g.
> 
> http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/util/
> AsyncProxy.html

This is a bit of a stretch but it does capture some of the sync/async
points.

> If what you mean is more of a SEDA based transport framework, well  
> we've been working for quite some time on one of those on the ActiveMQ  
> project :). Last benchmark we did was 22,000 messages/second sustained  
> throughput on 2 2-way linux boxes with producer, broker, consumer all  
> going across the network for 1-2K message sizes and reasonably low CPU  
> usage (YMMV).

That's pretty impressive.  I definately will have a look through the
code there and most likely will be using ActiveMQ for the messaging
abstraction in LDAP replication ;).

> Currently we've transports for
> 
> * VM (in memory both sync & true SEDA)
> * TCP / SSL
> * UDP & multicat
> * NIO through g-networks and EmberIO
> * JGroups
> * JRMS
> * JXTA
> * HTTP (for tunnelling)
> * Jabber (experimental)
> * AIO4J (experimental)

That's really cool.  I especially need to take a look at the UDP code.  



> Details of the code are here...
> 
> http://activemq.codehaus.org/Code+Overview
> 

Ahhh this TransportChannel abstraction is exactly what Trustin and I
have been talking about using for the SEDA stuff here.  Looks like we
can borrow from what you've already done.  See right now we only do TCP
and have not needed the abstraction.  Now we do.  Seeing you using this
makes us feel a little better about the common path we've selected.

> Basically we have a really simple TransportChannel API which can  
> represent any kind of transport protocol.
> 
> http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/
> transport/package-summary.html

This is excellent!

> The minimal contract we support for application protocols is that they  
> must decide if a method call is sync (requiring a receipt such as a  
> commit()) or async (fire & forget) and for async, whether a flush is  
> required after the send. Consuming is pluggable based on the transport  
> - so it decides if there is a thread, is it pull/push or how threads  
> multiplex such as for NIO / AIO.

Right following ya!  We've actually put in very similar hooks into the
stages for handling encoding and decoding.  There are two ways to
process IO as it is delivered sync or asynch.  This is reflected in the
interfaces use on these stages.  This is very similar to the send() and
asyncSend() methods you have.

> Most of the transport channels can be reused as is with a pluggable  
> WireFormat which dictates how command objects (we use the Packet base  
> class) get serialized on the wire. e.g. we have a defau

Re: RE: Eve integration with Geronimo

[Alex Karasulu]

Hey James,

I'm still processing all this to see what we can use and how best we can 
integrate.  Thanks for taking the time to write such a thorough email.  I'll 
get back to you shortly.

Alex

> From: [EMAIL PROTECTED]
> Date: 2004/09/10 Fri PM 04:05:40 EDT
> To: [EMAIL PROTECTED]
> Subject: RE:  Eve integration with Geronimo
> 
> Hey Alex
> 
>  > From: Alex Karasulu <[EMAIL PROTECTED]>
>  > Also we have begun to separate out frontend plumbing from LDAP  
> specific code in Eve's frontend.  This code is a TCP specific SEDA  
> framework.
>  > We're going to make this into a subproject on its own so we can reuse  
> it for a Eve integrated Kerberos server without tight coupling (it can  
> also be
>  > standalone).  Trustin Lee (guy who did Netty) will be looking into  
> adding UDP support to this in project.
>  >
>  > So what does this all mean for integration?  Well we want to write  
> wrappers for this SEDA framework where Eve just plugs in as another  
> simple
>  > protocol to be able to benefit from those wrappers.  By writing a  
> geronimo wrapper for SEDA rather than an Eve specific frontend we now  
> allow any
>  > protocol to be fired up within geronimo without having to  
> specifically integrate that protocols frontend.  WDYT?
>  >
>  > So we really want to write a SEDA framework wrapper intead of one  
> specifically for Eve.  This also makes me think if its worth writting  
> wrappers for the > backend of Eve and this raises several questions I  
> still don't have answers to but these I'll leave for other emails.
> 
> I guess it depends what you mean by SEDA. Mostly I tend to think of the  
> Channel abstraction in the concurrent.jar as being a pretty good  
> abstraction for SEDA, where the channels can be local in VM or remote  
> and you can put/take/poll objects - then the rest is just  
> implementation details. Or some folks like to abstract away the low  
> level SEDA like protocol of sync/async send behind a dynamic proxy to  
> make SEDA invisible as it were. e.g.
> 
> http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/util/ 
> AsyncProxy.html
> 
> 
> If what you mean is more of a SEDA based transport framework, well  
> we've been working for quite some time on one of those on the ActiveMQ  
> project :). Last benchmark we did was 22,000 messages/second sustained  
> throughput on 2 2-way linux boxes with producer, broker, consumer all  
> going across the network for 1-2K message sizes and reasonably low CPU  
> usage (YMMV).
> 
> Currently we've transports for
> 
> * VM (in memory both sync & true SEDA)
> * TCP / SSL
> * UDP & multicat
> * NIO through g-networks and EmberIO
> * JGroups
> * JRMS
> * JXTA
> * HTTP (for tunnelling)
> * Jabber (experimental)
> * AIO4J (experimental)
> 
> In addition we have discovery protocols (Zeroconf & ActiveCluster) to  
> make peer-style clusters of auto-discoverying clients & servers  
> (Zeroconf is particularly cute as it works nice with Apple's  
> Rendezvous), together with load balancing & fault tolerance transports  
> (e.g. auto-fail over to another server in case of failure etc).
> 
> Other protocols to come are SOAP-over-TCP, FTP,  SMTP, SQL and file  
> system when we get chance.
> 
> Details of the code are here...
> 
> http://activemq.codehaus.org/Code+Overview
> 
> 
> Basically we have a really simple TransportChannel API which can  
> represent any kind of transport protocol.
> 
> http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/ 
> transport/package-summary.html
> 
> 
> The minimal contract we support for application protocols is that they  
> must decide if a method call is sync (requiring a receipt such as a  
> commit()) or async (fire & forget) and for async, whether a flush is  
> required after the send. Consuming is pluggable based on the transport  
> - so it decides if there is a thread, is it pull/push or how threads  
> multiplex such as for NIO / AIO.
> 
> Most of the transport channels can be reused as is with a pluggable  
> WireFormat which dictates how command objects (we use the Packet base  
> class) get serialized on the wire. e.g. we have a default, fast as  
> possible, wire format for the JMS Packets, as well as Jabber & XStream  
> based ones etc.
> 
> The TransportChannel abstract represents about the 8th or 9th  
> generation of this kind of abstraction the team have used over the last  
> 5 years or so for implementing high performance messaging & SEDA  
> transport abstractions - so if nothing else, I'd advise you to go down  
> a similar route of abstraction; then at the very least you'll be able  
> to reuse our transports easily & we can easily plugin into your stuff -  
> especially if you want to take advantage of our clustering, failover &  
> replication protocols..
> 
> James
> ---
> http://radio.weblogs.com/0112098/
> 
> 

Re: RE: Eve integration with Geronimo

[Alex Karasulu]

Hey guys,

As a Hurricane refugee (sounds weird saying that) I have no dependable internet 
connectivity so I appologize for getting to these emails so late.  And thank 
you Noel for letting people know.

Now for Geronimo integration Alan and I had discussed making some components 
into GBeans.  We were debating whether or not to make the entire server into 
one GBean or to make all services in the server into a GBean.  To show how that 
is done Alan whiped together a few wrappers for all the services here:

http://svn.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/frontend/geronimo/?root=Apache-SVN

But after he did this we began thinking the single GBean approach for all of 
Eve may be better.  So with Alan's examples I think one of us can pick up the 
torch and write a single wrapper pretty easily for plugging into Geronimo.

There are however some considerations.  We have begun to decouple the backend 
code from Avalon and will have pure pojos with Avalon wrappers.  This must 
happen before the backend can be integrated as well as the frontend code.  

Also we have begun to separate out frontend plumbing from LDAP specific code in 
Eve's frontend.  This code is a TCP specific SEDA framework.  We're going to 
make this into a subproject on its own so we can reuse it for a Eve integrated 
Kerberos server without tight coupling (it can also be standalone).  Trustin 
Lee (guy who did Netty) will be looking into adding UDP support to this in 
project.  

So what does this all mean for integration?  Well we want to write wrappers for 
this SEDA framework where Eve just plugs in as another simple protocol to be 
able to benefit from those wrappers.  By writing a geronimo wrapper for SEDA 
rather than an Eve specific frontend we now allow any protocol to be fired up 
within geronimo without having to specifically integrate that protocols 
frontend.  WDYT?  

So we really want to write a SEDA framework wrapper intead of one specifically 
for Eve.  This also makes me think if its worth writting wrappers for the 
backend of Eve and this raises several questions I still don't have answers to 
but these I'll leave for other emails.

Hope that helps,
Alex


> From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> Date: 2004/09/10 Fri AM 12:26:39 EDT
> To: <[EMAIL PROTECTED]>
> CC: "Apache Directory Developers List" <[EMAIL PROTECTED]>
> Subject: RE: Eve integration with Geronimo
> 
> Alan D. Cabrera wrote:
> > Alex Karasulu is working on it.  I suspect that it will be
> > completed soon.  Alex?
> 
> Small matter of something called a hurricane has Alex off-line at the
> moment.
> 
>   --- Noel
> 
> 

Re: Javamail license

[Alex Karasulu]

Dain,

Don't know for sure but I thought the James folks were working on a java
mail implementation.  Perhaps its worth checking this out.  Noel might
be able to elaborate on this.

Alex

On Tue, 2004-07-13 at 22:56, Dain Sundstrom wrote:
> I know Geir has been working on this, but it popped up on my radar 
> again... I think we have a serous problem with Javamail unless sun is 
> willing to relicense it.  The license is here 
> http://java.sun.com/products/javamail/LICENSE.txt
> 
> I think the biggest problem for us is this section (near the bottom):
> 
> (vi) you agree to defend and indemnify Sun and its licensors from and 
> against any
> damages, costs, liabilities, settlement amounts and/or expenses 
> (including
> attorneys' fees) incurred in connection with any claim, lawsuit or 
> action by
> any third party that arises or results from the use or distribution of 
> any
> and all Programs and/or Software.
> 
> 
> Does the ASF allow us to ship software from ASF servers that contain 
> dependencies that have this kind of language?
> 
> -dain
> 

Re: Integrating Spring into Geronimo

[Alex Karasulu]

On Tue, 2004-06-29 at 15:09, Colin Sampaleanu wrote:
> This is seriously cool!

Oh yeah!

> [EMAIL PROTECTED] wrote:
> 
> > Dion let the cat out of the bag...
> >
> > http://www.almaer.com/blog/archives/000246.html
> >
> > Basically we've a GBean for Geronimo so that any existing spring XML 
> > config file can be slurped up & turned into beans and managed in a JSR 
> > 77/88 way & hot deployed - so Geronimo can hot deploy arbitrary Spring 
> > containers within the core J2EE container - all managed in the same 
> > stack as web apps, web containers, EJB containers etc. We should also 
> > be able to JMX-ifiy all the beans as they are created into the JSR 
> > 77/88 management stack.



> > Going forward we should be able to further increase the functionality 
> > of the SpringGBean to closer integrate the two projects so that the 
> > Spring POJOs can take better, more efficient & easier use of the J2EE 
> > services in Geronimo (transactions, security, remoting, pooling, 
> > clustering etc).

That would really be worth while because then these components need not
roll their own redundant utilities like thread pools etcetera.  If these
and other services that are already part of Geronimo's scaffolding could
be accessible to the spring components then that would be most
wonderful.  

Just as a feeler how far off is all this from being mature and
available?

Alex