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