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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
