On Sep 10, 2005, at 1:25 PM, Stefano Bagnara wrote:
my company deploys the phoenix trunk. its not the tip, but
its a 4.1 alpha release from early 2003. it has been solid
with zero problems, which is why we're still using it.
Is there a list of known bugs of the current trunk?
not that i know
On 9/12/05, Soren Hilmer <[EMAIL PROTECTED]> wrote:
> >
> > Does phoenix trunk supports hotdeploy/undeploy/reload of applications?
>
> Not sure about hotdeploy, but undeploy and reload are suported.
> Both can be achieved through the JMX interface.
> One caveat with James and our standard distribu
>
> Does phoenix trunk supports hotdeploy/undeploy/reload of applications?
Not sure about hotdeploy, but undeploy and reload are suported.
Both can be achieved through the JMX interface.
One caveat with James and our standard distribution is that, Phoenix is ran in
a mode where it shuts-down whe
> my company deploys the phoenix trunk. its not the tip, but
> its a 4.1 alpha release from early 2003. it has been solid
> with zero problems, which is why we're still using it.
Is there a list of known bugs of the current trunk?
Why did noone made a release of it?
Are you using it with bundled
On Sep 7, 2005, at 7:46 PM, Noel J. Bergman wrote:
I'm not sure I would like to use phoenix-trunk: does any
other project use it?
Does anyone use LOOM?
i know of no deployments. not saying that there are any, just that
its not public.
my company deploys the phoenix trunk. its not the tip,
> > IMHO we still have the problem with spaces in the
> config.xml: this is
> > a real problem.
> But isn't there any simple solution to this 'space problem'?
>
> I always thought(me naive) that such issues are just a matter
> of parser configuration, cause we talk about XML here :).
Yes and n
IMHO we still have the problem with spaces in the config.xml: this is a real
problem.
But isn't there any simple solution to this 'space problem'?
I always thought(me naive) that such issues are just a matter of parser
configuration,
cause we talk about XML here :).
Probably phoenix-trunk is
> > (my idea was a little different but I saw the first reaction and I
> > changed my mind).
> But no commiter gave a -1 till yet. Why shouldn't we switch
> if it works for you?
I didn't run a vote ;-)
> Did anyone proved the contrary or had any founded with tests
> argument - except FUD?
IMH
Does anyone use LOOM?
If it does the job we need, why shouln't we use it till
the 'great POJO-fication' that might(or not) come in the far future.
From what Peter Royal told me, I understood that development on LOOM is
dead.
Judging from the source code, if LOOM is dead than Avalon could be
> Good! Attach some dates and we have a release plan!
Right, but we are not a company and we advance with sparetime so we can
simply decide the order of steps in the cycle and not dates.
> [...]
> The alpha phase can be shortened if there are less features
> still being put in. I think it is imp
(my idea was a little different but I saw the first reaction and I changed
my mind).
But no commiter gave a -1 till yet. Why shouldn't we switch if it works for you?
Did anyone proved the contrary or had any founded with tests argument - except
FUD?
After that we could still investigate that 's
> > I'm not sure I would like to use phoenix-trunk: does any
> other project
> > use it?
>
> Does anyone use LOOM?
>
> From what Peter Royal told me, I understood that development
> on LOOM is dead. And we don't have access to the code. I'd
> like to hear from Peter regarding Loom vs Phoeni
Good! Attach some dates and we have a release plan!
Since there was talk about feature freeze, I thought we were somewhere
before the release cycle. I didn't really follow the alpha series for
2.2.0, so I wasn't aware that there will be a bunch of them.
The alpha phase can be shortened if the
> I'm not sure I would like to use phoenix-trunk: does any
> other project use it?
Does anyone use LOOM?
>From what Peter Royal told me, I understood that development on LOOM is
dead. And we don't have access to the code. I'd like to hear from Peter
regarding Loom vs Phoenix, but he seemed will
> > We also, in the last month:
> > - updated all of our libraries
> > (cornerstone/avalon/excalibur/dnsjava/javamail)
> > - updated phoenix (so as you can see we already "changed" the
> > container)
>
> For me, a container change *has a big impact* (specially
> because it is a partially "dead"
> Ok, my view is that we should release a firts and last alpha
> now and start the beta cycle :-)
I agree, but I don't think we should stop and wait for a release. We should
just move forward as much as possible and when someone with rights/knowledge
to do the release (probably Noel in mid octobe
Ok, my view is that we should release a firts and last alpha now and start the
beta cycle :-)
Vincenzo
Stefano Bagnara wrote:
I thought the 2.3.0 release was coming up shortly?
You mean that it is the right time to put Loom in, just
before releasing the RCs for 2.3.0. Is it correct that your
Stefano Bagnara wrote:
Not totally true, as I think that some people (like myself)
has been thoroughly testing even in production the contents
of svn. Specially after Noel's work in May, which has been a
major (and potentially risky) update impacting the whole
system ... And James looked quite
> I thought the 2.3.0 release was coming up shortly?
>
> You mean that it is the right time to put Loom in, just
> before releasing the RCs for 2.3.0. Is it correct that your
> point is that real testing will be done with the RCs, not
> with the trunk?
>
> Cheers,
Let me explain what is the r
> > The fact that has passed an year since the 2.2.0 does not
> mean we made
> > testing an year of tests on the current trunk. *real time* is not a
> > variable for trunk stability.
> >
>
> I thought the 2.3.0 release was coming up shortly?
>
> You mean that it is the right time to put Loom
> Not totally true, as I think that some people (like myself)
> has been thoroughly testing even in production the contents
> of svn. Specially after Noel's work in May, which has been a
> major (and potentially risky) update impacting the whole
> system ... And James looked quite stable after
Stefano Bagnara wrote:
In general I prefer to do big changes just after a release,
not just before... which in any case would not make such a
difference if releases are made often.
WE ARE just after a release as we never released an alpha of 2.3.0 release
and the last release (2.2.0) was a fi
Not totally true, as I think that some people (like myself) has been thoroughly testing even in production the contents
of svn. Specially after Noel's work in May, which has been a major (and potentially risky) update impacting the whole
system ... And James looked quite stable after that.
Vinc
Hes Siemelink wrote:
Stefano Bagnara wrote:
On the whole it sounds like a good plan, but I would not do it for
the upcoming release.
Why?
It helps fixing current bugs (see classloader issues).
Since this change has impact on the entire product, there might be
more issues. It needs a to
> In general I prefer to do big changes just after a release,
> not just before... which in any case would not make such a
> difference if releases are made often.
WE ARE just after a release as we never released an alpha of 2.3.0 release
and the last release (2.2.0) was a final.
The fact that
Stefano Bagnara wrote:
On the whole it sounds like a good plan, but I would not do
it for the upcoming release.
Why?
It helps fixing current bugs (see classloader issues).
Since this change has impact on the entire product, there might be more
issues. It needs a to be tested thoroughly and
> On the whole it sounds like a good plan, but I would not do
> it for the upcoming release.
Why?
It helps fixing current bugs (see classloader issues).
> And why is there a 1.0RC3 that hasn't seen development in six months?
> Will there be a 1.0 release at all?
Maybe no, but I would feel bett
Stefano Bagnara wrote:
Should we move to Loom?
I've tested it today and the changes I had to do in order to run inside Loom
have been:
1) remove all the spaces from XML: loom does not automatically remove spaces
so leaving the spaces in the config means misconfiguration.
This should be fixed..
> Again to me, if we get rid of the whitespace issue so we can
> basically use the same configuration file, this seems like a
> change worth discussing.
I think we should first discussing then try to make it work.
I don't want to loose time "hacking" loom and then stop against a -1.
I will work
On 9/7/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> I've already said this a lot of time: it will take A LOT of time to move
> away from avalon/cornerstone/excalibur. IMHO it would be really a big
> mistake to continue to think to that move as a near move. I'm almost sure
> that james will cont
On 9/7/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > > - I've not been able to run james in "Phoenix trunk"
> >
> > Peter Royal indicated that he would help us with any Phoenix
> > changes that we really needed.
>
> I'm not sure I would like to use phoenix-trunk: does any other project use
>
> > Should we move to Loom?
>
> Not if it means some of the things you noted. I am
> particularly not keen to start using more excalibur code
> instead of Jakarta Commons code.
IMHO this is not more dependency on excalibur code! We already using that
jar: using that class we could remove our d
I am with Noel on this. We should not do anything that means we get tied more
to Avalon/Excalibur.
On the other hand I liked the advantages a lot, as I have experienced massive
classloader problems with Phoenix, I do a lot of dynamic reloading of .sar's
and on Windows this leads to lost handles
> > - I've not been able to run james in "Phoenix trunk"
>
> Peter Royal indicated that he would help us with any Phoenix
> changes that we really needed.
I'm not sure I would like to use phoenix-trunk: does any other project use
it?
I feel really better with loom. It just reported good errors
> - I've not been able to run james in "Phoenix trunk"
Peter Royal indicated that he would help us with any Phoenix changes that we
really needed.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comm
> Should we move to Loom?
Not if it means some of the things you noted. I am particularly not keen to
start using more excalibur code instead of Jakarta Commons code.
> we could avoid using DBCP at all.
But we want to use DBCP. It is well-tested, supported and broadly used.
And I really don't
> The advantages for the changes are:
5) Loom currently has a website (http://loom.codehaus.org/) with
informations for the deployer the administrator, the assembler and even if
it is not updated so often it is a lot better than the avalon site
(http://avalon.apache.org/closed.html).
More conside
Should we move to Loom?
I've tested it today and the changes I had to do in order to run inside Loom
have been:
1) remove all the spaces from XML: loom does not automatically remove spaces
so leaving the spaces in the config means misconfiguration.
2) change the data-source configuration to use
or
38 matches
Mail list logo
