it isn't if we can have an admin that makes complete sense using our own infrastructure then so much the better,
I really see no problem with that. marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Budworth |Sent: Saturday, December 01, 2001 9:18 PM |To: Dain Sundstrom |Cc: 'David Budworth'; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
