yes and no yes: I strongly support the microkernel view, the basic server is just the JMX stuff (even stripped I think does anyone use the relationships out there?) and the service libraries (possibly unified with MLet). And that doesn't require anything else, certainly not an EJB container (or rather the MBeans that when assembled provide EJB behavior). The small servers, the embedded servers, the edge servers need not ship everything.
no: the configuration server is a central server, he will not run inside my DVD player (while the microkernel will) he will run the central configuration server that David is talking about. Since the MMBeans in the edge servers have pluggable persistence we can use EJB for the persistence in case of clustering, and straight file in case of single server, the EJB in the case buys us location. BTW the persistence is not necessarily in JDBC it would be in file in the first pass, meaning the file persistence that we have in there already just remote under the EJB front. They are different servers and both configuration (at the same time) make total sense to me, the central server is a configuration server (possibly ha'ed itself) the edge ones are what you want, ejb clients if you want (rmi stacks necessary, proxy clients from JBoss, couple of k) or straight microkernel readers if you don't want to and they read their configurations and adminitstration through other means. marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jiri |Luzny |Sent: Wednesday, December 05, 2001 4:54 AM |To: David Budworth |Cc: Dain Sundstrom; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |I have to support Dain's comment. |We see JBoss as a microkernel (container for containers) plus some |services that you can run on top of it. Sure, we also use the J2EE |"services" like EJB etc.., but for some parts of our system, we run |the thin JBoss's microkernel (without any EJB, DB) configuration ONLY. |We just deploy our custom services (MBeans) there. |Why to increase startup time and waste memory for something that is |not going to be used at all? | |Jiri. | | |On Sat, 1 Dec 2001 18:18:02 -0800, you wrote: | |>I hadn't thought of that. I have always viewed JBoss as an overall |>platform with replacable elements. |> |>It hadn't occured to me that you may want to run only one element of it. |> |>I saw it more like the JDK. If you don't want to use JDBC, don't use |>it. But you wouldn't go removing the java.sql.* classes from the jars. |> |>I didn't realize that was a goal of JBoss. |> |> |>-David |> |>On Sat, 01 Dec 2001, Dain Sundstrom wrote: |> |>> You are making 2 bold assumptions. |>> |>> 1. JBoss will always run with the EJB service installed. |>> 2. JBoss will always have a database available. |>> |>> Neither of these hold. As a quick example, I may want JBossMQ |with out a |>> database or EJB services. |>> |>> -dain |>> |>> -----Original Message----- |>> From: David Budworth [mailto:[EMAIL PROTECTED]] |>> Sent: Saturday, December 01, 2001 6:04 PM |>> To: [EMAIL PROTECTED] |>> Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings |>> |>> |>> Marc / everyone, |>> |>> When you asked about this Dynamic mbean thing I'm working on, were you |>> thinking of me applying it to RequiredModelMBean? |>> |>> If I read correctly, we are required to supply an implementation of that |>> class, no? |>> |>> If not, ignore the rest. |>> |>> I'd be happy convert my stuff over to be the implementation of that, |>> since mainly the only difference with what I wrote and this is the |>> persistent storage stuff. |>> |>> I do have a few questions on how it should be done. |>> |>> 1) What are the expectations for determining the MBeanInfo? Should we |>> expect a XYZMBean interface to match the XYZ implementation the user |>> provides? (similar to regular MBeans) |>> |>> This would be easy to add. Since I already have the code that walks the |>> methods of any specified interface to compose the operation/attribute |>> info structures. |>> |>> 2) What should be the rules for determining the operations/attributes? |>> I have written and re-written this logic in my own code about 15 times, |>> never really happy with it. Example, how to handle: |>> |>> int getXYZ(); |>> void setXYZ(float); |>> |>> Do you consider the get to be a RO attribute and one to be an |operation? Or |>> throw an exception for non-compliant naming? I see nothing in the spec |>> regarding naming standards on dynamic mbean oper/attr |>> |>> or |>> |>> int getXYZ(); |>> void setXYZ(int); |>> void setXYZ(float); |>> |>> Do we consider get/set(int) to be a RW attr, and set(float) to be an |>> operation? Or throw again? |>> |>> |>> In my stuff, there is a protected Class[] getInterfaces() so an mbean |>> can specify which interfaces it want's to expose to management. But, if |>> that returns null(default impl), I just use all public methods |not defined |>> in the base |>> or java.lang.Object to be a managed UI. |>> |>> Would you want that in the JBoss RequiredModelMBean? |>> |>> What I have now, basically allows the subclasses to specify any part of |>> the MBeanInfo (ie, via "protected MBeanAttributeInfo[] |>> getAttributeInfo()"), so the subclass can 'break the rules' that are |>> defined in the base class. |>> |>> I wonder, is this too much complexity to offer in a generic base class |>> to be supplied with JBoss? |>> |>> As for persistence, have you finished rolling on the floor laughing at |>> my idea of using EJBs to store? I have noticed that no other components |>> use EJBs for their JDBC based persistence. Is there a reason for this? |>> |>> <soapbox> |>> Assuming Dain's engine has nothing to persist (MBean wise), there is no |>> reason not to use it. If we don't believe in EJBs enough to use them |>> ourselves, how can we tell others to use JBoss for their projects. |>> Hell, configuration persistence is something that happens so rarely (in |>> the application sense), I don't think performance is really an issue. |>> </soapbox> |>> |>> |>> As for clustering stuff, keeping in mind I haven't looked at it yet. |>> Does anyone know if hypersonic get's clustered |>> as well? I see that to get the EJBs mass deployed there is the farm |>> directory, so that kind of implies that there is a master server |>> somewhere (unless everyones farm propogates to everyone else). |>> |>> If hypersonic doesn't cluster, then is there the ability to add to a DD |>> something like: |>> if (master) use local DB |>> else use master DB |>> |>> We store the JMS stuff (and maybe others, I haven't looked) on disk now. |>> With the option of using JDBC. I understand that there is a performance |>> issue, but from the admin point of view, they'd be much happier if |>> everything was all in one place, that was remotely viewable (ie. |>> whatever DefaultDS points to). |>> |>> I've heard Marc mention several times that the winner in this space is |>> going to be the ones with the best ease of management. |>> |>> And I fully agree. Knowing what it took to manage eloan.com's website, |>> and all the problems with what files are where, all the little cron jobs |>> on different machines to make sure the old stuff gets nuked to avoid |>> running out of disk space. |>> |>> I think that a system, with a single point of management (ie: everything |>> in single DB) would have made our lives easier. |>> |>> Keep in mind, my view may be tainted. Our admins pretty much all came |>> from Oracle (or oracle based companies). So to them, having a DB be the |>> front for everything was nirvana. |>> |>> My current project has all my custom config info in the database. So I |>> can easily make changes that all servers can see, as well as perform |>> atomic changes (update 20 config items, then commit, rather than calling |>> setXXX, setYYY and having each change propgate one at a time). |>> |>> But hey, maybe that's just me. |>> |>> Is my view of how things should work just completely misguided? |>> |>> I'll shut up (again) now. |>> |>> -David |>> |>> _______________________________________________ |>> Jboss-development mailing list |>> [EMAIL PROTECTED] |>> https://lists.sourceforge.net/lists/listinfo/jboss-development |> |>_______________________________________________ |>Jboss-development mailing list |>[EMAIL PROTECTED] |>https://lists.sourceforge.net/lists/listinfo/jboss-development | | |_________________________________________________________ |Do You Yahoo!? |Get your free @yahoo.com address at http://mail.yahoo.com | | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
