Bernd Fondermann ha scritto: > On 10/10/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> As an example of phoenix advanced components, phoenix provides a >> Beanshell based kernel that you can access with a console to manage the >> container and the contained applications dynamically. > > Phoenix is a very mature and capable container. Spring cannot > supersede every possible feature of Phoenix or any other technology. > And I am not saying that Spring is equivalent to Phoenix in every > single example you gave. But nevertheless, I'd like to give some > references where everybody interested might start reading...
I reply to the pointers you gave so to make it more clear what I was talking about, but I think we mostly agree on the Phoenix vs Spring issue and the 2 specific issues are not so important now. > for scripting and BeanShell support, see Spring Reference Chapter 24. esp. > 24.3. I don't know every Spring aspect this well, but I think this is different. The Beanshell kernel module for Phoenix gives you an *interactive* shell where you can remotely login and manage apps/components via beanshell. Spring chapter 24 is instead (if I understand it correctly) about writing new components using scripting/dynamic languages. >> Phoenix has an HTTP adaptor on the ServiceManager that allow you to >> access the JMX services via web. > > see Spring Reference Chapters 17.4 and 20. I see JMX export and HTTP support, but I don't see an out of the box solution that gives me a way to point my a simple browser there, see some information, restart some component and so on. I'm sure you can do this integrating MX4J or other tools, but at the moment in phoenix I uncomment few lines in the configuration file, with spring I should start reading 2 chapters... >> Not everything in this list will make me veto a proposal to use spring >> as our main deployment and forget about phoenix, but some of them are >> important, and this was mainly to make it clear that spring is not the >> panacea. > > Alright. My basic idea behind the spring-deployment is /choice/, to > offer our users new ways to integrate James with their own or third > party software. > Pheonix-deployment module will live on as long as someone is maintaining it. > At least I myself will never propose to deprecate it. I will do, once I'll see a complete alternative: supporting multiple deployment is (IMHO) a waste of already limited (human) resources. Thank you, Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
