You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Knystautas <se...@lokitech.com> on 2002/04/18 00:12:55 UTC
Avalon.die.die.die
I don't know if I can take much more of Avalon. I've lost so much
interest in working on James because of the problems that arise from
using Avalon, and am nearing my last straw this afternoon.
The latest problem with our use of Avalon is that if you have any open
connections when you try to stop the JVM, it hangs and has to be
forcibly stopped. I thought the whole reason behind migrating to Avalon
was so that we didn't have to deal with underlying threading,
configuration, object pooling, database sources, connection handling,
logging, and other server related issues. Unfortunately, none of the
features are implemented that wonderfully, the platform continually
moves from one pre-alpha release to another, there are regular huge
arguments on the dev mailing list about what latest pre-pre-alpha
component should be added next to the already uncertain platform, and
meanwhile the James project is stuck working again and again on stuff
that was already working before we ported to Avalon years ago.
Sorry, I'm just really really tired of this stuff. Since there aren't
any real official releases of Avalon, should we just do another
snapshot? Or maybe just branch the code, import it into James so we can
gain control over our project again?
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
> Nonetheless, I'd like to offer my services to bring you completely up to
> date with released Avalon comps.
+1 on that.
> Tonight, while you folks mull the offer, I am going to create a block
> wrapper for this Tomcat wrapper :-
> http://freshmeat.net/projects/mintc/?topic_id=92%2C259%2C250
> How would you feel about a web server in the same SAR file ? Another
> day perhaps....
I think it is a really good idea, although (plug) it would be a even a
better idea, if you used this SSL library for secure server access. :-)
http://ssllib.sourceforge.net. Here is the readme, if I have your attention.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ssllib/jsrc/README?rev=1.1&co
ntent-type=text/vnd.viewcvs-markup
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Serge Knystautas <se...@lokitech.com>.
I also wanted to mention that all of next week I'll be on vacation and
while I'll be checking email, it probably won't be very regularly and I
don't expect to be working on any James code.
California here I come!
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Paul Hammant wrote:
> Serge,
>
> OK thanks for backing down, coming clean re the need for the pub... ;-)
>
> Nonetheless, I'd like to offer my services to bring you completely up to
> date with released Avalon comps. I'll also try to get a release of
> Phoenix done (it moves a little each month) and of Cornerstone (has
> hardly moved in months). I reckon it will take me a day to do. I'll
> propose Saturday (if you guys can stay clear of the CVS).
> I'd like to do it in this style
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/eob/eob/ where there is
> greater separation between the jars that Phoenix needs and the jars that
> JAMES needs. This will help a newbie see what is actually needed for
> JAMES compilation. I am adept at build scripts and will leave you in a
> position where all the targets (that work currently) continue to work.
> What will follow, hopefully in a week or so would be the release
> versions of the things that are release versions. What I have done with
> EOB is take the Phoenix verison from CVS after a "build dist-lite"
> build. The layout that gives is the same as that I have booked into CVS
> of EOB.
>
> Of course, there is a lot to consider here. You have every right to
> veto or decline, but the offer is tabled.
>
> Tonight, while you folks mull the offer, I am going to create a block
> wrapper for this Tomcat wrapper :-
> http://freshmeat.net/projects/mintc/?topic_id=92%2C259%2C250
> How would you feel about a web server in the same SAR file ? Another
> day perhaps....
>
> Regards,
>
> - Paul H
>
>
>> Peter and Paul,
>>
>> Thank you for responding so calmly. Regardless of my points, I should
>> have just walked to the nearby bar before writing that kind of a
>> message, and I appreciate your positive responses.
>>
>> I'm glad to see Avalon is making some releases. I see the latest in
>> code James CVS reporting "Phoenix 4.0a4" and a bunch of timestamped
>> avalon jars. I don't see where Avalon-Phoenix is "currently shipping
>> a beta"... both freshmeat and jakarta show 4.0a1-a3 and latest. If
>> there is a release, that's great and we should probably upgrade.
>>
>> On that note, what would really help me from Avalon would be
>> concrete/complete releases. What I would like in a release would be a
>> main jar, dependent jars, source code, javadocs, and ideally a branch
>> in CVS. I'm used to drilling from James' code to Avalon-Phoenix to
>> Avalon-Cornerstone, etc..., that's fine and expected... I like to do
>> that and that's a big reason why I use open source.
>>
>> The problem is without clear releases, I have to setup timestamped
>> checkouts of code from CVS, maybe generate my own javadocs, and
>> otherwise always be uncertain if I'm checking the source and docs of
>> what I'm actually running.
>>
>> Also, as it seems every other line of code in Avalon is dependent on
>> another Avalon subproject, in these releases I would very much like to
>> understand how these builds are made and with what dependencies. Are
>> these being built with the latest of CVS in the other subprojects, or
>> a particular release? It always worries me when I see how 2/3rds of
>> the subprojects have made releases since there is so much
>> interdependency. It seems at some point there could be a combined
>> "Avalon" release for projects like James where we're using more than
>> one or two modules.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Serge Knystautas <se...@lokitech.com>.
Paul,
If it's ok, I'd prefer if you did these changes to an offline
repository. I don't really know what exactly your changes would be (as
tempting as they sound) and what all the implications would be, so I
would prefer to review them from a separate source. Otherwise I would
very much appreciate your help in getting us up to speed with the latest
version of Avalon, a better structure, and otherwise improved build
process as you see it.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Paul Hammant wrote:
> Danny,
>
>>> Nonetheless, I'd like to offer my services to bring you completely up to
>>> date with released Avalon comps.
>>>
>>
>> +1
>>
> You guys need to worry about how to make me committer for this once off
> duty.. Normal rules of patches before proposition have not been followed.
>
> I could cut the whole thin else where (without CVS directories) and let
> one of you over lay it before commit.
>
>> My specific concern is that there seem to be a significant number of
>> avalon
>> issues manifesting themselves as James bugs.
>> What I think James needs is a way in which we can address bugs and
>> enhancements without getting too dirty in the avalon code.
>>
> You must realise that JAMES is our flagship dependant project... we will
> always be attentive to you...
>
> - Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Serge Knystautas <se...@lokitech.com>.
Great, sounds encouraging. The database stuff is pretty independent of
Avalon since I've rolled my own datasource component/pooler. If you can
get it working with the standard file repositories, we can probably get
it the rest of the way.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Paul Hammant wrote:
> Danny, Harmeet, Serge,
>
> OK, I have JAMES building with latest Avalon comps. I have not had to
> chage any JAMES sourcem but have made a few changes to the build script.
>
> Overview :-
>
> * BAR files have gone. They are just jars now.
> * There is a new SAR taskdef (Peter is active on the Ant list).
> * Excalibur has been broken into many jars.
> * There are way less jars in lib/ and many more in phoenix-bin/lib
> * I have all bar the dist-lite target working which i do not quite
> understand.
>
> Should I try to make things compatible with off the shelf Ant 1.4.1 and
> thus remove the tools dir?
> Should I upload this 7Mb snapshot of source and libs somewhere?
>
> I can't really test right without a database?
>
> Regards,
>
> - Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny, Harmeet, Serge,
OK, I have JAMES building with latest Avalon comps. I have not had to
chage any JAMES sourcem but have made a few changes to the build script.
Overview :-
* BAR files have gone. They are just jars now.
* There is a new SAR taskdef (Peter is active on the Ant list).
* Excalibur has been broken into many jars.
* There are way less jars in lib/ and many more in phoenix-bin/lib
* I have all bar the dist-lite target working which i do not quite
understand.
Should I try to make things compatible with off the shelf Ant 1.4.1 and
thus remove the tools dir?
Should I upload this 7Mb snapshot of source and libs somewhere?
I can't really test right without a database?
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon.die.die.die
Posted by Danny Angus <da...@thought.co.uk>.
> You must realise that JAMES is our flagship dependant project... we will
> always be attentive to you...
I didn't. But I do now.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>>Nonetheless, I'd like to offer my services to bring you completely up to
>>date with released Avalon comps.
>>
>
>+1
>
You guys need to worry about how to make me committer for this once off
duty.. Normal rules of patches before proposition have not been followed.
I could cut the whole thin else where (without CVS directories) and let
one of you over lay it before commit.
>My specific concern is that there seem to be a significant number of avalon
>issues manifesting themselves as James bugs.
>What I think James needs is a way in which we can address bugs and
>enhancements without getting too dirty in the avalon code.
>
You must realise that JAMES is our flagship dependant project... we will
always be attentive to you...
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon.die.die.die
Posted by Danny Angus <da...@thought.co.uk>.
> Nonetheless, I'd like to offer my services to bring you completely up to
> date with released Avalon comps.
+1
My specific concern is that there seem to be a significant number of avalon
issues manifesting themselves as James bugs.
What I think James needs is a way in which we can address bugs and
enhancements without getting too dirty in the avalon code.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Paul Hammant <Pa...@yahoo.com>.
Serge,
OK thanks for backing down, coming clean re the need for the pub... ;-)
Nonetheless, I'd like to offer my services to bring you completely up to
date with released Avalon comps. I'll also try to get a release of
Phoenix done (it moves a little each month) and of Cornerstone (has
hardly moved in months). I reckon it will take me a day to do. I'll
propose Saturday (if you guys can stay clear of the CVS).
I'd like to do it in this style
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/eob/eob/ where there is
greater separation between the jars that Phoenix needs and the jars that
JAMES needs. This will help a newbie see what is actually needed for
JAMES compilation. I am adept at build scripts and will leave you in a
position where all the targets (that work currently) continue to work.
What will follow, hopefully in a week or so would be the release
versions of the things that are release versions. What I have done with
EOB is take the Phoenix verison from CVS after a "build dist-lite"
build. The layout that gives is the same as that I have booked into CVS
of EOB.
Of course, there is a lot to consider here. You have every right to
veto or decline, but the offer is tabled.
Tonight, while you folks mull the offer, I am going to create a block
wrapper for this Tomcat wrapper :-
http://freshmeat.net/projects/mintc/?topic_id=92%2C259%2C250
How would you feel about a web server in the same SAR file ? Another
day perhaps....
Regards,
- Paul H
> Peter and Paul,
>
> Thank you for responding so calmly. Regardless of my points, I should
> have just walked to the nearby bar before writing that kind of a
> message, and I appreciate your positive responses.
>
> I'm glad to see Avalon is making some releases. I see the latest in
> code James CVS reporting "Phoenix 4.0a4" and a bunch of timestamped
> avalon jars. I don't see where Avalon-Phoenix is "currently shipping
> a beta"... both freshmeat and jakarta show 4.0a1-a3 and latest. If
> there is a release, that's great and we should probably upgrade.
>
> On that note, what would really help me from Avalon would be
> concrete/complete releases. What I would like in a release would be a
> main jar, dependent jars, source code, javadocs, and ideally a branch
> in CVS. I'm used to drilling from James' code to Avalon-Phoenix to
> Avalon-Cornerstone, etc..., that's fine and expected... I like to do
> that and that's a big reason why I use open source.
>
> The problem is without clear releases, I have to setup timestamped
> checkouts of code from CVS, maybe generate my own javadocs, and
> otherwise always be uncertain if I'm checking the source and docs of
> what I'm actually running.
>
> Also, as it seems every other line of code in Avalon is dependent on
> another Avalon subproject, in these releases I would very much like to
> understand how these builds are made and with what dependencies. Are
> these being built with the latest of CVS in the other subprojects, or
> a particular release? It always worries me when I see how 2/3rds of
> the subprojects have made releases since there is so much
> interdependency. It seems at some point there could be a combined
> "Avalon" release for projects like James where we're using more than
> one or two modules.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Vinay Chandran <vi...@yahoo.com>.
Folks,
Dont know whether this is the right thread
to advocate Avalon for the JAMES guys <or>
praise JAMES in front of the Avalon folks,:)
But it was bcoz of BOTH that I was really able to
get grasp over much of JAMES (atleast the parts I
needed).
Avalon paradigms helped me quickly put a initial
release for JXTA
p2pEmail project , which aims at transporting
eMail(MIME messages)
over JXTA p2p network to the recipient JXTA p2pEmail
entity.
.[ JXTA is SUN's open p2p protocol:
http://www.jxta.org].
.[ JXTA p2pEmail Home Page:
http://p2p-email.jxta.org/servlets/ProjectHome ].
Hats off to JAMES and Avalon projects ,
the exercise was piece of cake for me.
Regards,
V i n a y
--- Serge Knystautas <se...@lokitech.com> wrote:
> Peter and Paul,
>
> Thank you for responding so calmly. Regardless of
> my points, I should
> have just walked to the nearby bar before writing
> that kind of a
> message, and I appreciate your positive responses.
>
> I'm glad to see Avalon is making some releases. I
> see the latest in
> code James CVS reporting "Phoenix 4.0a4" and a bunch
> of timestamped
> avalon jars. I don't see where Avalon-Phoenix is
> "currently shipping a
> beta"... both freshmeat and jakarta show 4.0a1-a3
> and latest. If there
> is a release, that's great and we should probably
> upgrade.
>
> On that note, what would really help me from Avalon
> would be
> concrete/complete releases. What I would like in a
> release would be a
> main jar, dependent jars, source code, javadocs, and
> ideally a branch in
> CVS. I'm used to drilling from James' code to
> Avalon-Phoenix to
> Avalon-Cornerstone, etc..., that's fine and
> expected... I like to do
> that and that's a big reason why I use open source.
>
> The problem is without clear releases, I have to
> setup timestamped
> checkouts of code from CVS, maybe generate my own
> javadocs, and
> otherwise always be uncertain if I'm checking the
> source and docs of
> what I'm actually running.
>
> Also, as it seems every other line of code in Avalon
> is dependent on
> another Avalon subproject, in these releases I would
> very much like to
> understand how these builds are made and with what
> dependencies. Are
> these being built with the latest of CVS in the
> other subprojects, or a
> particular release? It always worries me when I see
> how 2/3rds of the
> subprojects have made releases since there is so
> much interdependency.
> It seems at some point there could be a combined
> "Avalon" release for
> projects like James where we're using more than one
> or two modules.
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
> Paul Hammant wrote:
> > Serge,
> >
> > As an Avalon advocate, who has none of the
> problems you mention before,
> > I think I should offer my help. Your cry for help
> is heard.
> >
> > At the risk of contradicting you, Avalon comps
> have been released : -
> >
> http://freshmeat.net/projects/avalon/?topic_id=810
> > Avalon-Cornerstone has not. Avalon-Phoenix is
> currently shipping a beta.
> >
> > Regards,
> >
> > - Paul H
> >
> >> I don't know if I can take much more of Avalon.
> I've lost so much
> >> interest in working on James because of the
> problems that arise from
> >> using Avalon, and am nearing my last straw this
> afternoon.
> >>
> >> The latest problem with our use of Avalon is that
> if you have any open
> >> connections when you try to stop the JVM, it
> hangs and has to be
> >> forcibly stopped. I thought the whole reason
> behind migrating to
> >> Avalon was so that we didn't have to deal with
> underlying threading,
> >> configuration, object pooling, database sources,
> connection handling,
> >> logging, and other server related issues.
> Unfortunately, none of the
> >> features are implemented that wonderfully, the
> platform continually
> >> moves from one pre-alpha release to another,
> there are regular huge
> >> arguments on the dev mailing list about what
> latest pre-pre-alpha
> >> component should be added next to the already
> uncertain platform, and
> >> meanwhile the James project is stuck working
> again and again on stuff
> >> that was already working before we ported to
> Avalon years ago.
> >>
> >> Sorry, I'm just really really tired of this
> stuff. Since there aren't
> >> any real official releases of Avalon, should we
> just do another
> >> snapshot? Or maybe just branch the code, import
> it into James so we
> >> can gain control over our project again?
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Serge Knystautas <se...@lokitech.com>.
Peter and Paul,
Thank you for responding so calmly. Regardless of my points, I should
have just walked to the nearby bar before writing that kind of a
message, and I appreciate your positive responses.
I'm glad to see Avalon is making some releases. I see the latest in
code James CVS reporting "Phoenix 4.0a4" and a bunch of timestamped
avalon jars. I don't see where Avalon-Phoenix is "currently shipping a
beta"... both freshmeat and jakarta show 4.0a1-a3 and latest. If there
is a release, that's great and we should probably upgrade.
On that note, what would really help me from Avalon would be
concrete/complete releases. What I would like in a release would be a
main jar, dependent jars, source code, javadocs, and ideally a branch in
CVS. I'm used to drilling from James' code to Avalon-Phoenix to
Avalon-Cornerstone, etc..., that's fine and expected... I like to do
that and that's a big reason why I use open source.
The problem is without clear releases, I have to setup timestamped
checkouts of code from CVS, maybe generate my own javadocs, and
otherwise always be uncertain if I'm checking the source and docs of
what I'm actually running.
Also, as it seems every other line of code in Avalon is dependent on
another Avalon subproject, in these releases I would very much like to
understand how these builds are made and with what dependencies. Are
these being built with the latest of CVS in the other subprojects, or a
particular release? It always worries me when I see how 2/3rds of the
subprojects have made releases since there is so much interdependency.
It seems at some point there could be a combined "Avalon" release for
projects like James where we're using more than one or two modules.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Paul Hammant wrote:
> Serge,
>
> As an Avalon advocate, who has none of the problems you mention before,
> I think I should offer my help. Your cry for help is heard.
>
> At the risk of contradicting you, Avalon comps have been released : -
> http://freshmeat.net/projects/avalon/?topic_id=810
> Avalon-Cornerstone has not. Avalon-Phoenix is currently shipping a beta.
>
> Regards,
>
> - Paul H
>
>> I don't know if I can take much more of Avalon. I've lost so much
>> interest in working on James because of the problems that arise from
>> using Avalon, and am nearing my last straw this afternoon.
>>
>> The latest problem with our use of Avalon is that if you have any open
>> connections when you try to stop the JVM, it hangs and has to be
>> forcibly stopped. I thought the whole reason behind migrating to
>> Avalon was so that we didn't have to deal with underlying threading,
>> configuration, object pooling, database sources, connection handling,
>> logging, and other server related issues. Unfortunately, none of the
>> features are implemented that wonderfully, the platform continually
>> moves from one pre-alpha release to another, there are regular huge
>> arguments on the dev mailing list about what latest pre-pre-alpha
>> component should be added next to the already uncertain platform, and
>> meanwhile the James project is stuck working again and again on stuff
>> that was already working before we ported to Avalon years ago.
>>
>> Sorry, I'm just really really tired of this stuff. Since there aren't
>> any real official releases of Avalon, should we just do another
>> snapshot? Or maybe just branch the code, import it into James so we
>> can gain control over our project again?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Peter Donald <pe...@apache.org>.
Hi,
Sorry that you got bitten by that bug but I believe it was fixed about 7
months ago. Heres the relevent cvs log
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
revision 1.5
date: 2001/09/07 03:06:51; author: donaldp; state: Exp; lines: +2 -0
Make sure accept() calls are interupted frequently enough on win32.
----------------------------
revision 1.4
date: 2001/09/01 16:51:42; author: donaldp; state: Exp; lines: +6 -7
Threads are got from a pool and thus will never end. Thus when we were waiting
for thread.join() it would wait indefinetly. Thus we now use monitors +
wait()/notifyAll() to communicate between threads.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
I am not sure if the above is the cause of your current woes but it sounds
like it is.
However if you want to take control of your project as you say then all you
need do is ask for commit access and it will be granted. Then if you need to
fix something you can fix it.
As a side note just because it is in avalon does not mean there is any law
stating that you have to use it. Some of the components I don't use because I
don't like their design and some I don't use because they drag in too many
dependencies or are not stable or whatever. If you have problems with
particular components then you should feel free to fix them or use
alternatives.
On Thu, 18 Apr 2002 16:18, Paul Hammant wrote:
> Serge,
>
> As an Avalon advocate, who has none of the problems you mention before,
> I think I should offer my help. Your cry for help is heard.
>
> At the risk of contradicting you, Avalon comps have been released : -
> http://freshmeat.net/projects/avalon/?topic_id=810
> Avalon-Cornerstone has not. Avalon-Phoenix is currently shipping a beta.
>
> Regards,
>
> - Paul H
>
> > I don't know if I can take much more of Avalon. I've lost so much
> > interest in working on James because of the problems that arise from
> > using Avalon, and am nearing my last straw this afternoon.
> >
> > The latest problem with our use of Avalon is that if you have any open
> > connections when you try to stop the JVM, it hangs and has to be
> > forcibly stopped. I thought the whole reason behind migrating to
> > Avalon was so that we didn't have to deal with underlying threading,
> > configuration, object pooling, database sources, connection handling,
> > logging, and other server related issues. Unfortunately, none of the
> > features are implemented that wonderfully, the platform continually
> > moves from one pre-alpha release to another, there are regular huge
> > arguments on the dev mailing list about what latest pre-pre-alpha
> > component should be added next to the already uncertain platform, and
> > meanwhile the James project is stuck working again and again on stuff
> > that was already working before we ported to Avalon years ago.
> >
> > Sorry, I'm just really really tired of this stuff. Since there aren't
> > any real official releases of Avalon, should we just do another
> > snapshot? Or maybe just branch the code, import it into James so we
> > can gain control over our project again?
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Paul Hammant <Pa...@yahoo.com>.
Serge,
As an Avalon advocate, who has none of the problems you mention before,
I think I should offer my help. Your cry for help is heard.
At the risk of contradicting you, Avalon comps have been released : -
http://freshmeat.net/projects/avalon/?topic_id=810
Avalon-Cornerstone has not. Avalon-Phoenix is currently shipping a beta.
Regards,
- Paul H
> I don't know if I can take much more of Avalon. I've lost so much
> interest in working on James because of the problems that arise from
> using Avalon, and am nearing my last straw this afternoon.
>
> The latest problem with our use of Avalon is that if you have any open
> connections when you try to stop the JVM, it hangs and has to be
> forcibly stopped. I thought the whole reason behind migrating to
> Avalon was so that we didn't have to deal with underlying threading,
> configuration, object pooling, database sources, connection handling,
> logging, and other server related issues. Unfortunately, none of the
> features are implemented that wonderfully, the platform continually
> moves from one pre-alpha release to another, there are regular huge
> arguments on the dev mailing list about what latest pre-pre-alpha
> component should be added next to the already uncertain platform, and
> meanwhile the James project is stuck working again and again on stuff
> that was already working before we ported to Avalon years ago.
>
> Sorry, I'm just really really tired of this stuff. Since there aren't
> any real official releases of Avalon, should we just do another
> snapshot? Or maybe just branch the code, import it into James so we
> can gain control over our project again?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Serge Knystautas <se...@lokitech.com>.
Also, after you login into POP3, commands are no longer passed to the
POP3Handler class. SMTP Handler seems to be working ok though... sent a
few test messages through what's in CVS.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Serge Knystautas wrote:
> I don't know if I can take much more of Avalon. I've lost so much
> interest in working on James because of the problems that arise from
> using Avalon, and am nearing my last straw this afternoon.
>
> The latest problem with our use of Avalon is that if you have any open
> connections when you try to stop the JVM, it hangs and has to be
> forcibly stopped. I thought the whole reason behind migrating to Avalon
> was so that we didn't have to deal with underlying threading,
> configuration, object pooling, database sources, connection handling,
> logging, and other server related issues. Unfortunately, none of the
> features are implemented that wonderfully, the platform continually
> moves from one pre-alpha release to another, there are regular huge
> arguments on the dev mailing list about what latest pre-pre-alpha
> component should be added next to the already uncertain platform, and
> meanwhile the James project is stuck working again and again on stuff
> that was already working before we ported to Avalon years ago.
>
> Sorry, I'm just really really tired of this stuff. Since there aren't
> any real official releases of Avalon, should we just do another
> snapshot? Or maybe just branch the code, import it into James so we can
> gain control over our project again?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon.die.die.die
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny
>How much code would we have to import, a lot right..?
>
>I share your concerns, but I wonder if there's another way.
>d.
>
Please do not over-react. How about asking the Avalon team for help
with your issue. If you rip out Avalon, you will lose so many other
features.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon.die.die.die
Posted by Danny Angus <da...@thought.co.uk>.
> I don't know if I can take much more of Avalon. I've lost so much
> interest in working on James because of the problems that arise from
> using Avalon, and am nearing my last straw this afternoon.
>
> The latest problem with our use of Avalon is that if you have any open
> connections when you try to stop the JVM, it hangs and has to be
> forcibly stopped.
That has been the case for a while
> I thought the whole reason behind migrating to Avalon
> was so that we didn't have to deal with underlying threading,
> configuration, object pooling, database sources, connection handling,
> logging, and other server related issues. Unfortunately, none of the
> features are implemented that wonderfully, the platform continually
> moves from one pre-alpha release to another, there are regular huge
> arguments on the dev mailing list about what latest pre-pre-alpha
> component should be added next to the already uncertain platform, and
> meanwhile the James project is stuck working again and again on stuff
> that was already working before we ported to Avalon years ago.
>
> Sorry, I'm just really really tired of this stuff. Since there aren't
> any real official releases of Avalon, should we just do another
> snapshot? Or maybe just branch the code, import it into James so we can
> gain control over our project again?
How much code would we have to import, a lot right..?
I share your concerns, but I wonder if there's another way.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>