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]
