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 Paul Hammant <Pa...@yahoo.com> on 2002/05/17 02:09:28 UTC
Phoenix upgraded.
Folks,
It is upgraded and tested (up to a point ... I configured a news client
and posted some messages).
What has happened ....
1) We've upgraded Phoenix to latest from CVS. It is quite stable now
and will be released soon. Phoenix is in a dir called 'phoenix-bin' It
is the same as created by the 'dist-lite' target of Phoenix itself.
Thus it will be easy to keep upgraded in future. This is the same
design as I use for Enterprise Object Broker, that I'm sure non of you
have looked at. Sigh.... ;-)
2) Libs/ has been trimmed. All as a consequence of (1). Many jars are
deilvered in a standard phoenix distribution, so it is best to keep them
in site (and add to classpath for compilation). The side effect of this
is that the newbie can look at them and see what James is directly using
that is not delivered by Avalon (and its subcomps).
3) The build file has been changed to reflect the new locations of
things. There is a new target called 'install' that shoves the sar into
phoenix-bin/apps/ . If you go into phoenix-bin/bin/ and run.bat|sh then
Phoenix will launch and load James. There is also a 'dist2' target that
makes distributables. I have not overwritten 'dist' as there is much in
there I did not want to wipe out. You guys will have to look at things
yourselves. You'll also note there is a SAR taskdef.
Notes -
a) Only two (the new ones) targets have descriptions in build.xml
b) There is a way of generating xinfo files now. Peter has made a
xdoclet type thing.
c) If there are no methods in a service, then there is no need to have
an interface now. Refactor rules say that one should not create marker
interfaces, if there are no methods.
d) You now have compatibility with other features of modern Avalon.
AltRMI (seriously - check this out, or its cornerstone adapter).
Managability of services (see management-access-point in cornerstone
source.
e) We are also switching to Serviceable from Composable. We debated it
long and hard and felt in was necessary to kill the Component (empty)
interface. We differed about implementation, and compromised on a
migration route that did not render previously compiled jars incompatible.
f) HypersonicSQL has a block wrapper. You could include a database in
the sar file now.
g) SimpleStore (jakarta-commons) is being Phoenix enabled. It could
replace 'store' and makes abstractions for storage types itself.
h) There is a webserver called Jo! that is SAR compatible, If you want
a web app management suite, then you can have that in the JAR too.
I await the bug reports, hoping there are none and that I can be trimed
from the committer list... Keep up the good work folks ..... death to
spammers!
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenix upgraded.
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
> b) There is a way of generating xinfo files now. Peter has made a
> xdoclet type thing.
This is how you use it -> see javadoc tags. This also show Serviceable
which is a simple migration from Composable....
-ph
/**
* This is the service through which ConnectionManagement occurs.
*
* @phoenix:service
name="org.apache.avalon.cornerstone.services.connection.ConnectionManager"
*
* @author <a href="mailto:peter@apache.org">Peter Donald</a>
*/
public class DefaultConnectionManager
extends AbstractLogEnabled
implements Block, ConnectionManager, Serviceable, Disposable
{
private HashMap m_connections = new HashMap();
private ThreadManager m_threadManager;
/**
* @phoenix:dependency
name="org.apache.avalon.cornerstone.services.threads.ThreadManager"
*/
public void service( final ServiceManager serviceManager )
throws ServiceException
{
m_threadManager = (ThreadManager)serviceManager.lookup(
ThreadManager.ROLE );
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenix upgraded.
Posted by Serge Knystautas <se...@lokitech.com>.
Oh, and Paul, thank you very much for your help getting James current!!
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Paul Hammant wrote:
> Folks,
>
> It is upgraded and tested (up to a point ... I configured a news client
> and posted some messages).
>
> What has happened ....
>
> 1) We've upgraded Phoenix to latest from CVS. It is quite stable now
> and will be released soon. Phoenix is in a dir called 'phoenix-bin' It
> is the same as created by the 'dist-lite' target of Phoenix itself. Thus
> it will be easy to keep upgraded in future. This is the same design as
> I use for Enterprise Object Broker, that I'm sure non of you have looked
> at. Sigh.... ;-)
>
> 2) Libs/ has been trimmed. All as a consequence of (1). Many jars are
> deilvered in a standard phoenix distribution, so it is best to keep them
> in site (and add to classpath for compilation). The side effect of this
> is that the newbie can look at them and see what James is directly using
> that is not delivered by Avalon (and its subcomps).
>
> 3) The build file has been changed to reflect the new locations of
> things. There is a new target called 'install' that shoves the sar into
> phoenix-bin/apps/ . If you go into phoenix-bin/bin/ and run.bat|sh then
> Phoenix will launch and load James. There is also a 'dist2' target that
> makes distributables. I have not overwritten 'dist' as there is much in
> there I did not want to wipe out. You guys will have to look at things
> yourselves. You'll also note there is a SAR taskdef.
>
> Notes -
>
> a) Only two (the new ones) targets have descriptions in build.xml
>
> b) There is a way of generating xinfo files now. Peter has made a
> xdoclet type thing.
>
> c) If there are no methods in a service, then there is no need to have
> an interface now. Refactor rules say that one should not create marker
> interfaces, if there are no methods.
>
> d) You now have compatibility with other features of modern Avalon.
> AltRMI (seriously - check this out, or its cornerstone adapter).
> Managability of services (see management-access-point in cornerstone
> source.
> e) We are also switching to Serviceable from Composable. We debated it
> long and hard and felt in was necessary to kill the Component (empty)
> interface. We differed about implementation, and compromised on a
> migration route that did not render previously compiled jars incompatible.
>
> f) HypersonicSQL has a block wrapper. You could include a database in
> the sar file now.
>
> g) SimpleStore (jakarta-commons) is being Phoenix enabled. It could
> replace 'store' and makes abstractions for storage types itself.
>
> h) There is a webserver called Jo! that is SAR compatible, If you want
> a web app management suite, then you can have that in the JAR too.
>
>
> I await the bug reports, hoping there are none and that I can be trimed
> from the committer list... Keep up the good work folks ..... death to
> spammers!
>
> Regards,
>
> - Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenix upgraded.
Posted by Serge Knystautas <se...@lokitech.com>.
I have a bunch of small patches to make to docs, code, whatever. I'll
also try to test the JDBC and other things I use in James.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Paul Hammant wrote:
> Folks,
>
> It is upgraded and tested (up to a point ... I configured a news client
> and posted some messages).
>
> What has happened ....
>
> 1) We've upgraded Phoenix to latest from CVS. It is quite stable now
> and will be released soon. Phoenix is in a dir called 'phoenix-bin' It
> is the same as created by the 'dist-lite' target of Phoenix itself. Thus
> it will be easy to keep upgraded in future. This is the same design as
> I use for Enterprise Object Broker, that I'm sure non of you have looked
> at. Sigh.... ;-)
>
> 2) Libs/ has been trimmed. All as a consequence of (1). Many jars are
> deilvered in a standard phoenix distribution, so it is best to keep them
> in site (and add to classpath for compilation). The side effect of this
> is that the newbie can look at them and see what James is directly using
> that is not delivered by Avalon (and its subcomps).
>
> 3) The build file has been changed to reflect the new locations of
> things. There is a new target called 'install' that shoves the sar into
> phoenix-bin/apps/ . If you go into phoenix-bin/bin/ and run.bat|sh then
> Phoenix will launch and load James. There is also a 'dist2' target that
> makes distributables. I have not overwritten 'dist' as there is much in
> there I did not want to wipe out. You guys will have to look at things
> yourselves. You'll also note there is a SAR taskdef.
>
> Notes -
>
> a) Only two (the new ones) targets have descriptions in build.xml
>
> b) There is a way of generating xinfo files now. Peter has made a
> xdoclet type thing.
>
> c) If there are no methods in a service, then there is no need to have
> an interface now. Refactor rules say that one should not create marker
> interfaces, if there are no methods.
>
> d) You now have compatibility with other features of modern Avalon.
> AltRMI (seriously - check this out, or its cornerstone adapter).
> Managability of services (see management-access-point in cornerstone
> source.
> e) We are also switching to Serviceable from Composable. We debated it
> long and hard and felt in was necessary to kill the Component (empty)
> interface. We differed about implementation, and compromised on a
> migration route that did not render previously compiled jars incompatible.
>
> f) HypersonicSQL has a block wrapper. You could include a database in
> the sar file now.
>
> g) SimpleStore (jakarta-commons) is being Phoenix enabled. It could
> replace 'store' and makes abstractions for storage types itself.
>
> h) There is a webserver called Jo! that is SAR compatible, If you want
> a web app management suite, then you can have that in the JAR too.
>
>
> I await the bug reports, hoping there are none and that I can be trimed
> from the committer list... Keep up the good work folks ..... death to
> spammers!
>
> Regards,
>
> - Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>