You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/10/24 17:32:16 UTC
Minutes from AvalonCon #1
Minutes from unofficial AvalonCon, London Thurs 11th Oct 2001.
Present:
Charles Bennett
Kai Eris
Liam Holohan
Paul Hammant
Pratik Patel
Notes taken by Liam, embellished by Paul and Pratik after the event.
P1) Assembly (or re-assembly) needs to be revisited i.e. possibly have a
GUI as a alternative.
Reason : assembly is too hard for assembler, if they are not taking the
defaults setup by the relevant build script. Assembly seems to a
programmers task, rather than an "assemblers" task.
P2) Avalon needs to evaluate class loading w.r.t kernel and its
applications.
i.e. how do servers know that "this" is the http server. Or put another
way, no inter sar communications or dependencies.
Of note is Tomcat's concept of trees -
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
P3) The FAQ needs to be updated. Experience of "new guy" should be
incorporated into the faq/docs ("Woods for the Trees" anti-pattern).
P4) Too many servers need sar files without proper federation. I think
this is similar to P2. Perhaps this can be rephrased as:
SAR files should be able to register* their offered services to a
'registry' in the kernel. This registry can take the form of a JNDI
registry. SARs can do a lookup to attain if and what other SAR is
providing a service. This can also be the location where a service can
register itself as a 'default' service within a specific context. For
example, Bay can register itself as the default internal webserver for
handling webapps. An simple example is Tomcat4:
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html.
*Note we don't think the code of the block should do the registration,
we think it is an XML specified assembler duty.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Peter Donald <do...@apache.org>.
On Sun, 28 Oct 2001 21:04, Peter Donald wrote:
> > Now RMI should continue to be used for client to server comms (JAMES and
> > FTPServer use it for admin), but I really donlt think we need it for the
> > inter-sar communication. Sun, sooner or later, are going to come along
> > with a fresh replacement RMI. They are not adverse to such efforts
> > (look at nio package in JDK1.4). That replacement is going to be a lot
> > easier to use because it will be seamless. The RMI registry needs an
> > overhaul too.
>
> RMI registry is only a toy API that grew as is some of the infrastructure.
> However what I am talking about is the model. Whether it actually uses any
> of the RMI code or rewrites it all (ie RMI/IIOP, RMI/JAXM, RMI/JRMP in EJB
> servers, etc). I still think that being forced to deal with errors where
> they are likely to occur is a good thing.
>
> I guess we will have to agree to disagree ;)
Another way of looking at it is - do you think that it is good or bad that
most database classes declare they throw SQLExceptions? I see it as good - u ?
--
Cheers,
Pete
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Minutes from AvalonCon #1
Posted by Peter Donald <do...@apache.org>.
On Sun, 28 Oct 2001 20:39, Paul Hammant wrote:
> Peter,
>
> >>>Even if we were to create
> >>>Avalon Method Invocation we would still need a AMIException for the same
> >>>use anyways,
> >>
> >>Yes but extend RuntimeException not Exception. GLUE does this and it is
> >>seamless.
> >
> >I like the fact that Remote is not a runtime exception. It forces the
> >developer to write code that behaves nicely in a distributed environment.
> > You should be catching this down low and dealing with them gracefully
> > IMHO ;)
>
> It forces the developer to catch RemoteException at each invocation of a
> remote method. What to do with it?
I usually do something like
Client.remoteException( "Description of what I was doing",
myRemoteException );
> I catch a lot of coders declaring
> it in throws to decrease the amount of code they have to write, suddenly
> you find throws RemoteException proliferating around a system. What to
> do with it?
Bad programmers will write bad code regardless of what you do.
> Try again? Hmm, Typically people have new exceptions like
> "QuoteServiceFailedException" and wrap the remote in that before
> throwing it.
Wrapping exceptions before propogating them up is a standard practice. I do
it all through my code and avalons code ;)
For instance something I was debugging the other day had exceptions nested
like
ActionException -> PersistenceException -> SQLException
> I've had nothing but misery since 98 with RemoteException.
> It's a major pain in the ass that, strictly speaking, you can't even
> test. No I really do prefer handling wobbly connections at a single
> handler level in an API.
See above for an example of that. However choice - especially when it is more
than a simple client-server setup is important.
> >They fixed this in EJBs because now EJBs no longer have to implement the
> >remote interface - yaya!!!!! I have thought about doing a
> > proxy/wrapper/stub compiler that just exported local version and was
> > automagically generated. In a perfect world the setup per class would be
> > something like
> >
> >interface Foo
> >{
> > void doStuff();
> >}
> >class FooImpl implements Foo {}
> >
> >interface RemoteFoo extends Foo
> >{
> > void doStuff() throws RemoteException;
> >}
> >class RemoteFooStub extends RemoteObject implements RemoteFoo { ]
> >
> >The first two would be human created while the second two would be
> > computer generated.
>
> I Just don't like it Peter.
I know ;)
> Now RMI should continue to be used for client to server comms (JAMES and
> FTPServer use it for admin), but I really donlt think we need it for the
> inter-sar communication. Sun, sooner or later, are going to come along
> with a fresh replacement RMI. They are not adverse to such efforts
> (look at nio package in JDK1.4). That replacement is going to be a lot
> easier to use because it will be seamless. The RMI registry needs an
> overhaul too.
RMI registry is only a toy API that grew as is some of the infrastructure.
However what I am talking about is the model. Whether it actually uses any of
the RMI code or rewrites it all (ie RMI/IIOP, RMI/JAXM, RMI/JRMP in EJB
servers, etc). I still think that being forced to deal with errors where they
are likely to occur is a good thing.
I guess we will have to agree to disagree ;)
--
Cheers,
Pete
When a stupid man is doing something he's ashamed of, he always
declares that it is his duty.
George Bernard Shaw
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Minutes from AvalonCon #1
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>Even if we were to create
>>>Avalon Method Invocation we would still need a AMIException for the same
>>>use anyways,
>>>
>>Yes but extend RuntimeException not Exception. GLUE does this and it is
>>seamless.
>>
>
>I like the fact that Remote is not a runtime exception. It forces the
>developer to write code that behaves nicely in a distributed environment. You
>should be catching this down low and dealing with them gracefully IMHO ;)
>
It forces the developer to catch RemoteException at each invocation of a
remote method. What to do with it? I catch a lot of coders declaring
it in throws to decrease the amount of code they have to write, suddenly
you find throws RemoteException proliferating around a system. What to
do with it? Try again? Hmm, Typically people have new exceptions like
"QuoteServiceFailedException" and wrap the remote in that before
throwing it. I've had nothing but misery since 98 with RemoteException.
It's a major pain in the ass that, strictly speaking, you can't even
test. No I really do prefer handling wobbly connections at a single
handler level in an API. Plenty of others do too. Take a look at
Glue's examples Peter (
http://www.themindelectric.com/products/glue/releases/GLUE-1.3/docs/guide/exceptions.html
-> sample calculator exception is simple enough).
>About the only thing that really and truly sucks about RMI is that you have
>to have two versions of interfaces and that your implementation has to
>implement the Remote version (bleck!!!).
>
Agree it sucks. Not agree on "only".
>They fixed this in EJBs because now EJBs no longer have to implement the
>remote interface - yaya!!!!! I have thought about doing a proxy/wrapper/stub
>compiler that just exported local version and was automagically generated. In
>a perfect world the setup per class would be something like
>
>interface Foo
>{
> void doStuff();
>}
>class FooImpl implements Foo {}
>
>interface RemoteFoo extends Foo
>{
> void doStuff() throws RemoteException;
>}
>class RemoteFooStub extends RemoteObject implements RemoteFoo { ]
>
>The first two would be human created while the second two would be computer
>generated.
>
I Just don't like it Peter.
Now RMI should continue to be used for client to server comms (JAMES and
FTPServer use it for admin), but I really donlt think we need it for the
inter-sar communication. Sun, sooner or later, are going to come along
with a fresh replacement RMI. They are not adverse to such efforts
(look at nio package in JDK1.4). That replacement is going to be a lot
easier to use because it will be seamless. The RMI registry needs an
overhaul too.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Minutes from AvalonCon #1
Posted by Peter Donald <do...@apache.org>.
On Sun, 28 Oct 2001 12:01, Paul Hammant wrote:
> >Even if we were to create
> >Avalon Method Invocation we would still need a AMIException for the same
> > use anyways,
>
> Yes but extend RuntimeException not Exception. GLUE does this and it is
> seamless.
I like the fact that Remote is not a runtime exception. It forces the
developer to write code that behaves nicely in a distributed environment. You
should be catching this down low and dealing with them gracefully IMHO ;)
About the only thing that really and truly sucks about RMI is that you have
to have two versions of interfaces and that your implementation has to
implement the Remote version (bleck!!!).
They fixed this in EJBs because now EJBs no longer have to implement the
remote interface - yaya!!!!! I have thought about doing a proxy/wrapper/stub
compiler that just exported local version and was automagically generated. In
a perfect world the setup per class would be something like
interface Foo
{
void doStuff();
}
class FooImpl implements Foo {}
interface RemoteFoo extends Foo
{
void doStuff() throws RemoteException;
}
class RemoteFooStub extends RemoteObject implements RemoteFoo { ]
The first two would be human created while the second two would be computer
generated.
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Minutes from AvalonCon #1
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>Thus (2) is the best one IMHO at this stage. It would also have the nice
>>>side-effect that we could federate servers. ie the ServletEngine may be on
>>>different host from MailetEngine but they could both talk as if they were
>>>on same machine.
>>>
>>Nooooooooooooo, RMI is flawed - it has that abominable RemoteException
>>thing. Avalon Method Invocation (AMI) is what we want. What ever that is.
>>
>
>How did I know you were going to say that ? ;)
>
Cos we're cursed to say the same things over and over again. Cos we're
cursed to say the same things over and over again ;-)
>Even if we were to create
>Avalon Method Invocation we would still need a AMIException for the same use
>anyways,
>
Yes but extend RuntimeException not Exception. GLUE does this and it is
seamless.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Peter Donald <do...@apache.org>.
On Sun, 28 Oct 2001 00:04, Paul Hammant wrote:
> >Thus (2) is the best one IMHO at this stage. It would also have the nice
> >side-effect that we could federate servers. ie the ServletEngine may be on
> >different host from MailetEngine but they could both talk as if they were
> > on same machine.
>
> Nooooooooooooo, RMI is flawed - it has that abominable RemoteException
> thing. Avalon Method Invocation (AMI) is what we want. What ever that is.
How did I know you were going to say that ? ;) Even if we were to create
Avalon Method Invocation we would still need a AMIException for the same use
anyways,
--
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>>Avalon Method Invocation (AMI) is what we want. What
>>ever that is.
>>
>
>If it means I can spread load by splitting my avalon whatever-it-is server across multiple machines go for it.
>for example.. JAMES with configuration, Mailets & SMTP on one machine and POP & repositories on another seems like a good idea.
>
You could do that now with a block implementation that uses a delegate.
Think org.apache.james.core.AvalonMailStore and
org.apache.james.core.RemoteAvalonMailStore ....
Glue would be an ideal transport until Axis is ready.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Minutes from AvalonCon #1
Posted by Danny Angus <da...@thought.co.uk>.
> Avalon Method Invocation (AMI) is what we want. What
> ever that is.
If it means I can spread load by splitting my avalon whatever-it-is server across multiple machines go for it.
for example.. JAMES with configuration, Mailets & SMTP on one machine and POP & repositories on another seems like a good idea.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>[ .. assembly .. ]
>>>
>>Yes, but perhaps an Ant task before then. Automation is more important
>>that interactive replacement.
>>
>
>The problem is it quickly requires human intervention for most things. ie
>Merging configuration and adding .jar files is simple enough but how do you
>manage dependencies between blocks. If you are replacing another block then
>it *should* be easy but it gets really tricky when you start moving beyond
>that.
>
>>>>P3) The FAQ needs to be updated. Experience of "new guy" should be
>>>>incorporated into the faq/docs ("Woods for the Trees" anti-pattern).
>>>>
>>>+100
>>>
>>>volunteering ? ;)
>>>
>>Perhaps a little with infrastructure. How about we ask people we are
>>helping in the list to contribute what then feel to be a decent FAQ
>>point after we've helped them in the list. Vinay's cryptic:
>>
>> "How does one service access the instance of another Service.?"
>>
>>Is a good example of not knowig where to start (as we're all so familiar).
>>
>
>Im happy to answer questions if you want to create a list of them, chuck them
>in a faq.xml and get it generating stuff properly ;)
>
Cool will do. From now on can we compel newbies to FAQize their
questions and the resulting answers to asist the FAQ program.
>>>+1 Phoenix has needed this ever since we went from a 2-layer app to a
>>>3-layer app. (About a year ago?). However before we can do this there is
>>>2 issues we really need to resolve. One is the ClassLoader issue and the
>>>other is the definition of the interface.
>>>
>>Re Interfaces, I'd like to see support for multiple versions of the same
>>interface.
>>
>
>Should be possible - especially as I no longer see apps sharing any
>classloader stuff. We can use the jdk1.3 Proxy stuff or BCEL to implement
>this I think.
>
Indeed.
>>Re Classloader, you know my daft ideas. I'll re-read your RT thread,
>>
>
>promotion ? sorry still don't like that idea ;)
>
I don't like it anymore either, It was a cool trick bat had loads of
downsides. Proxy of some sort is the answer.
>>>The other is the definition of the interface. The problem arises is how do
>>>we know when the interface has been invalidated? We could let the
>>>application know with another Event listener interface but that seems
>>>like overkill. The other alternative is to make it a Remote interface but
>>>I know how much you hate that ;)
>>>
>>Invalidated? You mean dependancies. EJB need to know when Tomcat is
>>stopping? Perhaps Tomcat can't stop until things that use it have?
>>
>
>This would actually make Phoenix's Application very similar to the notion of
>a Partition as per HP's CSF framework (and the Services JSR basis).
>
>Is this a good thing or not ? Not sure. It could be painful because you could
>force a whole bunch of things to go down unecessarily when you want to swap
>an application.
>
>It would be even worse when the application was a container (ie a servlet or
>mailet container) and the components it contained (servlet or mailet)
>depended on another application and that other application depended on on the
>container application.
>
>ie in more simple terms
>
>A and B are applications.
>B depends on A
>A contains P sub-component.
>P depends on B
>
That is a very complex example. Not sure it would ever exist as it is
circular.
>So given this there are three options.
>1. Have the interfaces throw a IllegalStateException when invalidated
>2. Have the interfaces be a rmi Remote interface
>3. Have the interfaces only accesible via a reflection-like ability (similar
>to JMX). eg
>
>otherObject.invoke( "performAction", new Object[] { param1, param2 } );
>
>
>(3) is too clunky for users in my mind.
>
Agree, but it would work. Almost Bean Scripting Framework like. Hmmmm.
>(1) encourages bad programming
>practices and could lead to faulty applications relatively easy.
>
Yup.
>Thus (2) is the best one IMHO at this stage. It would also have the nice
>side-effect that we could federate servers. ie the ServletEngine may be on
>different host from MailetEngine but they could both talk as if they were on
>same machine.
>
Nooooooooooooo, RMI is flawed - it has that abominable RemoteException
thing. Avalon Method Invocation (AMI) is what we want. What ever that is.
>So maybe the rule would be that anything registered into the JNDI directory
>should be a Remote interface or something ?
>
I'm not sold on the need for a JNDI directory, but others are so I'll
not resisit.
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Peter Donald <do...@apache.org>.
On Fri, 26 Oct 2001 22:45, Paul Hammant wrote:
> Peter,
>
> >fun - now I wish I was a Londonite ;)
>
> Far too much booze was imbibed for lucid conversation!
even better !
;)
> >On Thu, 25 Oct 2001 01:32, Paul Hammant wrote:
> >>P1) Assembly (or re-assembly) needs to be revisited i.e. possibly have a
> >>GUI as a alternative.
> >>Reason : assembly is too hard for assembler, if they are not taking the
> >>defaults setup by the relevant build script. Assembly seems to a
> >>programmers task, rather than an "assemblers" task.
> >
> >yep. Most of the information required for this is available in the
> > BlockInfos etc. If the manifest has also added entries to say something
> > like
> >
> >Avaon-Block: true
> >
> >then it should be easy enough for a GUI assembler to be written. I think
> > ;)
>
> Yes, but perhaps an Ant task before then. Automation is more important
> that interactive replacement.
The problem is it quickly requires human intervention for most things. ie
Merging configuration and adding .jar files is simple enough but how do you
manage dependencies between blocks. If you are replacing another block then
it *should* be easy but it gets really tricky when you start moving beyond
that.
> >Yep. I would like some feedback on the Random Thought I posted a while
> > back in relation to this. If it is liked then I will try to implement it
> > when I get the chance.
> >
> >BTW the title of it was [phoenix] RT: ClassLoader hierarchy
>
> Will have a look again. I think my brain rebooted at first read.
If you can say why it rebooted I will have another shot at explaining it.
Basically it amounted to allowing applications to declare their own
classloader setup. Also most classsloaders except the avalon-framework.jar
and phoenix-client.jar would not be shared but separate instances between
different applications.
> >>P3) The FAQ needs to be updated. Experience of "new guy" should be
> >>incorporated into the faq/docs ("Woods for the Trees" anti-pattern).
> >
> >+100
> >
> >volunteering ? ;)
>
> Perhaps a little with infrastructure. How about we ask people we are
> helping in the list to contribute what then feel to be a decent FAQ
> point after we've helped them in the list. Vinay's cryptic:
>
> "How does one service access the instance of another Service.?"
>
> Is a good example of not knowig where to start (as we're all so familiar).
Im happy to answer questions if you want to create a list of them, chuck them
in a faq.xml and get it generating stuff properly ;)
> >+1 Phoenix has needed this ever since we went from a 2-layer app to a
> > 3-layer app. (About a year ago?). However before we can do this there is
> > 2 issues we really need to resolve. One is the ClassLoader issue and the
> > other is the definition of the interface.
>
> Re Interfaces, I'd like to see support for multiple versions of the same
> interface.
Should be possible - especially as I no longer see apps sharing any
classloader stuff. We can use the jdk1.3 Proxy stuff or BCEL to implement
this I think.
> Re Classloader, you know my daft ideas. I'll re-read your RT thread,
promotion ? sorry still don't like that idea ;)
> >The other is the definition of the interface. The problem arises is how do
> > we know when the interface has been invalidated? We could let the
> > application know with another Event listener interface but that seems
> > like overkill. The other alternative is to make it a Remote interface but
> > I know how much you hate that ;)
>
> Invalidated? You mean dependancies. EJB need to know when Tomcat is
> stopping? Perhaps Tomcat can't stop until things that use it have?
This would actually make Phoenix's Application very similar to the notion of
a Partition as per HP's CSF framework (and the Services JSR basis).
Is this a good thing or not ? Not sure. It could be painful because you could
force a whole bunch of things to go down unecessarily when you want to swap
an application.
It would be even worse when the application was a container (ie a servlet or
mailet container) and the components it contained (servlet or mailet)
depended on another application and that other application depended on on the
container application.
ie in more simple terms
A and B are applications.
B depends on A
A contains P sub-component.
P depends on B
So given this there are three options.
1. Have the interfaces throw a IllegalStateException when invalidated
2. Have the interfaces be a rmi Remote interface
3. Have the interfaces only accesible via a reflection-like ability (similar
to JMX). eg
otherObject.invoke( "performAction", new Object[] { param1, param2 } );
(3) is too clunky for users in my mind. (1) encourages bad programming
practices and could lead to faulty applications relatively easy.
Thus (2) is the best one IMHO at this stage. It would also have the nice
side-effect that we could federate servers. ie the ServletEngine may be on
different host from MailetEngine but they could both talk as if they were on
same machine.
So maybe the rule would be that anything registered into the JNDI directory
should be a Remote interface or something ?
--
Cheers,
Pete
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>fun - now I wish I was a Londonite ;)
>
Far too much booze was imbibed for lucid conversation!
>On Thu, 25 Oct 2001 01:32, Paul Hammant wrote:
>
>>P1) Assembly (or re-assembly) needs to be revisited i.e. possibly have a
>>GUI as a alternative.
>>Reason : assembly is too hard for assembler, if they are not taking the
>>defaults setup by the relevant build script. Assembly seems to a
>>programmers task, rather than an "assemblers" task.
>>
>
>yep. Most of the information required for this is available in the BlockInfos
>etc. If the manifest has also added entries to say something like
>
>Avaon-Block: true
>
>then it should be easy enough for a GUI assembler to be written. I think ;)
>
Yes, but perhaps an Ant task before then. Automation is more important
that interactive replacement.
>>P2) Avalon needs to evaluate class loading w.r.t kernel and its
>>applications.
>>i.e. how do servers know that "this" is the http server. Or put another
>>way, no inter sar communications or dependencies.
>>
>>Of note is Tomcat's concept of trees -
>>http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
>>
>
>Yep. I would like some feedback on the Random Thought I posted a while back
>in relation to this. If it is liked then I will try to implement it when I
>get the chance.
>
>BTW the title of it was [phoenix] RT: ClassLoader hierarchy
>
Will have a look again. I think my brain rebooted at first read.
>>P3) The FAQ needs to be updated. Experience of "new guy" should be
>>incorporated into the faq/docs ("Woods for the Trees" anti-pattern).
>>
>
>+100
>
>volunteering ? ;)
>
Perhaps a little with infrastructure. How about we ask people we are
helping in the list to contribute what then feel to be a decent FAQ
point after we've helped them in the list. Vinay's cryptic:
"How does one service access the instance of another Service.?"
Is a good example of not knowig where to start (as we're all so familiar).
>>P4) Too many servers need sar files without proper federation. I think
>>this is similar to P2. Perhaps this can be rephrased as:
>>SAR files should be able to register* their offered services to a
>>'registry' in the kernel. This registry can take the form of a JNDI
>>registry. SARs can do a lookup to attain if and what other SAR is
>>providing a service. This can also be the location where a service can
>>register itself as a 'default' service within a specific context. For
>>example, Bay can register itself as the default internal webserver for
>>handling webapps. An simple example is Tomcat4:
>>http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html.
>>*Note we don't think the code of the block should do the registration,
>>we think it is an XML specified assembler duty.
>>
>
>+1 Phoenix has needed this ever since we went from a 2-layer app to a 3-layer
>app. (About a year ago?). However before we can do this there is 2 issues we
>really need to resolve. One is the ClassLoader issue and the other is the
>definition of the interface.
>
Re Interfaces, I'd like to see support for multiple versions of the same
interface.
Re Classloader, you know my daft ideas. I'll re-read your RT thread,
>The ClassLoader issue is partly discussed in the RT thread I mentioned in
>last mail. The other part of ClassLoader stuff we have to do is basically
>finish the org.apache.avalon.excalibur.extensions.* classes and integrate
>them into the DefaultClassLoaderManager. This would be easy enough to do I
>think. It just takes time ;)
>
>The other is the definition of the interface. The problem arises is how do we
>know when the interface has been invalidated? We could let the application
>know with another Event listener interface but that seems like overkill. The
>other alternative is to make it a Remote interface but I know how much you
>hate that ;)
>
Invalidated? You mean dependancies. EJB need to know when Tomcat is
stopping? Perhaps Tomcat can't stop until things that use it have?
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Peter Donald <do...@apache.org>.
fun - now I wish I was a Londonite ;)
On Thu, 25 Oct 2001 01:32, Paul Hammant wrote:
> P1) Assembly (or re-assembly) needs to be revisited i.e. possibly have a
> GUI as a alternative.
> Reason : assembly is too hard for assembler, if they are not taking the
> defaults setup by the relevant build script. Assembly seems to a
> programmers task, rather than an "assemblers" task.
yep. Most of the information required for this is available in the BlockInfos
etc. If the manifest has also added entries to say something like
Avaon-Block: true
then it should be easy enough for a GUI assembler to be written. I think ;)
> P2) Avalon needs to evaluate class loading w.r.t kernel and its
> applications.
> i.e. how do servers know that "this" is the http server. Or put another
> way, no inter sar communications or dependencies.
>
> Of note is Tomcat's concept of trees -
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
Yep. I would like some feedback on the Random Thought I posted a while back
in relation to this. If it is liked then I will try to implement it when I
get the chance.
BTW the title of it was [phoenix] RT: ClassLoader hierarchy
> P3) The FAQ needs to be updated. Experience of "new guy" should be
> incorporated into the faq/docs ("Woods for the Trees" anti-pattern).
+100
volunteering ? ;)
> P4) Too many servers need sar files without proper federation. I think
> this is similar to P2. Perhaps this can be rephrased as:
> SAR files should be able to register* their offered services to a
> 'registry' in the kernel. This registry can take the form of a JNDI
> registry. SARs can do a lookup to attain if and what other SAR is
> providing a service. This can also be the location where a service can
> register itself as a 'default' service within a specific context. For
> example, Bay can register itself as the default internal webserver for
> handling webapps. An simple example is Tomcat4:
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html.
> *Note we don't think the code of the block should do the registration,
> we think it is an XML specified assembler duty.
+1 Phoenix has needed this ever since we went from a 2-layer app to a 3-layer
app. (About a year ago?). However before we can do this there is 2 issues we
really need to resolve. One is the ClassLoader issue and the other is the
definition of the interface.
The ClassLoader issue is partly discussed in the RT thread I mentioned in
last mail. The other part of ClassLoader stuff we have to do is basically
finish the org.apache.avalon.excalibur.extensions.* classes and integrate
them into the DefaultClassLoaderManager. This would be easy enough to do I
think. It just takes time ;)
The other is the definition of the interface. The problem arises is how do we
know when the interface has been invalidated? We could let the application
know with another Event listener interface but that seems like overkill. The
other alternative is to make it a Remote interface but I know how much you
hate that ;)
The rest of it (ie JNDI implementation and infrastructure) is ready to go.
Just needs decisions on design to be made ;)
--
Cheers,
Pete
------------------------------------------------------
Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is
the task of journalists and historians to rectify
this error."
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Ulrich Mayring <ul...@denic.de>.
Paul Hammant wrote:
>
> OK, Team A ship a sar file with X Y and Z as blocks. Fred (an
> administrator type person) for a compant decides that he wants to deploy
> with Y2 instead of Y (a better implementation for his setup), he puts on
> his "re-assembler" hat and replaces the block (bar file) in the sar
> file, then deploys it as ususal. "Assembler" was one of the original
> promises of the pluggable component design of Avalon..... it's juste
> never been discussed as a role.
Ok, I do (and did ;-) understand what an assembler has to do. We are
frequently swapping blocks within .sar applications, for example to roll
back to an older version, if the new version misbehaves. This is a very
handy feature of Avalon and everyone loves it. What I was wondering,
however, is whether an Avalon-agnostic person, like a system
administrator, would be allowed or required to do this. I think no. The
decision to use Avalon is made by the developers, the admins want to
know how to stop and start it, but not how to fix something internal to
an Avalon installation or a .sar application.
Therefore I think the role "Assembler" can have the same rights and
duties as the role "Developer". The decision which version of a
server-side software to deploy is ultimately made by the developer - I
haven't seen anything else, at least.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Minutes from AvalonCon #1
Posted by Peter Donald <do...@apache.org>.
On Fri, 26 Oct 2001 22:32, Paul Hammant wrote:
> Ulrich,
>
> >>Reason : assembly is too hard for assembler, if they are not taking the
> >>defaults setup by the relevant build script. Assembly seems to a
> >>programmers task, rather than an "assemblers" task.
> >
> >I haven't seen any concept in the real world, which would suggest
> >creating a seperate role "assembler". What is its purpose?
The role is only useful in a mature system, where there are sets of well made
reusable components. I have seen it work in the context of J2EE framework
where there are several components such as
* databases
* servlets
* ejbs
* swing applications
The assembler basically set up all the default configurations, SQL scripts,
.WAR files, .ear files and so forth. Often developers will work with just one
servlet per war while this guys job was to combine 3 into one war and
integrate them. He also created Installshield like applications to make them
easy to install.
So thats where the idea comes from. While it is probably still too
"developer" orientated atm I hope that in time this will be fixed ;)
--
Cheers,
Pete
--------------------------------------------------
you've made a dangerous leap right over common
sense, like some kind of metaphysical Evil Knievel
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Paul Hammant <Pa...@yahoo.com>.
Ulrich,
>>Reason : assembly is too hard for assembler, if they are not taking the
>>defaults setup by the relevant build script. Assembly seems to a
>>programmers task, rather than an "assemblers" task.
>>
>
>I haven't seen any concept in the real world, which would suggest
>creating a seperate role "assembler". What is its purpose?
>
OK, Team A ship a sar file with X Y and Z as blocks. Fred (an
administrator type person) for a compant decides that he wants to deploy
with Y2 instead of Y (a better implementation for his setup), he puts on
his "re-assembler" hat and replaces the block (bar file) in the sar
file, then deploys it as ususal. "Assembler" was one of the original
promises of the pluggable component design of Avalon..... it's juste
never been discussed as a role.
How about an Ant task?
<zip-replace zip="abc123.sar">
<zipfileset dir="our-impl-of-abc-thing"
fullpath="SAR-INF/lib/abc.bar">
<include name="our-abc.bar"/>
</zipfileset>
</zip-replace>
GUIs are good, but suck for automation.
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Minutes from AvalonCon #1
Posted by Ulrich Mayring <ul...@denic.de>.
Paul Hammant wrote:
>
> Reason : assembly is too hard for assembler, if they are not taking the
> defaults setup by the relevant build script. Assembly seems to a
> programmers task, rather than an "assemblers" task.
I haven't seen any concept in the real world, which would suggest
creating a seperate role "assembler". What is its purpose?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
s2s(Service2Service)
Posted by avalon nair <vi...@yahoo.com>.
How does one service access the instance
of another Service.?
Vinay.
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org