You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@excalibur.apache.org by "Sasvata (Shash) Chatterjee" <sh...@badfw.org> on 2005/08/15 05:30:41 UTC
RC2 Builds
RC2 builds are now available at:
http://people.apache.org/~shash/dist/. Framework is at 4.3, Fortress
is at 1.2, everything else at 2.1.
Primarily, changes are in: avalon-logkit, excalibur-datasource,
excalibur-logger, excalibur-sourceresolve, excalibur-xmlutil,
cornerstone-threads. The rest of the updated JARs are because of
dependency changes.
Barring unforeseen changes, the final release will be on August 28.
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@excalibur.apache.org
For additional commands, e-mail: user-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Carsten Ziegeler <cz...@apache.org>.
Antonio Gallardo wrote:
>>
>>Yepp, we had to fix such a ThreadLocal in Xalan recently which eat up
>>3GB of memory in four hours! With the ThreadLocal properly reset, the
>>app runs at an average of 300MB...
>>
>>
>
> Wow! Is this affecting cocoon? If this is affecting cocoon code, I will
> prefer to add a patched excalibur jar into cocoon. ;-)
>
It depends - the bug is in Xalan, not excalibur, so you need to patch
Xalan - I filed this into Jira as XALANJ-2178. You're only affected by
it if you're using the Xalan extensions to write files directly from
within the stylesheet - so the usual Cocoon user does not need the
patch. I really hope that the Xalan guys will do something about it for
the next release.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>... or ThreadLocals are EVIL! If you have not heard the word yet, ThreadLocals
>>tend to prevent (web) application(s) from being garbage collected when thread
>>locals are not properly nulled out.
>>
>>
>Yepp, we had to fix such a ThreadLocal in Xalan recently which eat up
>3GB of memory in four hours! With the ThreadLocal properly reset, the
>app runs at an average of 300MB...
>
>
Wow! Is this affecting cocoon? If this is affecting cocoon code, I will
prefer to add a patched excalibur jar into cocoon. ;-)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>
>>So as you can see there is a strong reference from ContextMap class to the
>>ThreadLocal which prevents GC of the WebAppClassLoader :-) See also [1] and
>>referenced BugParade entry.
>
> Ah, ok - what a crap; so actually this means that one should clear all
> ThreadLocal variables. Are only static thread locals effected or also
> instance variables using thread locals?
Unless you do something like foo.tLocal.set(foo) - which creates reference from
ThreadLocalMap.Entry.value back to tLocal - you should be ok :-) Rule is, there
should be no strong reference from value of the thread local back to thread local.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
> Of course it is required, and of course it is a problem :-)
>
> Thread (pooled tomcat thread)
> --> ThreadLocalMap
> --> ThreadLocalMap.Entry
> --weak--> ThreadLocal (ContextMap.c_localContext)
> -strong-> ContextMap Object
> --> ContextMap Class
> --> ThreadLocal (c_localContext)
> --> WebAppClassLoader (<loader>)
>
> So as you can see there is a strong reference from ContextMap class to the
> ThreadLocal which prevents GC of the WebAppClassLoader :-) See also [1] and
> referenced BugParade entry.
>
Ah, ok - what a crap; so actually this means that one should clear all
ThreadLocal variables. Are only static thread locals effected or also
instance variables using thread locals?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>
>>Consistent usage of this method, like:
>>
>>try {
>> ... ContextMap.getCurrentContext() ...
>>} finally {
>> ContextMap.removeCurrentContext();
>>}
>>
>>will guarantee that ThreadLocal is properly cleaned up and web app will be
>>properly unloaded. I'd like to include this addition into the release; and IMHO
>>there is no reason to do yet another RC build just because of it :-) because it
>>is simple addition which does not alter any existing behavior.
>
> Hmm, is this really required? The context map has a clear method
> clearing all items stored in the map. The only object that is not
> removed is the map itself, which shouldn't be a problem.
Of course it is required, and of course it is a problem :-)
Thread (pooled tomcat thread)
--> ThreadLocalMap
--> ThreadLocalMap.Entry
--weak--> ThreadLocal (ContextMap.c_localContext)
-strong-> ContextMap Object
--> ContextMap Class
--> ThreadLocal (c_localContext)
--> WebAppClassLoader (<loader>)
So as you can see there is a strong reference from ContextMap class to the
ThreadLocal which prevents GC of the WebAppClassLoader :-) See also [1] and
referenced BugParade entry.
Vadim
[1] http://www.jroller.com/page/tackline?entry=fixing_threadlocal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
> ... or ThreadLocals are EVIL! If you have not heard the word yet, ThreadLocals
> tend to prevent (web) application(s) from being garbage collected when thread
> locals are not properly nulled out.
Yepp, we had to fix such a ThreadLocal in Xalan recently which eat up
3GB of memory in four hours! With the ThreadLocal properly reset, the
app runs at an average of 300MB...
>
> So in order to allow web applications using LogKit to be properly unloaded,
> LogKit's ContextMap has to have one more method:
>
> /**
> * Remove current ContextMap.
> * This method removes a ContextMap associated with current thread,
> * if there is any.
> */
> public static void removeCurrentContext()
> {
> c_localContext.set(null);
> }
>
>
> Consistent usage of this method, like:
>
> try {
> ... ContextMap.getCurrentContext() ...
> } finally {
> ContextMap.removeCurrentContext();
> }
>
> will guarantee that ThreadLocal is properly cleaned up and web app will be
> properly unloaded. I'd like to include this addition into the release; and IMHO
> there is no reason to do yet another RC build just because of it :-) because it
> is simple addition which does not alter any existing behavior.
>
Hmm, is this really required? The context map has a clear method
clearing all items stored in the map. The only object that is not
removed is the map itself, which shouldn't be a problem.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
... or ThreadLocals are EVIL! If you have not heard the word yet, ThreadLocals
tend to prevent (web) application(s) from being garbage collected when thread
locals are not properly nulled out.
So in order to allow web applications using LogKit to be properly unloaded,
LogKit's ContextMap has to have one more method:
/**
* Remove current ContextMap.
* This method removes a ContextMap associated with current thread,
* if there is any.
*/
public static void removeCurrentContext()
{
c_localContext.set(null);
}
Consistent usage of this method, like:
try {
... ContextMap.getCurrentContext() ...
} finally {
ContextMap.removeCurrentContext();
}
will guarantee that ThreadLocal is properly cleaned up and web app will be
properly unloaded. I'd like to include this addition into the release; and IMHO
there is no reason to do yet another RC build just because of it :-) because it
is simple addition which does not alter any existing behavior.
WDYT?
Vadim
PS http://www.jroller.com/page/tackline?entry=fixing_threadlocal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sasvata (Shash) Chatterjee wrote:
> Vadim,
>
> Is it really bad enough to hold the release? Why can we not fix it in
> the next release?
Well, I can live with private fork for some time...
> PS: Admittedly, my opinion is colored by the grunt-work of making
> repeated released, but, still...:-)
Hence I colored this as a simple addition not requiring RC4 :-)
Vadim
> Vadim Gritsenko wrote:
>
>> ... or ThreadLocals are EVIL! If you have not heard the word yet,
>> ThreadLocals
>> tend to prevent (web) application(s) from being garbage collected when
>> thread
>> locals are not properly nulled out.
>>
>> So in order to allow web applications using LogKit to be properly
>> unloaded,
>> LogKit's ContextMap has to have one more method:
>>
>> /**
>> * Remove current ContextMap.
>> * This method removes a ContextMap associated with current thread,
>> * if there is any.
>> */
>> public static void removeCurrentContext()
>> {
>> c_localContext.set(null);
>> }
>>
>>
>> Consistent usage of this method, like:
>>
>> try {
>> ... ContextMap.getCurrentContext() ...
>> } finally {
>> ContextMap.removeCurrentContext();
>> }
>>
>> will guarantee that ThreadLocal is properly cleaned up and web app
>> will be
>> properly unloaded. I'd like to include this addition into the release;
>> and IMHO
>> there is no reason to do yet another RC build just because of it :-)
>> because it
>> is simple addition which does not alter any existing behavior.
>>
>> WDYT?
>>
>> Vadim
>>
>> PS http://www.jroller.com/page/tackline?entry=fixing_threadlocal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
Vadim,
Is it really bad enough to hold the release? Why can we not fix it in
the next release?
Shash
PS: Admittedly, my opinion is colored by the grunt-work of making
repeated released, but, still...:-)
Vadim Gritsenko wrote:
> ... or ThreadLocals are EVIL! If you have not heard the word yet,
> ThreadLocals
> tend to prevent (web) application(s) from being garbage collected when
> thread
> locals are not properly nulled out.
>
> So in order to allow web applications using LogKit to be properly
> unloaded,
> LogKit's ContextMap has to have one more method:
>
> /**
> * Remove current ContextMap.
> * This method removes a ContextMap associated with current thread,
> * if there is any.
> */
> public static void removeCurrentContext()
> {
> c_localContext.set(null);
> }
>
>
> Consistent usage of this method, like:
>
> try {
> ... ContextMap.getCurrentContext() ...
> } finally {
> ContextMap.removeCurrentContext();
> }
>
> will guarantee that ThreadLocal is properly cleaned up and web app
> will be
> properly unloaded. I'd like to include this addition into the release;
> and IMHO
> there is no reason to do yet another RC build just because of it :-)
> because it
> is simple addition which does not alter any existing behavior.
>
> WDYT?
>
> Vadim
>
> PS http://www.jroller.com/page/tackline?entry=fixing_threadlocal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leo Simons wrote:
> Vadim Gritsenko wrote:
>
>>Leo Simons wrote:
>>
>>>On 24-08-2005 01:27, "Vadim Gritsenko" <va...@reverycodes.com> wrote:
>>>
>>>>is no reason to do yet another RC build just because of it :-) because
>>>>it is simple addition which does not alter any existing behavior.
>>>
>>>-1 on such a process. There should be *no* difference between the RC
>>>that is voted on and what is eventually released. Take this seriously!
>>
>><vent>
>>Give me a break!
>
> Sorry Vadim, but no. You should be giving the release manager a break
> and not put pressure on him to keep including changes into a release
> near the end of a several-week release process. Its bad form and wastes
> everyone's time.
Hey, I never meant to add a burden to the heroic person we have for a release
manager right now! Only if suggested something which is "that's not the way we
do it here" (tm).
> The problem you brought up has existed for years and there have been
> many years to fix it. I understand it is a new problem for you and
> you're burning to fix it now,
It's fixed for me, right now; only question was, does it make sense to include
it in this release round or not. Including in the next release is good enough
for me. I'm cool.
<snip/>
> If you want a release that includes your fix you can volunteer to build
> it and put on the release manager hat. That would be very healthy for
> this community.
Can't volunteer for this now - was planning to do release of another project
first...
> Having releases once every so often (with often << year)
> is good. We're not going to get to such a point if every release cycle
> takes rediculously long.
+1 to that.
>>PMC can release whatever it wants as long as what is
>>had released matches with what it had voted upon to release!
>
> Yes, if you define "matches" as "same MD5 signature". No, otherwise.
You are not correct. PMC decides how it will do business. It can decide that
'matches' means source code. If that PMC requires matching MD5 sigs of
zip/tar.gz release, so be it (even though I might not agree with it and complain
about it :P ).
But - note that your MD5 sigs won't match with final release anyway - for
example because of different entries in the Manifest (version: 1.2.3 rc5 changes
to version: 1.2.3 giving different MD5).
>>If PMC
>>voted to release "SVN r239620", it might or might not match any of the
>>previous (RC or Beta or Alpha or Milestone) releases.
(completing the sentence) ... and that is not a problem: rc3 release is not the
same as final release, so it is different vote, and different release.
> Indeed, which is why we won't.
As long as SVN r239620 is SVN r239620, release made out of it is the same
release. If you 'svn cp' r239620 today or tomorrow, you still get same result,
always. Does not matter how many other releases do you have (m1, m2, ... mn, a1,
a2, ... an, b1, b2, ... bn, rc1, rc2, ... rcn). Also does not matter how you
name your releases (alpha, beta, gamma, ...).
Point is,
* You have to uniquely and reproducably identify what you
are releasing (1)
* You have to give it a name
>>Moreover, one might argue there is no point in enforcing RCn == Final
>>policy as it lacks common sense.
>
> Oh c'mon. "common sense" is what led to a solid and verifiable and
> documented and repeatable release process in the first place.
Yep, see (1) above.
>>And in addition to this, RCn is already
>>out there anyway and re-releasing it is waste of bandwidth.
>></vent>
>
> Heh. There is a transformation process between an SVN revision and a
> distribution that is manual, non-trivial, environment-dependent, and
> fragile.
So it makes most sense than for each developer to repeat the process and compare
results - that is, if you want to transform it into something more stable.
> It is because of this that we have things like releases and
> release candidates.
This PMC, might be. Most others don't do this, hence I, as unfamiliar with
practice, got confused.
> Otherwise we could just have gump or some other
> build bot autopublish all the stuff it compiles and save ourselves a
> whole lot of work.
I imagine some folks from 'release early, release often' would love to just do
that, if not already doing. Write a cron job, schedule it to execute each 3
month, and announce code freeze week or two before that. Good process for lively
maintenance branch which gets patched regularly, especially if there are
automated nightly tests. And if you put on top of that requirement to add a test
for each bug found... This will produce good releases.
> These processes weren't invented because there's a bunch of really
> strange people that totally lack common sense and for some odd reason
> love fiddling with bits and bytes and votes and showing off authority or
> anything like that. They exist because of all the experiences we've had
> with f****d up releases causing nasty problems for years.
This gives background why this PMC had chosen such process. Thanks. I wonder
what was primary cause of problematic releases - was it issues with jar files in
repository, difference in version of build tool, difference in plugins / addons
/ jars to the build tool... Makes me want to commit maven repository into the
SVN - in order to achieve (1) above...
>>But, whatever - it's your PMC.
>
> Not really, I'm just one of many. In fact, our PMC is also just one of
> many. We are a part of the ASF and as such we have a shared
> responsibility towards all of its users and developers to uphold
> extremely high quality standards.
Notice though that this would not be a top and foremost goal of ASF. It might be
a by-product of achieving other ASF goals (such as strong communities), or some
third or fourth level goal, but not a top goal in and by itself. Moreover, some
senior ;-) member of the community would argue that in order to achieve high
quality software sometimes all you need to do is to push out a release with bugs
in it :-)
> The "Official ASF release" stamp is a
> rather big one and its not to be waved around or toyed with.
Leo, relax. Take off your tie and 3 piece suite, put jeans and t-shirt on. :-)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Leo Simons <ma...@leosimons.com>.
Vadim Gritsenko wrote:
> Leo Simons wrote:
>
>> On 24-08-2005 01:27, "Vadim Gritsenko" <va...@reverycodes.com> wrote:
>>
>>> is no reason to do yet another RC build just because of it :-) because
>>> it is simple addition which does not alter any existing behavior.
>>
>> -1 on such a process. There should be *no* difference between the RC
>> that is voted on and what is eventually released. Take this seriously!
>
> <vent>
> Give me a break!
Sorry Vadim, but no. You should be giving the release manager a break
and not put pressure on him to keep including changes into a release
near the end of a several-week release process. Its bad form and wastes
everyone's time.
The problem you brought up has existed for years and there have been
many years to fix it. I understand it is a new problem for you and
you're burning to fix it now, but in collaborative development there's
many needs to take into consideration besides your own. There will be
many more years to fix this stuff after Shash finishes the release cycle.
If you want a release that includes your fix you can volunteer to build
it and put on the release manager hat. That would be very healthy for
this community. Having releases once every so often (with often << year)
is good. We're not going to get to such a point if every release cycle
takes rediculously long.
> PMC can release whatever it wants as long as what is
> had released matches with what it had voted upon to release!
Yes, if you define "matches" as "same MD5 signature". No, otherwise.
> If PMC
> voted to release "SVN r239620", it might or might not match any of the
> previous (RC or Beta or Alpha or Milestone) releases.
Indeed, which is why we won't.
> Moreover, one might argue there is no point in enforcing RCn == Final
> policy as it lacks common sense.
Oh c'mon. "common sense" is what led to a solid and verifiable and
documented and repeatable release process in the first place.
> And in addition to this, RCn is already
> out there anyway and re-releasing it is waste of bandwidth.
> </vent>
Heh. There is a transformation process between an SVN revision and a
distribution that is manual, non-trivial, environment-dependent, and
fragile. It is because of this that we have things like releases and
release candidates. Otherwise we could just have gump or some other
build bot autopublish all the stuff it compiles and save ourselves a
whole lot of work.
These processes weren't invented because there's a bunch of really
strange people that totally lack common sense and for some odd reason
love fiddling with bits and bytes and votes and showing off authority or
anything like that. They exist because of all the experiences we've had
with f****d up releases causing nasty problems for years.
> But, whatever - it's your PMC.
Not really, I'm just one of many. In fact, our PMC is also just one of
many. We are a part of the ASF and as such we have a shared
responsibility towards all of its users and developers to uphold
extremely high quality standards. The "Official ASF release" stamp is a
rather big one and its not to be waved around or toyed with.
cheers!
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leif Mortenson wrote:
> ... it is always good to go through a testing phase.
I'd even go so far as to say...
It is a MUST to go through a testing phase!
:-)
My point was not about testing...
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Shash Chatterjee <sh...@badfw.org>.
>
> I don't think I really have any choice but to keep using the previous
> fortress-meta for
> now. From what I could tell by looking at the code, there is not a
> way to fix the
> encoding problem from within Excalibur. It is a QDox problem. I
> don't think it is
> reasonable to hold the release until that gets fixed as that could
> potentially take
> quite a while. (I have not heard if anyone has yet contacted them
> about this issue.
> If nobody in Excalibur has any contacts over there, then I will go
> ahead and do it.)
>
> Yes, my changes to instrument are quite minor. I would only put them
> in if we were
> already going to do an RC4 anyway.
>
OK...I'll restart the vote for the final release then.
> By the way. Thank you for all the energy you are putting into this
> release cycle.
You're welcome! This is payback for the good code I have been using for
years :-)
Shash
Re: One more change to be included into the release...
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Sasvata (Shash) Chatterjee wrote:
> Leif,
>
>>
>> If we are going to do another RCn then I have a minor change of my
>> own for the
>> excalibur-instrument-mgr-impl jar. If not then it can wait until the
>> next release.
>> (A typo and removing a stack dump if the state file is corrupted or
>> can't be
>> accessed for any reason. It can happen if a previous JVM invocation
>> crashed
>> at just the wrong moment.)
>>
> You tell us. As the release-manager, here's my position: There's no
> sense doing a release, but leaving the community high and dry if they
> cannot use the release. So, tell us, if you can trudge along with
> using most of the new release, but use the previous fortress-meta.
I don't think I really have any choice but to keep using the previous
fortress-meta for
now. From what I could tell by looking at the code, there is not a way
to fix the
encoding problem from within Excalibur. It is a QDox problem. I don't
think it is
reasonable to hold the release until that gets fixed as that could
potentially take
quite a while. (I have not heard if anyone has yet contacted them about
this issue.
If nobody in Excalibur has any contacts over there, then I will go ahead
and do it.)
> If you cannot do that, we'll do a RC4 and fix Vadim's (I think
> important, but non-blocker) issue, and you can fix the minor issue you
> mention here. But, here's the catch. I would not do the RC4 for
> another week, instead really *encouraging* all users to complete
> testing with RC3. Once we do RC4, the only things that will stop the
> release will be things broken between RC3 and RC4, but nothing else.
>
> Does that sound kosher?
Yes, my changes to instrument are quite minor. I would only put them in
if we were
already going to do an RC4 anyway.
By the way. Thank you for all the energy you are putting into this
release cycle.
Cheers,
Leif
>
> Shash
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
Leif,
>
> If we are going to do another RCn then I have a minor change of my own
> for the
> excalibur-instrument-mgr-impl jar. If not then it can wait until the
> next release.
> (A typo and removing a stack dump if the state file is corrupted or
> can't be
> accessed for any reason. It can happen if a previous JVM invocation
> crashed
> at just the wrong moment.)
>
You tell us. As the release-manager, here's my position: There's no
sense doing a release, but leaving the community high and dry if they
cannot use the release. So, tell us, if you can trudge along with using
most of the new release, but use the previous fortress-meta. If you
cannot do that, we'll do a RC4 and fix Vadim's (I think important, but
non-blocker) issue, and you can fix the minor issue you mention here.
But, here's the catch. I would not do the RC4 for another week, instead
really *encouraging* all users to complete testing with RC3. Once we
do RC4, the only things that will stop the release will be things broken
between RC3 and RC4, but nothing else.
Does that sound kosher?
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Leif Mortenson <le...@tanukisoftware.com>.
I agree with Leo on this. No matter how simple the change, it is always
good to go
through a testing phase. I've been bitten myself my last minute changes
in the past
myself. Its a hassle, but it gives everyone a chance to test the final
version before
the actual release.
If we are going to do another RCn then I have a minor change of my own
for the
excalibur-instrument-mgr-impl jar. If not then it can wait until the
next release.
(A typo and removing a stack dump if the state file is corrupted or can't be
accessed for any reason. It can happen if a previous JVM invocation crashed
at just the wrong moment.)
Cheers,
Leif
Vadim Gritsenko wrote:
> Leo Simons wrote:
>
>> On 24-08-2005 01:27, "Vadim Gritsenko" <va...@reverycodes.com> wrote:
>>
>>> is no reason to do yet another RC build just because of it :-) because
>>> it is simple addition which does not alter any existing behavior.
>>
>>
>> -1 on such a process. There should be *no* difference between the RC
>> that is
>> voted on and what is eventually released. Take this seriously!
>
>
> <vent>
> Give me a break! PMC can release whatever it wants as long as what is
> had released matches with what it had voted upon to release! If PMC
> voted to release "SVN r239620", it might or might not match any of the
> previous (RC or Beta or Alpha or Milestone) releases.
>
> Moreover, one might argue there is no point in enforcing RCn == Final
> policy as it lacks common sense. And in addition to this, RCn is
> already out there anyway and re-releasing it is waste of bandwidth.
> </vent>
>
> But, whatever - it's your PMC.
>
> Vadim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leo Simons wrote:
> On 24-08-2005 01:27, "Vadim Gritsenko" <va...@reverycodes.com> wrote:
>
>>is no reason to do yet another RC build just because of it :-) because
>>it is simple addition which does not alter any existing behavior.
>
> -1 on such a process. There should be *no* difference between the RC that is
> voted on and what is eventually released. Take this seriously!
<vent>
Give me a break! PMC can release whatever it wants as long as what is had
released matches with what it had voted upon to release! If PMC voted to release
"SVN r239620", it might or might not match any of the previous (RC or Beta or
Alpha or Milestone) releases.
Moreover, one might argue there is no point in enforcing RCn == Final policy as
it lacks common sense. And in addition to this, RCn is already out there anyway
and re-releasing it is waste of bandwidth.
</vent>
But, whatever - it's your PMC.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: One more change to be included into the release...
Posted by Leo Simons <ma...@leosimons.com>.
On 24-08-2005 01:27, "Vadim Gritsenko" <va...@reverycodes.com> wrote:
> I'd like to include this addition into the release; and IMHO
> there is no reason to do yet another RC build just because of it :-) because
> it is simple addition which does not alter any existing behavior.
>
> WDYT?
-1 on such a process. There should be *no* difference between the RC that is
voted on and what is eventually released. Take this seriously!
Cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
One more change to be included into the release...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
... or ThreadLocals are EVIL! If you have not heard the word yet, ThreadLocals
tend to prevent (web) application(s) from being garbage collected when thread
locals are not properly nulled out.
So in order to allow web applications using LogKit to be properly unloaded,
LogKit's ContextMap has to have one more method:
/**
* Remove current ContextMap.
* This method removes a ContextMap associated with current thread,
* if there is any.
*/
public static void removeCurrentContext()
{
c_localContext.set(null);
}
Consistent usage of this method, like:
try {
... ContextMap.getCurrentContext() ...
} finally {
ContextMap.removeCurrentContext();
}
will guarantee that ThreadLocal is properly cleaned up and web app will be
properly unloaded. I'd like to include this addition into the release; and IMHO
there is no reason to do yet another RC build just because of it :-) because it
is simple addition which does not alter any existing behavior.
WDYT?
Vadim
PS http://www.jroller.com/page/tackline?entry=fixing_threadlocal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
RC3 builds
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
RC3 builds are now available at: http://people.apache.org/~shash/dist/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@excalibur.apache.org
For additional commands, e-mail: user-help@excalibur.apache.org
RC3 builds
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
RC3 builds are now available at: http://people.apache.org/~shash/dist/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: RC2 Builds
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
Leo Simons wrote:
>First things first...hurray for Shash! Keep going!
>
>
Thanks for the encouragement, guys. But, I'm just turning the crank.
It's a testament actually to the planning behind the structure, and the
buildsystem, so that the builds "just work".
Also, thanks are due to all the contributors putting in fixes, and also
to those dilligently reporting bugs and providing fixes.
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: RC2 Builds
Posted by Stefano Bagnara <ap...@bago.org>.
> First things first...hurray for Shash! Keep going!
Hurray! :-)
> Stefano Bagnara wrote:
> > I'm a James (Apache mail server) committer and i would like to know
> > your opinion about libraries upgrade.
> > Our current trunk is build against avalon 4.1.4 and runs
> under phoenix
> > 4.0.5.
> > Should we try to upgrade to the latest excalibur libs?
>
> Yes. *Try* being the keyword. We think everything is
> backwards-compatible and as far as Gump can tell it is. But
> from 4.0.5 (I think there's just a 4.0.4 actually?) to
> current trunk is a long way (like, ehm, a few years).
I've been successfull in upgrading phoenix-4.0.4 to latest cornerstone+
latest avalon and to use it to run an upgraded version of james.
I know this probably is not the right place to talk about phoenix but I
don't know another place. I've also downloaded the latest phoenix from
https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoeni
x and tryed to upgrade it to the latest avalon. I've been successfull but
when I try to run james in it I keep getting this error:
Schema type specified as relax-ng was translated to URI
http://relaxng.org/ns/structure/1.0 for component named database-connections
of type
org.apache.avalon.cornerstone.blocks.datasources.DefaultDataSourceSelector.
It is recomended that the components Info specify the URI rather than the
type for compatability reasons.
There was an uncaught exception:
---------------------------------------------------------
--- Message ---
Unable to validate configuration of component database-connections of type
org.apache.avalon.cornerstone.blocks.datasources.DefaultDataSourceSelector
--- Stack Trace ---
org.apache.avalon.phoenix.interfaces.DeploymentException: Unable to validate
configuration of component database-connections of type
org.apache.avalon.cornerstone.blocks.datasources.DefaultDataSourceSelector
at
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.validateConfig
uration(DefaultDeployer.java:524)
at
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.validateConfig
uration(DefaultDeployer.java:503)
at
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(Default
Deployer.java:354)
at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(Def
aultEmbeddor.java:542)
at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(Def
aultEmbeddor.java:535)
at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFiles(De
faultEmbeddor.java:520)
at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployDefaultA
pplications(DefaultEmbeddor.java:509)
at
org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.execute(Defaul
tEmbeddor.java:268)
at org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:198)
at
org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:184)
at
org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:128)
at org.apache.avalon.phoenix.launcher.Main.main(Main.java:83)
I'm using cornerstone-datasources-impl-2.1-RC2.jar but I don't know much
about relax-ng... Any idea?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: RC2 Builds
Posted by Leo Simons <ma...@leosimons.com>.
First things first...hurray for Shash! Keep going!
Stefano Bagnara wrote:
> I'm a James (Apache mail server) committer and i would like to know your
> opinion about libraries upgrade.
> Our current trunk is build against avalon 4.1.4 and runs under phoenix
> 4.0.5.
> Should we try to upgrade to the latest excalibur libs?
Yes. *Try* being the keyword. We think everything is
backwards-compatible and as far as Gump can tell it is. But from 4.0.5
(I think there's just a 4.0.4 actually?) to current trunk is a long way
(like, ehm, a few years).
At least consider upgrading avalon-framework. I'm *highly* confident
that's fully backwards-compatible and it has one or two bugfixes in
there that you want.
> Will Phoenix run with the latest avalon libs?
It should.
> Most cornerstone libs we use are 1.0: is it a big work to upgrade to the
> latest?
I don't think so.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Phoenix. (Re: RC2 Builds)
Posted by Stefano Bagnara <ap...@bago.org>.
> >Never tried to use loom, what is the missing jar?
>
> Here is the error that gets thrown when Loom attempts to load
> the james app:
>
> wrapper | --> Wrapper Started as Console wrapper |
> Launching a JVM...
> jvm 1 | Wrapper (Version 3.1.2) http://wrapper.tanukisoftware.org
> jvm 1 |
> jvm 1 | Loom Engine 1.0-rc3
> jvm 1 |
> jvm 1 | org.codehaus.loom.interfaces.LoomException:
> Component named
> "mailstore" failed to pass through the Starting stage. (Reason:
> java.lang.NoClassDefFoundError:
> org/apache/avalon/excalibur/io/ExtensionFileFilter).
I removed excalibur-io usage in the latest svn.
Can you try it and tell me if it runs under loom?
If it works, can you also tell me if you make any change to james to run it
under loom?
If needed I can send you an url where to download a snapshot binary build
done yesterday.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Phoenix. (Re: RC2 Builds)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Stefano Bagnara wrote:
>>Leo,
>> Thanks. I'll take a look at these. I tried getting the
>>latest version of Loom. But it didn't work when I tried to
>>load James. Missing jar. I will play with it a bit more, I
>>imagine it is a jar version problem. The instrumentation
>>code in Loom is pretty old. It is using the old API before I
>>restructured it last year.
>>
>> Do you know what James is planning to do in the future?
>>Being built on top of a frozen code base doesn't seem optimal
>>in the long term
>>
>>
>
>Never tried to use loom, what is the missing jar?
>
>I've just committed to james an upgrade to the latest avalon-framework,
>cornerstone and excalibur libs.
>I also rebuilt/updated the bundled phoenix to use the latest
>avalon-framework libs.
>It seems to work fine.
>
>We probably release a 2.3.0 or 3.0 still built over avalon. We will probably
>move to OSGi or a different container later.
>
>
Here is the error that gets thrown when Loom attempts to load the james app:
wrapper | --> Wrapper Started as Console
wrapper | Launching a JVM...
jvm 1 | Wrapper (Version 3.1.2) http://wrapper.tanukisoftware.org
jvm 1 |
jvm 1 |
jvm 1 | Loom Engine 1.0-rc3
jvm 1 |
jvm 1 | org.codehaus.loom.interfaces.LoomException: Component named
"mailstore" failed to pass through the Starting stage. (Reason:
java.lang.NoClassDefFoundError:
org/apache/avalon/excalibur/io/ExtensionFileFilter).
jvm 1 | at
org.codehaus.loom.components.util.lifecycle.LifecycleHelper.fail(LifecycleHelper.java:396)
jvm 1 | at
org.codehaus.loom.components.util.lifecycle.LifecycleHelper.startup(LifecycleHelper.java:267)
jvm 1 | at
org.codehaus.loom.components.application.DefaultApplication.startup(DefaultApplication.java:490)
jvm 1 | at
org.codehaus.loom.components.application.DefaultApplication.doRunPhase(DefaultApplication.java:435)
jvm 1 | at
org.codehaus.loom.components.application.DefaultApplication.runPhase(DefaultApplication.java:363)
jvm 1 | at
org.codehaus.loom.components.application.DefaultApplication.initialize(DefaultApplication.java:188)
jvm 1 | at
org.codehaus.dna.impl.ContainerUtil.initialize(ContainerUtil.java:119)
jvm 1 | at
org.codehaus.loom.components.kernel.DefaultKernel.startup(DefaultKernel.java:322)
jvm 1 | at
org.codehaus.loom.components.kernel.DefaultKernel.addApplication(DefaultKernel.java:419)
jvm 1 | at
org.codehaus.loom.components.deployer.DefaultDeployer.deploy(DefaultDeployer.java:409)
jvm 1 | at
org.codehaus.loom.components.monitor.DefaultDeploymentMonitor.deployApplication(DefaultDeploymentMonitor.java:269)
jvm 1 | at
org.codehaus.loom.components.monitor.DefaultDeploymentMonitor.deployFiles(DefaultDeploymentMonitor.java:393)
jvm 1 | at
org.codehaus.loom.components.monitor.DefaultDeploymentMonitor.deployDefaultApplications(DefaultDeploymentMonitor.java:376)
jvm 1 | at
org.codehaus.loom.components.monitor.DefaultDeploymentMonitor.initialize(DefaultDeploymentMonitor.java:183)
jvm 1 | at
org.codehaus.dna.impl.ContainerUtil.initialize(ContainerUtil.java:119)
jvm 1 | at
org.codehaus.loom.components.embeddor.DefaultEmbeddor.setupComponent(DefaultEmbeddor.java:501)
jvm 1 | at
org.codehaus.loom.components.embeddor.DefaultEmbeddor.setupComponents(DefaultEmbeddor.java:480)
jvm 1 | at
org.codehaus.loom.components.embeddor.DefaultEmbeddor.initialize(DefaultEmbeddor.java:219)
jvm 1 | at
org.codehaus.dna.impl.ContainerUtil.initialize(ContainerUtil.java:119)
jvm 1 | at
org.codehaus.loom.frontends.CLIMain.startup(CLIMain.java:291)
jvm 1 | at
org.codehaus.loom.frontends.CLIMain.execute(CLIMain.java:225)
jvm 1 | at
org.codehaus.loom.frontends.CLIMain.main(CLIMain.java:207)
jvm 1 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
jvm 1 | at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source)
jvm 1 | at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
jvm 1 | at java.lang.reflect.Method.invoke(Unknown Source)
jvm 1 | at org.codehaus.loom.launcher.Main.startup(Main.java:185)
jvm 1 | at
org.codehaus.loom.launcher.DaemonLauncher.start(DaemonLauncher.java:144)
jvm 1 | at
org.tanukisoftware.wrapper.WrapperManager.startInner(WrapperManager.java:1785)
jvm 1 | at
org.tanukisoftware.wrapper.WrapperManager.handleSocket(WrapperManager.java:2384)
jvm 1 | at
org.tanukisoftware.wrapper.WrapperManager.run(WrapperManager.java:2696)
jvm 1 | at java.lang.Thread.run(Unknown Source)
jvm 1 | Caused by: java.lang.NoClassDefFoundError:
org/apache/avalon/excalibur/io/ExtensionFileFilter
jvm 1 | at
org.apache.james.mailrepository.filepair.AbstractFileRepository.initialize(AbstractFileRepository.java:102)
jvm 1 | at
org.apache.avalon.cornerstone.blocks.masterstore.RepositoryManager.select(RepositoryManager.java:191)
jvm 1 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
jvm 1 | at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source)
jvm 1 | at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
jvm 1 | at java.lang.reflect.Method.invoke(Unknown Source)
jvm 1 | at
org.codehaus.loom.components.application.BlockInvocationHandler.invoke(BlockInvocationHandler.java:171)
jvm 1 | at $Proxy1.select(Unknown Source)
jvm 1 | at
org.apache.james.mailrepository.AvalonMailRepository.initialize(AvalonMailRepository.java:125)
jvm 1 | at
org.apache.james.core.AvalonMailStore.select(AvalonMailStore.java:300)
jvm 1 | at
org.apache.james.core.AvalonMailStore.initialize(AvalonMailStore.java:129)
jvm 1 | at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283)
jvm 1 | at
org.codehaus.loom.components.util.lifecycle.LifecycleHelper.startup(LifecycleHelper.java:239)
jvm 1 | ... 30 more
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Phoenix. (Re: RC2 Builds)
Posted by Stefano Bagnara <ap...@bago.org>.
> Leo,
> Thanks. I'll take a look at these. I tried getting the
> latest version of Loom. But it didn't work when I tried to
> load James. Missing jar. I will play with it a bit more, I
> imagine it is a jar version problem. The instrumentation
> code in Loom is pretty old. It is using the old API before I
> restructured it last year.
>
> Do you know what James is planning to do in the future?
> Being built on top of a frozen code base doesn't seem optimal
> in the long term
Never tried to use loom, what is the missing jar?
I've just committed to james an upgrade to the latest avalon-framework,
cornerstone and excalibur libs.
I also rebuilt/updated the bundled phoenix to use the latest
avalon-framework libs.
It seems to work fine.
We probably release a 2.3.0 or 3.0 still built over avalon. We will probably
move to OSGi or a different container later.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Phoenix. (Re: RC2 Builds)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Leo,
Thanks. I'll take a look at these. I tried getting the latest
version of Loom. But it didn't
work when I tried to load James. Missing jar. I will play with it a
bit more, I imagine it
is a jar version problem. The instrumentation code in Loom is pretty
old. It is using the
old API before I restructured it last year.
Do you know what James is planning to do in the future? Being built
on top of a
frozen code base doesn't seem optimal in the long term
Thanks for pointing me to these repositories.
Cheers,
Leif
Leo Simons wrote:
>Leif Mortenson wrote:
>
>
>>Where is Phoenix now?
>>
>>
>
>http://cvs.apache.org/viewcvs.cgi/avalon-phoenix/
>:pserver:anoncvs@cvs.apache.org:/home/cvspublic
>
> was migrated to
>
>http://cvs.apache.org/viewcvs.cgi/avalon/cvs-migration-snapshot/avalon-phoenix/?root=Apache-SVN
>https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoenix
>
> and various tagged versions can be found under
>
>http://cvs.apache.org/viewcvs.cgi/avalon/tags/?root=Apache-SVN
>https://svn.apache.org/repos/asf/avalon/tags
>
> (with of course there being the same tags on CVS as well)
> though looking at all that I'm afraid 4.0.4 was never tagged.
>
> Distributions are still at
>
>http://www.apache.org/dyn/closer.cgi/avalon/phoenix
>
> After they are removed from the mirroring system a few years from now,
> they'll still be at
>
>http://archive.apache.org/dist/avalon/phoenix/
>
> Documentation is currently not available online.
>
>
>
>> Does it exist in a repository that can be modified at this point?
>>
>>
>
>No (not at Apache, that is).
>
>
>
>>I started using James recently and wanted to get Instrumentation into
>>Phoenix. I had thought that it was frozen though.
>>
>>
>
>I've been suggesting that people take a look at Codehaus Loom:
>
> http://loom.codehaus.org/
>
>which one could be tempted to call a heavily modified and cleaned up
>phoenix 4.1 (perhaps dub it "phoenix 5"). They have instrumentation
>support I think.
>
>cheers,
>
>Leo
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
>For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Phoenix. (Re: RC2 Builds)
Posted by Leo Simons <ma...@leosimons.com>.
Leif Mortenson wrote:
> Where is Phoenix now?
http://cvs.apache.org/viewcvs.cgi/avalon-phoenix/
:pserver:anoncvs@cvs.apache.org:/home/cvspublic
was migrated to
http://cvs.apache.org/viewcvs.cgi/avalon/cvs-migration-snapshot/avalon-phoenix/?root=Apache-SVN
https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoenix
and various tagged versions can be found under
http://cvs.apache.org/viewcvs.cgi/avalon/tags/?root=Apache-SVN
https://svn.apache.org/repos/asf/avalon/tags
(with of course there being the same tags on CVS as well)
though looking at all that I'm afraid 4.0.4 was never tagged.
Distributions are still at
http://www.apache.org/dyn/closer.cgi/avalon/phoenix
After they are removed from the mirroring system a few years from now,
they'll still be at
http://archive.apache.org/dist/avalon/phoenix/
Documentation is currently not available online.
> Does it exist in a repository that can be modified at this point?
No (not at Apache, that is).
> I started using James recently and wanted to get Instrumentation into
> Phoenix. I had thought that it was frozen though.
I've been suggesting that people take a look at Codehaus Loom:
http://loom.codehaus.org/
which one could be tempted to call a heavily modified and cleaned up
phoenix 4.1 (perhaps dub it "phoenix 5"). They have instrumentation
support I think.
cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Phoenix. (Re: RC2 Builds)
Posted by peter royal <pr...@apache.org>.
On Aug 15, 2005, at 7:42 PM, Leif Mortenson wrote:
> Where is Phoenix now? Does it exist in a repository that can be
> modified at this point?
> I started using James recently and wanted to get Instrumentation
> into Phoenix. I had
> thought that it was frozen though.
The latest (never released) Phoenix has Instrumentation support. I
can send a snapshot of the old CVS if needed. (I'm using it and it
rocks!)
-pete
--
peter royal
Phoenix. (Re: RC2 Builds)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Where is Phoenix now? Does it exist in a repository that can be
modified at this point?
I started using James recently and wanted to get Instrumentation into
Phoenix. I had
thought that it was frozen though.
Cheers,
Leif
Stefano Bagnara wrote:
>I'm a James (Apache mail server) committer and i would like to know your
>opinion about libraries upgrade.
>Our current trunk is build against avalon 4.1.4 and runs under phoenix
>4.0.5.
>Should we try to upgrade to the latest excalibur libs?
>Will Phoenix run with the latest avalon libs?
>
>Most cornerstone libs we use are 1.0: is it a big work to upgrade to the
>latest?
>
>Thank you for any preliminary suggestion,
>Stefano
>
>
>
>>RC2 builds are now available at:
>>http://people.apache.org/~shash/dist/. Framework is at 4.3,
>>Fortress is at 1.2, everything else at 2.1.
>>
>>Primarily, changes are in: avalon-logkit,
>>excalibur-datasource, excalibur-logger,
>>excalibur-sourceresolve, excalibur-xmlutil,
>>cornerstone-threads. The rest of the updated JARs are
>>because of dependency changes.
>>
>>Barring unforeseen changes, the final release will be on August 28.
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
>For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: RC2 Builds
Posted by Stefano Bagnara <ap...@bago.org>.
I'm a James (Apache mail server) committer and i would like to know your
opinion about libraries upgrade.
Our current trunk is build against avalon 4.1.4 and runs under phoenix
4.0.5.
Should we try to upgrade to the latest excalibur libs?
Will Phoenix run with the latest avalon libs?
Most cornerstone libs we use are 1.0: is it a big work to upgrade to the
latest?
Thank you for any preliminary suggestion,
Stefano
> RC2 builds are now available at:
> http://people.apache.org/~shash/dist/. Framework is at 4.3,
> Fortress is at 1.2, everything else at 2.1.
>
> Primarily, changes are in: avalon-logkit,
> excalibur-datasource, excalibur-logger,
> excalibur-sourceresolve, excalibur-xmlutil,
> cornerstone-threads. The rest of the updated JARs are
> because of dependency changes.
>
> Barring unforeseen changes, the final release will be on August 28.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org