on 2/1/01 5:42 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> Actually you follow a lot of the patterns of J2EE aswell - you just do it
> differently. Their services directory via JNDI is equivelent to your
> singleton setup, you use log4j/other for logging while they will use that
> godforsaken sucky logging JSR, you use X they use Y ... ;)
To be more accurate, Turbine provides a way to build ANY logging system into
the backend. That is one of the beauties of Turbine...it is very good at
being the container for any number of technologies.
:-)
> In the long run it would be kewl to allow dual access so that J2EE devs
> could use turbine in a similar manner to most other newer web/enterprise
> apps.
Actually, I have a couple great emails from someone at Nokia that uses
Turbine (see below)...obviously we are doing *something* right. :-) Please
note that both of his issues (in Logging and Services) have already been
resolved.
> Of course a lot of the J2EE design decisions suck and you would have
> to live with them if you went that path ;)
No shit. I'm really tired of this constant pressure to use J2EE when
obviously so many things about it just plain suck...primarily JSP.
I had a great conversation today with Jason Hunter about his upcoming second
edition O'Reilly book on Servlets and how he spent a bunch of time doing
non-biased comparisons between different technologies in order to let people
come up with their own opinions on what they think of the different
implementation approaches instead of the constant pressure to simply use
what Sun's tells them to use. Funny, that sounds like a M$ thing to do.
It is amazing to me how anyone would want to use some of these technologies.
His comparison between Struts and Tea and WebMacro was a real eye opener as
to the fact that even though Struts is JSP done right, it still doesn't even
begin to hide the overall warts in JSP. I can't wait till that book is
published so that people can see these differences in plain as day examples.
Needless to say, I think that I'm going to start doing my own comparisons
and placing them up for people to comment. It is time that people wake up
and realize that the way that Sun dictates for people to do things isn't
necessarily the right way to do things.
-jon
> ----------
> From: [EMAIL PROTECTED]
> Reply-To: "Turbine" <[EMAIL PROTECTED]>
> Date: Tue, 23 Jan 2001 15:23:09 +0200
> To: [EMAIL PROTECTED]
> Subject: JMX integration issues
>
> Hi
>
> We have started an attemt to integrate Turbine to our JMX (Java Management
> eXtensions from Sun) based network agent framework. The framework includes
> its own server and doesn't support servlets directly but a somewaht lighter
> concept that we call request processors. It was a straightforward task to
> convert the Turbine servlet into a processor and get the system running.
> However, two static classes caused some problems.
>
> 1) It would be useful if the static Log supported customizable instances
> that could redirect log messages to whatever logging system is used in the
> integrating environment.
>
> 2) TurbineServices implements nicely the ServiceBroker interface and
> provides protected constructors. However, the instance member is private and
> the getInstance method returns a reference to the class instance, not to the
> implemented interface, although the getService method of the interface is
> almost the only one needed outside the class. A possibility to extend and
> customize the TurbineServices instance would make it possible to support
> other service construction methods than Class.forName and additional broker
> mechanisms.
>
> Other components of Turbine, like assembler factories, seemed to be
> extremely well configurable and customizable. The need to modify some of the
> base classes arise from our JMX based object management and broker system
> that we'd like to use for Turbine based objects also. One benefit of a
> separate broker system is a possibility to use different instances of the
> same Turbine module class depending on the context, e.g. pages maintaining
> state of a group of users and supporting several simultaneous groups.
>
> Ilkka
> --
> Ilkka Priha
> Nokia Networks
> http://www.nokia.com/networks
> mail: [EMAIL PROTECTED]
> ----------
> From: [EMAIL PROTECTED]
> Reply-To: "Turbine" <[EMAIL PROTECTED]>
> Date: Wed, 24 Jan 2001 09:39:04 +0200
> To: [EMAIL PROTECTED]
> Subject: RE: JMX integration issues
>
> Rafal, Thanks for your comment. I'm waiting for LogService...
>
> Here is some background information about JMX.
>
> JMX has evolved from a hardware related need to be able to manage thousands
> of different devices using different protocols in a telecommunications
> network. JMX solves the problem with Java so well that the same framework
> can be used for managing software components as well. The idea is to have a
> centralized object registry server, through which clients can ask for
> service objects they need. The registry fully hides the implementation of
> the objects and even their physical location. The registry provides a kind
> of handle, an ObjectName instance, with which to access the properties and
> methods of the implementing object. The handle makes it possible to change
> the implementation during run-time without disturbing any of the clients.
> The objects can be any Java objects either implementing an interface based
> on a certain naming rule or providing a dynamic description object about
> their exposed functionality. So it's easy to convert existing objects to
> managed ones. Sun considers JMX as a pre-implementation of Jini. The idea is
> the same, but JMX supports more clearly centralized management in one
> machine while Jini is a fully decentralized approach managing services
> dynamically around the net.
>
> The JMX framework contains also a web-based management view, based on
> reflection, to the registry and all of the registered objects. This view
> makes it possible to monitor the run-time status of the system, change the
> configuration and even load new objects into the system.
>
> We're using JMX both for its original purpose, for managing devices with
> SNMP, and for managing the components of the device management server
> itself, like connectors, containers, sessions, processors, socket factories,
> thread factories and pools, loggers, Turbine services and modules, etc.
> We've applied many design principles from the Apache Avalon project, but
> used JMX in implementation as it provides most of the required functionality
> readily available. We've added some glue between our system and JMX to be
> able to access registered objects also directly in order to achieve fast
> performance in request processing. The extension listens to registration
> events updating the direct references automatically when needed so that we
> don't lose any of the original dynamics of the framework. Combining JMX with
> IBM's BML (Bean Markup Language) makes configuration and management of
> complicated client/server systems easier than any other approach I know
> about.
>
> http://java.sun.com/products/JavaManagement/index.html
>
> http://www.alphaworks.ibm.com/tech/bml
>
> -- Ilkka
> --
> Nokia Networks
> http://www.nokia.com/networks
> mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
