RE: [JBoss-dev] JMX service architecture: next gen++
|I'll rephrase myself. Interceptors could be done as a series of JMX |MBeans implementing DynamicMBean, i.e. they don't do anything with the |call except delegate to other DynamicMBeans, with the last one actually |doing something. This would work, and it would make it simple to |configure each interceptor separately, since they're MBeans. The problem Yes this would indeed be the prefered way to work on the interceptors at run time. |is that for each MBean requiring a specific set of interceptors there |would be a bunch of additional MBeans (i.e. the interceptors |themselves). You would hence get loads and loads of MBeans who play the |interceptor game. Not sure if that's a good idea. However, if you put Not necessarily. Take for example the "transaction" interceptor in JBoss. It is essentially a purely stateless component so that many threads can go through it at once. In clear even just ONE instance of the component (Tx interceptor EJB semantic) is probably enough to take the full load of the server. I don't know enough about compiler technology to know if this is true or not. If it is not I suspect we can MBean a set of them under the same "MBean" if we can use the JINI stuff to cluster them *inside* a node I would be interested in hearing how. You would have a call come in with the MI and whatever the type of bean at the end as long as you want "Tx-EJB-style" and you store a ref to the "context" in the message... you have created a brand new "state machine" in the Turin sense. Each interceptor is a state machine that works on stateless sequence of symbols (the MI coming through) and modify the symbols based on contextual information (tag declaration in tx for example). |the interceptors in the bus you then have two ways of writing |components: as MBeans and as JMX server interceptor plugins. | |Any thoughts on that? I didn't think about that before, but if you are right and we can indeed use the ONE dynamic MBean instead of custom stacks per bean, the we could very well have the mbean be the interceptors. The good news as you have been asking is that we don't need a special treatment for the JMX server. We need it to be UBER FAST which means IBM is out and SUN...well. Care to write one with Juha as "add-on" when you are done with the book ? I am sure people will pay a fair price for the speed. It would be very relevant to put the effort and time in a professional add-on here. No speed? IBM... want speed? we got it! |Good point. Actually, there's no need to use RMI for the talking, only |required for talking to the LUS. What you get from the LUS could be the |connectors to the other servers, which can talk whatever lingo you want. |In this sense you're only using the Jini/LUS as a way for the servers to | find each other. After that you can do whatever you want. ok... sure... |Interesting. And how is this configuration done? Also through JMX? What |you'd want to avoid is two ways of doing the same thing (e.g. JMX + |JMX/infra) in the case of MBeans that would be it. |> The role separation is very easy to do in that invoke flow (like |you did the |> interceptors in JBoss2 rickard) and it is very clear. It's your |stuff in a |> new dimension, don't you see? | | |Loud and clear. good. Saw your emails to Juha, glad you are finally listening to the kid, the book will be great. |> yes we are there :) read the microsoft research papers of 2 |weeks ago.. we |> are flying so fucking high they can't even start to hear us... | | |Read and giggled :-) They are way way behind. yeah but they will reach our point by the time they reach 3.0. Remember, they don't care about time they have got money, we don't so we care about speed. time == money is no insight really |> The other beautiful thing about this is it IS SO CORE that |before a vendor |> can rip off our ideas (hello again) we will know for sure as |there isn't a |> fucking other soul on earth that is using JMX EVEN TODAY as the base like |> you did rickard. They all use it "for management". | | |Good point. it is our radio-active trace. |We're all proffessional thieves, in some sense. :-) It's how good you |are at putting different things together in different dimensions that |makes it interesting or not. :-) | |> man I feel better it has been on my mind for quite some time now. |> Love, to the ones who deserve it. |> |> To the rest... |> |> "we will bury you" |> -- Krutchev? -- | |You're a blan&white kinda guy ;-) Glad I'm on the right side of the fence. Barely. It is important in these days of hunger to keep the message simple. You guys need to be spoon fed as you have been starving for so long. If B$W is clear then we can move on to technicolor (JBoss gets certified! in your dreams!) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|However, if you put |the interceptors in the bus you then have two ways of writing |components: as MBeans and as JMX server interceptor plugins. | |Any thoughts on that? The price you pay for the invocation "on the bus" on the bus isn't significant. Therefore the advantage of the MBean approach to interceptor you propose might just be the ticket from an administration standpoint. We would create the interceptors independently of each other. And then "creating a stack" is nothing more than instructing incoming gates (.net, rmi, whatever) that the messages requesting "EJB-style" fielding should go through this stack of ObjectName interceptors. standardjboss.xml needs to map one on one there. The stack of state machines, the movie seen by the MI, is a random access stack from the point of view of the admin. Then updating the flow means talking to that "route mapper" at the gates. We need a watchdog. Where is stacy when you need her. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: > We would create the interceptors independently of each other. And then > "creating a stack" is nothing more than instructing incoming gates (.net, > rmi, whatever) that the messages requesting "EJB-style" fielding should go > through this stack of ObjectName interceptors. standardjboss.xml needs to > map one on one there. Well, the only thing the incoming gates would have to know is to immediately delegate to the stack configuration MBean. After that it can take care of the stack config. *But this will only work if the interceptor/config interleaving is done as outlined in previous post*. Otherwise it will be an MBean explosion... > The stack of state machines, the movie seen by the MI, is a random access > stack from the point of view of the admin. > > Then updating the flow means talking to that "route mapper" at the gates. Which, as discussed, need to be hand-holding the MI as it travels along the stack. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[Fwd: [JBoss-dev] JMX service architecture: next gen++]
Wrong reply-to.. here it is. --- Begin Message --- marc fleury wrote: > |I'll rephrase myself. Interceptors could be done as a series of JMX > |MBeans implementing DynamicMBean, i.e. they don't do anything with the > |call except delegate to other DynamicMBeans, with the last one actually > |doing something. This would work, and it would make it simple to > |configure each interceptor separately, since they're MBeans. The problem > > Yes this would indeed be the prefered way to work on the interceptors at run > time. Ok, gotcha. > |is that for each MBean requiring a specific set of interceptors there > |would be a bunch of additional MBeans (i.e. the interceptors > |themselves). You would hence get loads and loads of MBeans who play the > |interceptor game. Not sure if that's a good idea. However, if you put > > Not necessarily. Take for example the "transaction" interceptor in JBoss. > It is essentially a purely stateless component so that many threads can go > through it at once. In clear even just ONE instance of the component (Tx > interceptor EJB semantic) is probably enough to take the full load of the > server. I don't know enough about compiler technology to know if this is > true or not. It should be. So then you will instead have n number of "Tx-EJB-style" MBeans for each configuration of it that you want to be able to use. There is a stacking problem here though. If each interceptor is supposed to know which interceptor comes next in the chain, then you will need one instance per *chain configuration*. I.e. if you have two MBeans being served by the same chain, and then want to modify the chain for one of the MBeans, you'll have to duplicate the chain and make the modification. It would be messy. The only way I can see to get around that is to have the interceptor chain interleaved with a configuration interceptor. Example: MBean XYZ wants the interceptor chain A,B,C (where C handles the call). Somehow this config info is given. An interceptor stack management MBean (MGMT) knows this, and for each incoming call the actual runtime chain of invocations looks like this: 1. Connector.invoke (incoming call) 2. MGMT.invoke (MGMT is delegated to, and in turn delegates to first in chain) 3. A.invoke (do the A stuff, delegate back to MGMT) 4. MGMT.invoke (determine that the chain has progressed past A, delegate to B) 5. B.invoke (similar as 3) 6. MGMT.invoke (same as 4) 7. C.invoke (similar as 3, delegate to XYZ through reflection) 8. XYZ.invoke 9. return through interceptors 10. Connector.invoke return result This is the only way you can get away with having a finite amount of interceptor MBean instances. If each interceptor is aware of the next in the chain, as in JBoss2 EJB, then you will have the config explosion problem (i.e. each interceptor will have the state "config+chain knowledge" instead of just "config"). See what I mean? To get this to work the interceptor chain needs the following meta-info in the MI: 1. Final MBean to invoke (XYZ in above case. this identifies the chain to use) 2. Point in chain (0,1,2,3 in above case. this identifies which interceptor in the chain to delegate to next) 3. method 4. arguments 5. custom meta-data(?) This way you can take maximum advantage of the fact that interceptors are largely stateless (and thread-safe), hence reusable for multiple concurrent calls. > Each interceptor is a state machine that works on stateless sequence of > symbols (the MI coming through) and modify the symbols based on contextual > information (tag declaration in tx for example). Yes, true. As in above, the point-in-chain is very important though in order to externalize the actual chain from the interceptors. Agree? > I didn't think about that before, but if you are right and we can indeed use > the ONE dynamic MBean instead of custom stacks per bean, the we could very > well have the mbean be the interceptors. It would require the above to work I think, but it's definitely doable. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] --- End Message ---
AW: [JBoss-dev] JMX service architecture: next gen++
Have you had already a deeper look at the Axis http://xml.apache.org/axis/ architecture? They have handlers (interceptors, e.g., an http-transport, a soap-deserializer, or an ejb-provider), chains (configurations of interceptors) and services (exposed start- and endpoints with names and options). The visitor pattern is used to, e.g., process an incoming "MessageContext" (keeping all the state). Except that they do not use JMX for that purpose ... CGJ -Ursprüngliche Nachricht- >Von: Rickard Öberg [mailto:[EMAIL PROTECTED]] >Gesendet: Dienstag, 2. Oktober 2001 09:57 >An: marc fleury >Betreff: Re: [JBoss-dev] JMX service architecture: next gen++ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/examples/build build.xml
User: gropi Date: 01/10/02 01:54:27 Modified:src/examples/build build.xml Log: Use a more flexible schema to determine the location of servlet.jar Revision ChangesPath 1.15 +34 -24manual/src/examples/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/manual/src/examples/build/build.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- build.xml 2001/09/05 21:58:01 1.14 +++ build.xml 2001/10/02 08:54:27 1.15 @@ -16,42 +16,52 @@ - - + + + + + + + + + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - + - + + - + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/examples/build readme.txt
User: gropi Date: 01/10/02 01:55:18 Modified:src/examples/build readme.txt Log: Update comments to actual situation Revision ChangesPath 1.5 +4 -5 manual/src/examples/build/readme.txt Index: readme.txt === RCS file: /cvsroot/jboss/manual/src/examples/build/readme.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- readme.txt2001/09/30 10:33:48 1.4 +++ readme.txt2001/10/02 08:55:18 1.5 @@ -7,11 +7,10 @@ e.g. c:\JBoss-2.2.2) If you are using a bundled version of JBoss with Jetty or Tomcat then -point JBOSS_DIST to the "jboss" subdir please. Using the bundled -versions will avoid some errors that might show up while the building -process of the examples because of a missing servlet.jar. Instead of -downloading the bundled JBoss versions you can get the servlet.jar -from SUN also. +point JBOSS_DIST to the "jboss" subdir please. +If you want to build any *-war or *-ear target you need to use a bundled +JBoss version or tweak the build.xml file to reflect the correct location +of your servlet.jar file. The Ant bin directory and JDK bin directory must also be in your PATH as described in the First Steps chapter of the JBoss manual. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/examples/org/jboss/docs/interest build.xml
User: gropi Date: 01/10/02 01:57:04 Modified:src/examples/org/jboss/docs/interest build.xml Log: Separate compilation of EJB classes and Servlet class. Thus servlet.jar is only needed if you want to use the servlet. Revision ChangesPath 1.5 +19 -2 manual/src/examples/org/jboss/docs/interest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/manual/src/examples/org/jboss/docs/interest/build.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- build.xml 2001/07/30 18:03:17 1.4 +++ build.xml 2001/10/02 08:57:04 1.5 @@ -16,10 +16,26 @@ optimize="off" > - + + + + + + + + + + + + @@ -38,8 +54,9 @@ + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DriverManager is skipping Drivers - How come?
David, I know that other drivers have been registered because I have checked the following: 1) the server.log file generated by jBoss; and 2) I have made a call to DriverManager.setLogStream() to get a trace on what the DriverManager is doing. From the stream I can see the DriverManager is skipping the other drivers. Cheers, Craig. > Why do you think drivers other than yours should be registered? > david jencks > On 2001.09.27 10:04:17 -0400 Craig Munday wrote: > > All, > > > > I'm using jBoss 2.2.2 with Java 1.3.1 and have a question concerning the > > behavior of the DriverManager. > > > > Essentially I've provided a simple implementation of the java.sql.Driver > > interface. At the moment one of the things it does is try to obtain a > > list > > of other registered drivers by calling DriverManager.getDrivers(). This > > works fine when I try it from Forte however when I use the driver in > > jBoss > > the DriverManager skips all drivers except for my own driver. > > > > Does anyone know why this is happening? I have a feeling it has > > something > > to do with a SecurityManager but I'm not sure how the two are related. > > > > There is a bug that is kind of related but is suppose to have been fixed > > in > > the JDK1.2 final release. > > > > http://developer.java.sun.com/developer/qow/archive/11/index.html > > > > Any help would be greatly appreciated. > > > > Regards, > > Craig.
[JBoss-dev] CVS update: newsite/src/docs/doco_files documentation-example.tar.gz documentation-example.zip
User: gropi Date: 01/10/02 05:32:55 Modified:src/docs/doco_files documentation-example.tar.gz documentation-example.zip Log: Built from the CVS sources on 2001/10/02. Revision ChangesPath 1.3 +172 -187 newsite/src/docs/doco_files/documentation-example.tar.gz <> 1.3 +359 -450 newsite/src/docs/doco_files/documentation-example.zip <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|Well, the only thing the incoming gates would have to know is to |immediately delegate to the stack configuration MBean. After that it can |take care of the stack config. | |*But this will only work if the interceptor/config interleaving is done |as outlined in previous post*. Otherwise it will be an MBean explosion... 4 hours of sleep and I need coffee but no I think that you don't have explosion as we now know that you can use stateless interceptor which enables you to have ONE instance per node as well as "at the beginning" mapping that the MI sees coming in, no need to go through the config interceptor every call. Do you agree? |Which, as discussed, need to be hand-holding the MI as it travels along |the stack. no as it comes in... (imnho) marcf | | |/R | | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of "Mastering RMI" |Email: [EMAIL PROTECTED] | | |___ |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
Re: [Fwd: [JBoss-dev] JMX service architecture: next gen++]
>From: Rickard Öberg <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: [Fwd: [JBoss-dev] JMX service architecture: next gen++] >Date: Tue, 02 Oct 2001 10:07:23 +0200 > >Example: MBean XYZ wants the interceptor chain A,B,C (where C handles the >call). Somehow this config info is given. An interceptor stack management >MBean (MGMT) knows this, and for each incoming call the actual runtime >chain of invocations looks like this: >1. Connector.invoke (incoming call) 2. MGMT.invoke (MGMT is delegated to, >and in turn delegates to first in chain) >3. A.invoke (do the A stuff, delegate back to MGMT) 4. MGMT.invoke >(determine that the chain has progressed past A, delegate to B) 5. B.invoke >(similar as 3) 6. MGMT.invoke (same as 4) 7. C.invoke (similar as 3, >delegate to XYZ through reflection) 8. XYZ.invoke 9. return through >interceptors 10. Connector.invoke return result Since it seems like the configuration would define a static stack of interceptors, MGMT could build a java.util.Stack containing the interceptors and pass that down. Avoiding the delegation back to it. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: > |Well, the only thing the incoming gates would have to know is to > |immediately delegate to the stack configuration MBean. After that it can > |take care of the stack config. > | > |*But this will only work if the interceptor/config interleaving is done > |as outlined in previous post*. Otherwise it will be an MBean explosion... > > 4 hours of sleep and I need coffee but no I think that you don't have > explosion as we now know that you can use stateless interceptor which > enables you to have ONE instance per node as well as "at the beginning" > mapping that the MI sees coming in, no need to go through the config > interceptor every call. > > Do you agree? Let's see if I understand this right. Do you send the list of interceptors as part of the MI? I.e. the list contains the MI and an index, and each interceptor just increases the index and delegates to the next? Or how is the stack controlled? What is the driver of the interceptor delegation? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [Fwd: [JBoss-dev] JMX service architecture: next gen++]
(Seems like the lists need to change the reply-to. it's to the sender and not the list) Hiram Chirino wrote: > Since it seems like the configuration would define a static stack of > interceptors, MGMT could build a java.util.Stack containing the > interceptors and pass that down. Avoiding the delegation back to it. Yes, pass it down along with the MI. That'd work. Didn't figure that one out initially. That would indeed be much better. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
For logging purposes ;) need...early... coffee. marcf |-Original Message- |From: marc fleury [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, October 02, 2001 9:13 AM |To: Rickard Öberg |Subject: RE: [JBoss-dev] JMX service architecture: next gen++ | | ||It should be. So then you will instead have n number of "Tx-EJB-style" ||MBeans for each configuration of it that you want to be able to use. | |not necessarily, I wasn't probably very clear in my previous emails, |a lot of the configuration is in the metadata used by the |interceptor today and that data can be pegged with the MI. | ||There is a stacking problem here though. If each interceptor is supposed ||to know which interceptor comes next in the chain, then you will need | |Who said that it would work like jboss2? reread my email, I talk |about a "stack of object names". | |That stack is essentially a map of the interceptors you are going |to go through as an MI. That stack is not harcoded in the |interceptors but in the gates where the MI is created. What type |of MI are you ? you are going to go through A-B-C-D. What type of |MI are you? you are going to go through C-D-Z. | |Can you hear me? Can you see me? | |Ok for work! | ||one instance per *chain configuration*. I.e. if you have two MBeans ||being served by the same chain, and then want to modify the chain for ||one of the MBeans, you'll have to duplicate the chain and make the ||modification. It would be messy. | |I don't think so. | ||The only way I can see to get around that is to have the interceptor ||chain interleaved with a configuration interceptor. | | || ||Example: ||MBean XYZ wants the interceptor chain A,B,C (where C handles the call). ||Somehow this config info is given. An interceptor stack management MBean ||(MGMT) knows this, and for each incoming call the actual runtime chain ||of invocations looks like this: ||1. Connector.invoke (incoming call) ||2. MGMT.invoke (MGMT is delegated to, and in turn delegates to first in ||chain) ||3. A.invoke (do the A stuff, delegate back to MGMT) ||4. MGMT.invoke (determine that the chain has progressed past A, delegate ||to B) ||5. B.invoke (similar as 3) ||6. MGMT.invoke (same as 4) ||7. C.invoke (similar as 3, delegate to XYZ through reflection) ||8. XYZ.invoke ||9. return through interceptors ||10. Connector.invoke return result | |That is a way, but is this better than giving the map at the |beginning? You save on a ton of calls and you still have the |dynamicity of the configuration (update maps == (LinkedList of |ObjectNames)) | ||This is the only way you can get away with having a finite amount of ||interceptor MBean instances. If each interceptor is aware of the next in ||the chain, as in JBoss2 EJB, then you will have the config explosion ||problem (i.e. each interceptor will have the state "config+chain ||knowledge" instead of just "config"). || ||See what I mean? | |Yes, right analysis on the wrong hypothesis. | ||To get this to work the interceptor chain needs the following meta-info ||in the MI: ||1. Final MBean to invoke (XYZ in above case. this identifies the chain ||to use) | |OBjectName as identifier. Map of "maps to component" where |essentially we store the metainformation we used to use in the |container of jboss2. | ||2. Point in chain (0,1,2,3 in above case. this identifies which ||interceptor in the chain to delegate to next) ||3. method ||4. arguments ||5. custom meta-data(?) | |On 4. I got this idea from "Dresdner Bank" in London with the |project "open adaptor". You might want to check it. I think |their view of the system world is a bit soft but the logic is |there and is kind of relevant. They described random payloads as just |Object[] | |in their case I think they typed the payload as some silly object |DataObject[] or something like that, which I think is superflous. |Again we are doing that but on steroids and with a clearer system |head (they use properties to configure the stacks) but the |"philosophy" is known by the bank guys. | |On 5. custom meta-data might be interesting, at least in the |navigation structures of it, I don't know. | ||This way you can take maximum advantage of the fact that interceptors ||are largely stateless (and thread-safe), hence reusable for multiple ||concurrent calls. | |You got it. | ||Yes, true. As in above, the point-in-chain is very important though in ||order to externalize the actual chain from the interceptors. || ||Agree? | |almost see above, | ||It would require the above to work I think, but it's definitely doable. | |almost there rickard | |marcf | || ||/R || || ||-- ||Rickard Öberg ||Software Development Specialist ||xlurc - Xpedio Linköping Ubiquitous Research Center ||Author of "Mastering RMI" ||Email: [EMAIL PROTECTED] || ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Tuesday, October 02, 2001 9:15 AM |To: Rickard Öberg; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] JMX service architecture: next gen++ | | ||Well, the only thing the incoming gates would have to know is to ||immediately delegate to the stack configuration MBean. After that it can ||take care of the stack config. || ||*But this will only work if the interceptor/config interleaving is done ||as outlined in previous post*. Otherwise it will be an MBean explosion... | |4 hours of sleep and I need coffee but no I think that you don't have |explosion as we now know that you can use stateless interceptor which |enables you to have ONE instance per node as well as "at the beginning" |mapping that the MI sees coming in, no need to go through the config |interceptor every call. | |Do you agree? | ||Which, as discussed, need to be hand-holding the MI as it travels along ||the stack. | |no as it comes in... (imnho) what you describe is how the folks at OpenAdaptor are doing it... let me know what you think of it but when I saw it I went "buark". I mean the functional part I don't know about, but the system implementation was truly primitive (and pompous). One of the interceptors was a "message hospital"... whatever that means. I mean what kind of "stateless" repair can you do in a message. Maybe a replay from a debugger standpoint but I still don't see the need for a centralized point to do that. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|Let's see if I understand this right. Do you send the list of |interceptors as part of the MI? I.e. the list contains the MI and an |index, and each interceptor just increases the index and delegates to |the next? Or how is the stack controlled? What is the driver of the |interceptor delegation? whatever... a stack of ObjectNames and in each "message interceptor mbean" there is a ObjectName name = message.getNextInterceptorInStack(); server.invoke(name, mi) // equivalent dynamic invocation ... whatever there are tons of ways to do that (maybe self contained in MI) but the point is that the stack is assigned when the MI is created (a gate can reconstruct a MI for EJB and set that stack). The "stack maintainer" is clearly an MBean and either the gates (adaptor, but I am curious to see what Andreas calls adaptor here... andreas is an "adaptor" an interceptor? (In the sense of OpenAdaptor then) or is it just a translator into our bus) either the gates know the router or the reverse... I don't know at this point. marcf | |/Rickard | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of "Mastering RMI" |Email: [EMAIL PROTECTED] | | |___ |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
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote:
> a stack of ObjectNames and in each "message interceptor mbean" there is a
>
> ObjectName name = message.getNextInterceptorInStack();
> server.invoke(name, mi) // equivalent dynamic invocation
> ...
>
> whatever there are tons of ways to do that (maybe self contained in MI)
Good point. I had missed the "send stack along in invoke" option. That
is indeed superior. Very lightweight and simple.
The stack could indeed done as:
class InterceptorStack
{
List interceptors;
int idx = 0;
InterceptorStack(List aList)
{
interceptors=aList;
}
ObjectName getNextInterceptor()
{
return (ObjectName)interceptors.get(idx++);
}
}
---
So many MI's would be sharing the same list, but with different indices
into it.
Updating the list would be to simply replace it at the gates. MI's
already in progress using the old version get to finish with that old
version.
Nice.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [davidjencks@directvinternet.com]
Grr, can someone set the reply to back to the list? I sent this originally just to Rickard. I'm reposting because of the comments about mbean config: lots of people suggested the iterator by now. On 2001.10.02 10:09:01 -0400 David Jencks wrote: I'm not sure if this is the same as what you guys are suggesting: The interceptor mbeans don't need to know who they are connected to in the invocation chain. The top of the stack (connector?) does - it has an (ordered) list of the interceptors it uses. A MI coming in gets an iterator on that list from the top of the stack (connector?) When an interceptor is done is asks the iterator in the MI where to go next. A slightly more concrete implementation of this has the list at the top be a linked list, and the "iterator" in the MI be a pointer into this linked list. So... in terms of configuration we have: each interceptor configured separately as mbean Each interceptor stack configured as an mbean with a list of the interceptor mbeans it uses. If we do this with xml configuration, I think we now have 3 kinds of mbean attributes: plain (like we have now) mbean reference/dependency (replaces depends) list (for interceptor stacks at least) david jencks On 2001.10.02 04:00:19 -0400 Rickard Öberg wrote: > marc fleury wrote: > > > We would create the interceptors independently of each other. And then > > "creating a stack" is nothing more than instructing incoming gates > (.net, > > rmi, whatever) that the messages requesting "EJB-style" fielding should > go > > through this stack of ObjectName interceptors. standardjboss.xml needs > to > > map one on one there. > > > Well, the only thing the incoming gates would have to know is to > immediately delegate to the stack configuration MBean. After that it can > take care of the stack config. > > *But this will only work if the interceptor/config interleaving is done > as outlined in previous post*. Otherwise it will be an MBean explosion... > > > > The stack of state machines, the movie seen by the MI, is a random > access > > stack from the point of view of the admin. > > > > Then updating the flow means talking to that "route mapper" at the > gates. > > > Which, as discussed, need to be hand-holding the MI as it travels along > the stack. > > > /R > > > -- > Rickard Öberg > Software Development Specialist > xlurc - Xpedio Linköping Ubiquitous Research Center > Author of "Mastering RMI" > Email: [EMAIL PROTECTED] > > > ___ > 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
RE: [JBoss-dev] JMX service architecture: next gen++
|So many MI's would be sharing the same list, but with different indices |into it. right that is even better the only state that is in the MI is the index and a (static) reference to the type of flow he will see (ejb), pretty cool rickard. |Updating the list would be to simply replace it at the gates. MI's |already in progress using the old version get to finish with that old |version. yes, once you send something in it uses that stack. Do you foresee a problem with this? Like you could have messages going in with a reference to the MBean to come up and then you can't really update the mbean... we will deal with it when we need to. We do have a "centralized" intelligence, the distributed JMX bus (you indirect in JMX at every point) marcf |Nice. | |/Rickard | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of "Mastering RMI" |Email: [EMAIL PROTECTED] | | |___ |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
RE: Re: [JBoss-dev] JMX service architecture: next gen++ [davidjencks@directvinternet.com]
then you are on top of it David? go ahead kid! marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Tuesday, October 02, 2001 11:13 AM |To: jboss-dev |Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ |[[EMAIL PROTECTED]] | | |Grr, can someone set the reply to back to the list? I sent this originally |just to Rickard. I'm reposting because of the comments about mbean config: |lots of people suggested the iterator by now. | | |On 2001.10.02 10:09:01 -0400 David Jencks wrote: |I'm not sure if this is the same as what you guys are suggesting: | |The interceptor mbeans don't need to know who they are connected to in the |invocation chain. | |The top of the stack (connector?) does - it has an (ordered) list of the |interceptors it uses. | |A MI coming in gets an iterator on that list from the top of the stack |(connector?) | |When an interceptor is done is asks the iterator in the MI where to go |next. | |A slightly more concrete implementation of this has the list at the top be |a linked list, and the "iterator" in the MI be a pointer into this linked |list. | | |So... in terms of configuration we have: | |each interceptor configured separately as mbean | |Each interceptor stack configured as an mbean with a list of the |interceptor mbeans it uses. | |If we do this with xml configuration, I think we now have 3 kinds of mbean |attributes: | |plain (like we have now) |mbean reference/dependency (replaces depends) |list (for interceptor stacks at least) | | |david jencks | |On 2001.10.02 04:00:19 -0400 Rickard Öberg wrote: |> marc fleury wrote: |> |> > We would create the interceptors independently of each other. And then |> > "creating a stack" is nothing more than instructing incoming gates |> (.net, |> > rmi, whatever) that the messages requesting "EJB-style" fielding should |> go |> > through this stack of ObjectName interceptors. standardjboss.xml needs |> to |> > map one on one there. |> |> |> Well, the only thing the incoming gates would have to know is to |> immediately delegate to the stack configuration MBean. After that it can |> take care of the stack config. |> |> *But this will only work if the interceptor/config interleaving is done |> as outlined in previous post*. Otherwise it will be an MBean explosion... |> |> |> > The stack of state machines, the movie seen by the MI, is a random |> access |> > stack from the point of view of the admin. |> > |> > Then updating the flow means talking to that "route mapper" at the |> gates. |> |> |> Which, as discussed, need to be hand-holding the MI as it travels along |> the stack. |> |> |> /R |> |> |> -- |> Rickard Öberg |> Software Development Specialist |> xlurc - Xpedio Linköping Ubiquitous Research Center |> Author of "Mastering RMI" |> Email: [EMAIL PROTECTED] |> |> |> ___ |> 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
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: > |So many MI's would be sharing the same list, but with different indices > |into it. > > right that is even better the only state that is in the MI is the index and > a (static) reference to the type of flow he will see (ejb), pretty cool > rickard. It is indeed (and I would not want to get credit for this idea. You already said it, you just didn't know it :-). > |Updating the list would be to simply replace it at the gates. MI's > |already in progress using the old version get to finish with that old > |version. > > yes, once you send something in it uses that stack. Do you foresee a > problem with this? Only if the change of the stack is due to MBeans in it becoming unavailable. Then the MI's that are in progress may try to use MBeans that are no longer running. You get around this by using dependencies. If the stack mgr declares itself as depending on the interceptor MBeans, then it should get STOPPING events before the interceptors have actually stopped, and can then a) wait until any current MI's using that MBean have finished b) hold any incoming MI's wanting to use stacks with that MBean Of course that won't work if the reason for stopping the interceptor is a fatal error (i.e. no way to halt the stop procedure, even temporarily). But then you're screwed anyway. > We do have a "centralized" intelligence, the distributed JMX bus (you > indirect in JMX at every point) Yup. It will be more of an interesting configuration problem, than a programming/design problem. How do you get this to work without getting config files the size of the planet? :-) /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
What if an interceptor in the stack has a call back to a previous
interceptor that was removed as a result of the update? Maintain multiple
version of the stack until all old references complete?
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 02, 2001 3:20 PM
Subject: Re: [JBoss-dev] JMX service architecture: next gen++
> marc fleury wrote:
>
> > a stack of ObjectNames and in each "message interceptor mbean" there is
a
> >
> > ObjectName name = message.getNextInterceptorInStack();
> > server.invoke(name, mi) // equivalent dynamic invocation
> > ...
> >
> > whatever there are tons of ways to do that (maybe self contained in MI)
>
>
> Good point. I had missed the "send stack along in invoke" option. That
> is indeed superior. Very lightweight and simple.
>
> The stack could indeed done as:
> class InterceptorStack
> {
>List interceptors;
>int idx = 0;
>InterceptorStack(List aList)
>{
> interceptors=aList;
>}
>
>ObjectName getNextInterceptor()
>{
> return (ObjectName)interceptors.get(idx++);
>}
> }
> ---
> So many MI's would be sharing the same list, but with different indices
> into it.
>
> Updating the list would be to simply replace it at the gates. MI's
> already in progress using the old version get to finish with that old
> version.
>
> Nice.
>
> /Rickard
>
> --
> Rickard Öberg
> Software Development Specialist
> xlurc - Xpedio Linköping Ubiquitous Research Center
> Author of "Mastering RMI"
> Email: [EMAIL PROTECTED]
>
>
> ___
> 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
Re: [JBoss-dev] JMX service architecture: next gen++
Vinay Menon wrote: > What if an interceptor in the stack has a call back to a previous > interceptor that was removed as a result of the update? Maintain multiple > version of the stack until all old references complete? I think the point is that you never change a stack. Only replace them. So, if an MI has a particular stack it won't change, even if the config changes. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: AW: [JBoss-dev] RH and -classic
Hi Geeks After some tests I figured out that IBM Java 1.3 on Linux causes the problem whereas Sun's Java 1.3.1-01 works fine. Blame the IBM. Andy - Original Message - From: "Andreas Schaefer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 01, 2001 4:07 PM Subject: Re: AW: AW: [JBoss-dev] RH and -classic > Me either but I guess that somehow the Classloader load the classes > on different paths which could lead to something like this. > This stacktrace I got from the call: > > [Default] java.lang.ClassCircularityError: org/mortbay/util/JarFileResource > [Default] at java.lang.ClassLoader.resolveClass0(Native Method) > [Default] at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled > Code)) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|It is indeed (and I would not want to get credit for this idea. You Don't want to take credit for your own ideas? my god, you are ready for the space program kid, the man in black will be coming for you soon. |already said it, you just didn't know it :-). yeah... |You get around this by using dependencies. If the stack mgr declares ok |itself as depending on the interceptor MBeans, then it should get |STOPPING events before the interceptors have actually stopped, and can then |a) wait until any current MI's using that MBean have finished |b) hold any incoming MI's wanting to use stacks with that MBean | |Of course that won't work if the reason for stopping the interceptor is |a fatal error (i.e. no way to halt the stop procedure, even |temporarily). But then you're screwed anyway. | | |> We do have a "centralized" intelligence, the distributed JMX bus (you |> indirect in JMX at every point) | | |Yup. It will be more of an interesting configuration problem, than a |programming/design problem. How do you get this to work without getting |config files the size of the planet? :-) one thing at a time kiddo, one thing at a time. marcf | |/R | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of "Mastering RMI" |Email: [EMAIL PROTECTED] | | |___ |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-dev] US don't fly?
Guys, we got people from eastern europe coming to the training, all the fucking way from Polland and yet we can get fucking silicon valley to fly out to Las Vegas? What's the matter with you people. If you are afraid of flying well you shouldn't. By the way someone from NY just registered and they have a 212 code and they claim "They are alive, and kicking" which is great to hear over the phone. They say we should do a training in NYC... just for the heck of it and patriotism of it all... and you guys won't fucking fly to Vegas? Bill is coming... good for you Bill. Come on man how I am supposed to get you to fly to NY if you won't fly to Vegas? Spreads those wings and strip those feet of lead my friend. -- Bauhaus Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [jboss-business] US don't fly?
|-Original Message- |From: marc fleury [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, October 02, 2001 12:13 PM |To: Jboss-Development@Lists. Sourceforge. Net |Cc: Jboss-Business@Yahoogroups. Com |Subject: [jboss-business] US don't fly? | | |Guys, | |we got people from eastern europe coming to the training, all the fucking |way from Polland and yet we can get fucking silicon valley to fly |out to Las |Vegas? What's the matter with you people. | |If you are afraid of flying well you shouldn't. By the way someone from NY |just registered and they have a 212 code and they claim "They are |alive, and |kicking" which is great to hear over the phone. | |They say we should do a training in NYC... just for the heck of it and |patriotism of it all... and you guys won't fucking fly to Vegas? Bill is |coming... good for you Bill. Come on man how I am supposed to get you to |fly to NY if you won't fly to Vegas? Spreads those wings and strip those |feet of lead my friend. | |-- Bauhaus from "we love our audience" for those who wonder ;-) we really do! we love the stage, so come, come! come already! fly baby fly... it's going to be one hell of a show marcf | | |Marc Fleury |President |JBoss Group, LLC | | | | Yahoo! Groups Sponsor -~--> |Pinpoint the right security solution for your company- Learn how |to add 128- bit encryption and to authenticate your web site with |VeriSign's FREE guide! |http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/W4wwlB/TM |-~-> | |To unsubscribe from this group, send an email to: |[EMAIL PROTECTED] | | | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] US don't fly?
Flights are cheap too. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Tuesday, October 02, 2001 12:13 PM > To: Jboss-Development@Lists. Sourceforge. Net > Cc: Jboss-Business@Yahoogroups. Com > Subject: [JBoss-dev] US don't fly? > > > Guys, > > we got people from eastern europe coming to the training, all the fucking > way from Polland and yet we can get fucking silicon valley to fly > out to Las > Vegas? What's the matter with you people. > > If you are afraid of flying well you shouldn't. By the way > someone from NY > just registered and they have a 212 code and they claim "They are > alive, and > kicking" which is great to hear over the phone. > > They say we should do a training in NYC... just for the heck of it and > patriotism of it all... and you guys won't fucking fly to Vegas? Bill is > coming... good for you Bill. Come on man how I am supposed to get you to > fly to NY if you won't fly to Vegas? Spreads those wings and strip those > feet of lead my friend. > > -- Bauhaus > > > Marc Fleury > President > JBoss Group, LLC > > > > ___ > 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
Re: [JBoss-dev] JMX service architecture: next gen++
On 2001.10.02 11:18:00 -0400 Rickard Öberg wrote: > marc fleury wrote: > > > |So many MI's would be sharing the same list, but with different > indices > > |into it. > > > > right that is even better the only state that is in the MI is the index > and > > a (static) reference to the type of flow he will see (ejb), pretty cool > > rickard. > > > It is indeed (and I would not want to get credit for this idea. You > already said it, you just didn't know it :-). > > > |Updating the list would be to simply replace it at the gates. MI's > > |already in progress using the old version get to finish with that old > > |version. > > > > yes, once you send something in it uses that stack. Do you foresee a > > problem with this? > > > Only if the change of the stack is due to MBeans in it becoming > unavailable. Then the MI's that are in progress may try to use MBeans > that are no longer running. > > You get around this by using dependencies. If the stack mgr declares > itself as depending on the interceptor MBeans, then it should get > STOPPING events before the interceptors have actually stopped, and can > then > a) wait until any current MI's using that MBean have finished > b) hold any incoming MI's wanting to use stacks with that MBean > > Of course that won't work if the reason for stopping the interceptor is > a fatal error (i.e. no way to halt the stop procedure, even > temporarily). But then you're screwed anyway. > I would like this best if the jmx server state were transactional with versioning optimistic concurrency control, like the firebird/interbase db. In this kind of scheme, an invocation to a mbean would get a jmx "transactional" view of all the mbeans in the jmx server as of the start of the invocation. The view of mbeans would be stable until the invocation finishes. Other concurrent changes to mbean state would use "copy on write" semantics and be visible (after they were committed) to jmx transactions started after the commit of the jmx modifications. After all uses of a replaced mbean were complete the (now inacessible) old version of the mbean can be garbage collected. Presumably one could also set up externally controlled jmx transactions so several configuration changes could occur atomically within one transaction. I guess I will have to read more of the mbean spec to see if this is consistent with it ;-) Optimistic/versioning or not, I think some kind of jmx transaction to make configuration invisible until it all completes will be necessary to make on the fly reconfiguration plausible and not too disruptive. > > > We do have a "centralized" intelligence, the distributed JMX bus (you > > indirect in JMX at every point) > > > Yup. It will be more of an interesting configuration problem, than a > programming/design problem. How do you get this to work without getting > config files the size of the planet? :-) How is this much worse than we have now? Now we have standardjboss.xml with a list of interceptors: then we will have this configuration in a "endpoint" mbean as a list of mbean references, and also mbean configuration for each interceptor individually. david jencks > > /R > > -- > Rickard Öberg > Software Development Specialist > xlurc - Xpedio Linköping Ubiquitous Research Center > Author of "Mastering RMI" > Email: [EMAIL PROTECTED] > > > ___ > 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
Re: [JBoss-dev] JMX service architecture: next gen++
David Jencks wrote: > I would like this best if the jmx server state were transactional with > versioning optimistic concurrency control, like the firebird/interbase db. > In this kind of scheme, an invocation to a mbean would get a jmx > "transactional" view of all the mbeans in the jmx server as of the start of > the invocation. The view of mbeans would be stable until the invocation > finishes. Other concurrent changes to mbean state would use "copy on > write" semantics and be visible (after they were committed) to jmx > transactions started after the commit of the jmx modifications. After all > uses of a replaced mbean were complete the (now inacessible) old version of > the mbean can be garbage collected. Presumably one could also set up > externally controlled jmx transactions so several configuration changes > could occur atomically within one transaction. I guess I will have to read > more of the mbean spec to see if this is consistent with it ;-) This is doable, but the overhead of it would be enormous... I think sticking with immutable interceptor stacks is good enough to start with :-) > Optimistic/versioning or not, I think some kind of jmx transaction to make > configuration invisible until it all completes will be necessary to make on > the fly reconfiguration plausible and not too disruptive. Not necessarily. All you need to do is have duplicate MBeans and then switch from one set to the other in one atomic operation. Still, this is really tricky to get right. > How is this much worse than we have now? Now we have standardjboss.xml > with a list of interceptors: then we will have this configuration in a > "endpoint" mbean as a list of mbean references, and also mbean > configuration for each interceptor individually. You may be right. It could be ok. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|I would like this best if the jmx server state were transactional with |versioning optimistic concurrency control, like the firebird/interbase db. |In this kind of scheme, an invocation to a mbean would get a jmx |"transactional" view of all the mbeans in the jmx server as of the start of |the invocation. The view of mbeans would be stable until the invocation |finishes. Other concurrent changes to mbean state would use "copy on |write" semantics and be visible (after they were committed) to jmx |transactions started after the commit of the jmx modifications. After all |uses of a replaced mbean were complete the (now inacessible) old version of |the mbean can be garbage collected. Presumably one could also set up |externally controlled jmx transactions so several configuration changes |could occur atomically within one transaction. I guess I will have to read |more of the mbean spec to see if this is consistent with it ;-) | |Optimistic/versioning or not, I think some kind of jmx transaction to make |configuration invisible until it all completes will be necessary to make on |the fly reconfiguration plausible and not too disruptive. oh no... another one goes pop! kid, what are you talking about? please expand, does someone understand this? marcf | | |> |> > We do have a "centralized" intelligence, the distributed JMX bus (you |> > indirect in JMX at every point) |> |> |> Yup. It will be more of an interesting configuration problem, than a |> programming/design problem. How do you get this to work without getting |> config files the size of the planet? :-) | |How is this much worse than we have now? Now we have standardjboss.xml |with a list of interceptors: then we will have this configuration in a |"endpoint" mbean as a list of mbean references, and also mbean |configuration for each interceptor individually. | |david jencks |> |> /R |> |> -- |> Rickard Öberg |> Software Development Specialist |> xlurc - Xpedio Linköping Ubiquitous Research Center |> Author of "Mastering RMI" |> Email: [EMAIL PROTECTED] |> |> |> ___ |> 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
Re: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
Hi, I think this bug is the reason for the problems we see with the automated tests. Here the test count sometimes gets very low due to the tests timing out. Looking into this is hard, as it seems to change with every run, but one thing seems to be common: The deployer stops working, and the timeouts happen because all attempts at deploying beans hang with a stack trace like: "RMI TCP Connection(3)-127.0.0.1" daemon prio=1 tid=0x82a5a20 nid=0x5876 waiting for monitor entry [0xbc7fe000..0xbc7ff8c4] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:349) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:473) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.jmx.connector.rmi.RMIConnectorImpl.invoke(RMIConnectorImpl.java:400) at [snip] But I think this monitor is held by another thread that appears hung with a stack trace like: "RMI TCP Connection(2)-127.0.0.1" daemon prio=1 tid=0x822fc68 nid=0x5813 waiting for monitor entry [0xbdffe000..0xbdfff8c4] at java.lang.ClassLoader.loadClass(ClassLoader.java:286) at org.jboss.system.URLClassLoader.loadClassLocally(URLClassLoader.java:163) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:292) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) at java.lang.ClassLoader.loadClass(ClassLoader.java:290) at java.lang.ClassLoader.loadClass(ClassLoader.java:290) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.getMethods0(Native Method) at java.lang.Class.getMethods(Class.java:742) at org.jboss.verifier.strategy.EJBVerifier11.verifyEntityHome(EJBVerifier11.java:762) at org.jboss.verifier.strategy.EJBVerifier11.checkEntity(EJBVerifier11.java:121) at org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:135) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:374) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:473) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) at [snip] In this test run, I started the tests a little early: After server startup was finished, but before the autodeployer was done deploying the default rars. Here the autodeployer seems to hang with the following stack trace: "AutoDeployer" prio=1 tid=0x48d8c090 nid=0x5816 waiting for monitor entry [0xbc3fe000..0xbc3ff8c4] at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:278) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:151) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at org.jboss.deployment.DeployerMBeanSupport.recursiveUnpack(DeployerMBeanSupport.java:551) at org.jboss.resource.RARDeployer.deploy(RARDeployer.java:166) at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBeanSupport.java:117) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:633) at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:308) at java.lang.Thread.run(Thread.java:484) But even if I wait until the server is fully operational, I see similar hangs in the test suite. This is complicated by the facts that: - kill -SIGQUIT does not give a monitor dump on my current SUN JDK 1.3.0 VM. - The hangs seem completely random. Sometimes the entire testsuite runs fine, and hangs at the next run if I restart the serv
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
Hey Ole, as I said I have a small tool written with JDI that will tell you who is holding what and who is waiting (so in the "wait for monitor entry" you'll know who is the monitor) If you wanna play, just tell me ;) Simon > -Original Message- > From: Ole Husgaard [mailto:[EMAIL PROTECTED]] > Sent: martedi 2 ottobre 2001 18:49 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] The rabbit has a bug in its pelt: > org.jboss.system.URLClassLoader > > > Hi, > > I think this bug is the reason for the problems > we see with the automated tests. > Here the test count sometimes gets very low due > to the tests timing out. > > Looking into this is hard, as it seems to change > with every run, but one thing seems to be common: > The deployer stops working, and the timeouts > happen because all attempts at deploying beans > hang with a stack trace like: > > "RMI TCP Connection(3)-127.0.0.1" daemon prio=1 tid=0x82a5a20 > nid=0x5876 > waiting for monitor entry [0xbc7fe000..0xbc7ff8c4] > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:349) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > at > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) > at > org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye > r.java:473) > at > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > at > org.jboss.jmx.connector.rmi.RMIConnectorImpl.invoke(RMIConnect > orImpl.java:400) > at [snip] > > But I think this monitor is held by another thread > that appears hung with a stack trace like: > > "RMI TCP Connection(2)-127.0.0.1" daemon prio=1 tid=0x822fc68 > nid=0x5813 > waiting for monitor entry [0xbdffe000..0xbdfff8c4] > at java.lang.ClassLoader.loadClass(ClassLoader.java:286) > at > org.jboss.system.URLClassLoader.loadClassLocally(URLClassLoade > r.java:163) > at > org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:292) > at > org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) > at java.lang.ClassLoader.loadClass(ClassLoader.java:290) > at java.lang.ClassLoader.loadClass(ClassLoader.java:290) > at java.lang.ClassLoader.loadClass(ClassLoader.java:253) > at > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > at java.lang.Class.getMethods0(Native Method) > at java.lang.Class.getMethods(Class.java:742) > at > org.jboss.verifier.strategy.EJBVerifier11.verifyEntityHome(EJB > Verifier11.java:762) > at > org.jboss.verifier.strategy.EJBVerifier11.checkEntity(EJBVerif > ier11.java:121) > at > org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:135) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:374) > at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > at > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) > at > org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye > r.java:473) > at > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) > at [snip] > > In this test run, I started the tests a little early: > After server startup was finished, but before the > autodeployer was done deploying the default rars. > Here the autodeployer seems to hang with the following > stack trace: > > "AutoDeployer" prio=1 tid=0x48d8c090 nid=0x5816 waiting for monitor > entry [0xbc3fe000..0xbc3ff8c4] > at > org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:278) > at > org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) > at > org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:151) > at > java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) > at > org.jboss.deployment.DeployerMBeanSupport.recursiveUnpack(Depl > oyerMBeanSupport.java:551) > at org.jboss.resource.RARDeployer.deploy(RARDeployer.java:166) > at > org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBean > Support.java:117) > at java.lang.reflect.Method.invok
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
we though you were dead, totally assimilated... marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Bordet, Simone |Sent: Tuesday, October 02, 2001 12:53 PM |To: JBoss Development Mailing List (E-mail) |Subject: RE: [JBoss-dev] The rabbit has a bug in its pelt: |org.jboss.system.URLClassLoader | | |Hey Ole, | |as I said I have a small tool written with JDI that will tell you who is |holding what and who is waiting (so in the "wait for monitor entry" you'll |know who is the monitor) |If you wanna play, just tell me ;) | |Simon | |> -Original Message- |> From: Ole Husgaard [mailto:[EMAIL PROTECTED]] |> Sent: martedi 2 ottobre 2001 18:49 |> To: [EMAIL PROTECTED] |> Subject: Re: [JBoss-dev] The rabbit has a bug in its pelt: |> org.jboss.system.URLClassLoader |> |> |> Hi, |> |> I think this bug is the reason for the problems |> we see with the automated tests. |> Here the test count sometimes gets very low due |> to the tests timing out. |> |> Looking into this is hard, as it seems to change |> with every run, but one thing seems to be common: |> The deployer stops working, and the timeouts |> happen because all attempts at deploying beans |> hang with a stack trace like: |> |> "RMI TCP Connection(3)-127.0.0.1" daemon prio=1 tid=0x82a5a20 |> nid=0x5876 |> waiting for monitor entry [0xbc7fe000..0xbc7ff8c4] |> at |> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:349) |> at |> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) |> at java.lang.reflect.Method.invoke(Native Method) |> at |> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. |> java:1628) |> at |> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. |> java:1523) |> at |> org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) |> at |> org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye |> r.java:473) |> at |> org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) |> at java.lang.reflect.Method.invoke(Native Method) |> at |> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. |> java:1628) |> at |> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. |> java:1523) |> at |> org.jboss.jmx.connector.rmi.RMIConnectorImpl.invoke(RMIConnect |> orImpl.java:400) |> at [snip] |> |> But I think this monitor is held by another thread |> that appears hung with a stack trace like: |> |> "RMI TCP Connection(2)-127.0.0.1" daemon prio=1 tid=0x822fc68 |> nid=0x5813 |> waiting for monitor entry [0xbdffe000..0xbdfff8c4] |> at java.lang.ClassLoader.loadClass(ClassLoader.java:286) |> at |> org.jboss.system.URLClassLoader.loadClassLocally(URLClassLoade |> r.java:163) |> at |> org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:292) |> at |> org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) |> at java.lang.ClassLoader.loadClass(ClassLoader.java:290) |> at java.lang.ClassLoader.loadClass(ClassLoader.java:290) |> at java.lang.ClassLoader.loadClass(ClassLoader.java:253) |> at |> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) |> at java.lang.Class.getMethods0(Native Method) |> at java.lang.Class.getMethods(Class.java:742) |> at |> org.jboss.verifier.strategy.EJBVerifier11.verifyEntityHome(EJB |> Verifier11.java:762) |> at |> org.jboss.verifier.strategy.EJBVerifier11.checkEntity(EJBVerif |> ier11.java:121) |> at |> org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:135) |> at |> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445) |> at |> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:374) |> at |> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) |> at java.lang.reflect.Method.invoke(Native Method) |> at |> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. |> java:1628) |> at |> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. |> java:1523) |> at |> org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) |> at |> org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye |> r.java:473) |> at |> org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) |> at [snip] |> |> In this test run, I started the tests a little early: |> After server startup was finished, but before the |> autodeployer was done deploying the default rars. |> Here the autodeployer seems to hang with the following |> stack trace: |> |> "AutoDeployer" prio=1 tid=0x48d8c090 nid=0x5816 waiting for monitor |> entry [0xbc3fe000..0xbc3ff8c4] |> at |> org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:278) |> at |> org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) |>
Re: [Fwd: [JBoss-dev] JMX service architecture: next gen++]
"Rickard Öberg" wrote: > > Hiram Chirino wrote: > > > Since it seems like the configuration would define a static stack of > > interceptors, MGMT could build a java.util.Stack containing the > > interceptors and pass that down. Avoiding the delegation back to it. > > Yes, pass it down along with the MI. That'd work. Didn't figure that one > out initially. That would indeed be much better. I agree, this way we avoid doubling the number of calls in the chain. But creating and using a Stack on every call would also be slow. And it is not needed since the chain instance configuration is basically static, once created. We could delegate the task of getting the next interceptor to the MI by adding a method MI.getNextInterceptor(). The MI constructor could then have an extra argument typed as an array of interceptors. This array is created and initialized once by MGMT at interceptor chain configuration time, and never changed by the MI. The MI could then have an instance field denoting the index of the next interceptor in the chain. This field would be incremented at each call to the MI.getNextInterceptor() method. I guess this approach would also make dynamic interceptor chain reconfiguration easy. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Restore the CVS module names
Look, the legacy branches are not dead (2.2, 2.4) and the modules file is not versioned across branches, so renaming jboss to jboss-all breaks the 2.4 build. Restore the aliases and live with them until 2.4 is as old and crusty as windows 95. A co of jboss needs to simply co the jboss module. This how the build process is documented in the book and I'm not going to change it or the current 2.4 source releases. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
Definitely a much simpler idea to just build the new stack and replace the old one atomically than to try and build a database for the MBeans. Cheers -Original Message- From: Rickard Öberg To: [EMAIL PROTECTED] Sent: 10/2/01 12:33 PM Subject: Re: [JBoss-dev] JMX service architecture: next gen++ David Jencks wrote: > I would like this best if the jmx server state were transactional with > versioning optimistic concurrency control, like the firebird/interbase db. > In this kind of scheme, an invocation to a mbean would get a jmx > "transactional" view of all the mbeans in the jmx server as of the start of > the invocation. The view of mbeans would be stable until the invocation > finishes. Other concurrent changes to mbean state would use "copy on > write" semantics and be visible (after they were committed) to jmx > transactions started after the commit of the jmx modifications. After all > uses of a replaced mbean were complete the (now inacessible) old version of > the mbean can be garbage collected. Presumably one could also set up > externally controlled jmx transactions so several configuration changes > could occur atomically within one transaction. I guess I will have to read > more of the mbean spec to see if this is consistent with it ;-) This is doable, but the overhead of it would be enormous... I think sticking with immutable interceptor stacks is good enough to start with :-) > Optimistic/versioning or not, I think some kind of jmx transaction to make > configuration invisible until it all completes will be necessary to make on > the fly reconfiguration plausible and not too disruptive. Not necessarily. All you need to do is have duplicate MBeans and then switch from one set to the other in one atomic operation. Still, this is really tricky to get right. > How is this much worse than we have now? Now we have standardjboss.xml > with a list of interceptors: then we will have this configuration in a > "endpoint" mbean as a list of mbean references, and also mbean > configuration for each interceptor individually. You may be right. It could be ok. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ 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
Re: [JBoss-dev] JMX service architecture: next gen++
Don't panic marc, even I don't plan to implement this this week ;-) Here's the context I'm thinking about, and please note IANASA (I am not a system administrator)... but if I were running the jboss cluster at Megacorp Conglomerates, I expect my audit trail requirements would include knowing exactly what configuration was used to process each online b2b soap enabled etc purchase order, yet allow on the fly hot updates to avoid even momentary service disruptions. Also, you don't want half-completed configuration changes to start getting used - you want them to finish first. I'm just saying this point of view on requirements (if they are indeed desirable, I don't really know) is satisfied really well by the versioning transaction model of firebird/interbase: transactions get numbered as they come in, so you can tell from the log what order they happened in, and configuration changes are invisible to all transactions (invocations) that start before the configuration change commits, whereas those after the commit use the new configuration. Conceptually this seems cleaner to me than the "valves" you were talking about to stop MIs during reconfiguration. As Rickard says, this might have a lot of overhead, and at least some of the properties of this system will come from careful use of copy on write. On 2001.10.02 12:45:31 -0400 marc fleury wrote: > > |I would like this best if the jmx server state were transactional with > |versioning optimistic concurrency control, like the firebird/interbase > db. > |In this kind of scheme, an invocation to a mbean would get a jmx > |"transactional" view of all the mbeans in the jmx server as of the start > of > |the invocation. The view of mbeans would be stable until the invocation > |finishes. Other concurrent changes to mbean state would use "copy on > |write" semantics and be visible (after they were committed) to jmx > |transactions started after the commit of the jmx modifications. After > all > |uses of a replaced mbean were complete the (now inacessible) old version > of > |the mbean can be garbage collected. Presumably one could also set up > |externally controlled jmx transactions so several configuration changes > |could occur atomically within one transaction. I guess I will have to > read > |more of the mbean spec to see if this is consistent with it ;-) > | > |Optimistic/versioning or not, I think some kind of jmx transaction to > make > |configuration invisible until it all completes will be necessary to make > on > |the fly reconfiguration plausible and not too disruptive. > > oh no... another one goes pop! > > kid, what are you talking about? please expand, does someone understand > this? > > marcf > | > | > |> > |> > We do have a "centralized" intelligence, the distributed JMX bus > (you > |> > indirect in JMX at every point) > |> > |> > |> Yup. It will be more of an interesting configuration problem, than a > |> programming/design problem. How do you get this to work without > getting > |> config files the size of the planet? :-) > | > |How is this much worse than we have now? Now we have standardjboss.xml > |with a list of interceptors: then we will have this configuration in a > |"endpoint" mbean as a list of mbean references, and also mbean > |configuration for each interceptor individually. > | > |david jencks > |> > |> /R > |> > |> -- > |> Rickard Öberg > |> Software Development Specialist > |> xlurc - Xpedio Linköping Ubiquitous Research Center > |> Author of "Mastering RMI" > |> Email: [EMAIL PROTECTED] > |> > |> > |> ___ > |> 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 > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Restore the CVS module names
and he means now Jason... marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, October 02, 2001 1:35 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Restore the CVS module names | | |Look, the legacy branches are not dead (2.2, 2.4) and the modules file is |not versioned across branches, so renaming jboss to jboss-all breaks the |2.4 build. Restore the aliases and live with them until 2.4 is as old and |crusty as windows 95. | |A co of jboss needs to simply co the jboss module. This how the |build process is documented in the book and I'm not going to change |it or the current 2.4 source releases. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | | | |___ |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
RE: [JBoss-dev] JMX service architecture: next gen++
|momentary service disruptions. Also, you don't want half-completed |configuration changes to start getting used - you want them to finish |first. I'm just saying this point of view on requirements (if they are Yes, the transactional nature of the distributed administration operation might be real.. I don't know. |indeed desirable, I don't really know) is satisfied really well by the |versioning transaction model of firebird/interbase: transactions get |numbered as they come in, so you can tell from the log what order they |happened in, and configuration changes are invisible to all transactions |(invocations) that start before the configuration change commits, whereas |those after the commit use the new configuration. Conceptually this seems What is the problem with numbering the result of the operation. I.e. there is a state that exists in the MBeans after the invocation and for making the store() backed by an EJB we will buy you the transactional XA registration of the database connection that stores that configuration. Building an history in the database based on the state is disconnected from the incoming invocations. Are you saying the incoming invocations should be recorded? Do you know how big this will get? will you always get the tools to replay this scenario? I would rather work with state in MBean and possibly both if we want to be rich (store the invocation with the modification ... p) clearly heavy and applicable to management operations only. |cleaner to me than the "valves" you were talking about to stop MIs during |reconfiguration. Only it doesn't really apply to the same stuff or does it? One is storing the state of the MBean in the database (it's configuration) with many other MBean nodes so you update your machine at once but what does it have to do with stopping the threads coming in? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
"Jung , Dr. Christoph" wrote: > > I must correct myself! We have a principle problem, unfortunately, for which > I do not > have an immediate answer right now: > > Actually, instead of synchronized(classLoaders) in ServiceLibraries, there > would be the need > to *atomically* synchronize on all instances of the set in order not to > interfere with the ClassLoader.loadClassInternally() calls. > > But this is not possible with the Java synchronization mechanism, AFAIK. Please forgive me if I am wrong - I'm not very familiar with this code. But isn't the only reason for synchronizing on classLoaders that there would be problems if another thread tries to add or remove classloaders while the Set is traversed? If this is the case, couldn't we avoid synchronizing on it by making ServiceLibraries.addClassLoader() and removeClassloader() create an entire new Set? Of course, then these methods would have to be synchronized, and we would probably also have to synchronize on the instance variables classes, resources, clToClassSetMap and clToResourceSetMap, but these locks would not be held while ClassLoader.loadClassInternally() is called. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/web/servlets UserTransactionServlet.java
User: sparre
Date: 01/10/02 11:55:07
Modified:src/main/org/jboss/test/web/servlets
UserTransactionServlet.java
Log:
Look up the UT under JNDI name "java:comp/UserTransaction", as the
standard tells us to.
Revision ChangesPath
1.2 +2 -2
jbosstest/src/main/org/jboss/test/web/servlets/UserTransactionServlet.java
Index: UserTransactionServlet.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/servlets/UserTransactionServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UserTransactionServlet.java 2001/09/25 18:07:13 1.1
+++ UserTransactionServlet.java 2001/10/02 18:55:07 1.2
@@ -28,7 +28,7 @@
* Adapted from Scott Starks EJBServlet.java.
*
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class UserTransactionServlet extends HttpServlet
{
@@ -46,7 +46,7 @@
// Get the UserTransaction
UserTransaction ut;
try {
-ut = (UserTransaction)ctx.lookup("UserTransaction");
+ut = (UserTransaction)ctx.lookup("java:comp/UserTransaction");
} catch (NamingException ex) {
throw new ServletException("Unable to lookup UserTransaction", ex);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: newsite/src/docs/doco_filesdocumentation-example.tar.gz documentation-example.zip
How does this get generated? --jason On Tue, 2 Oct 2001, Tobias Frech wrote: > User: gropi > Date: 01/10/02 05:32:55 > > Modified:src/docs/doco_files documentation-example.tar.gz > documentation-example.zip > Log: > Built from the CVS sources on 2001/10/02. > > Revision ChangesPath > 1.3 +172 -187 newsite/src/docs/doco_files/documentation-example.tar.gz > > <> > > > 1.3 +359 -450 newsite/src/docs/doco_files/documentation-example.zip > > <> > > > > ___ > 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
Re: AW: [JBoss-dev] CVS update: jboss/src/main/org/jboss/tm/usertx/client ServerVMClientUserTransaction.java ClientUserTransaction.java ClientUserTransactionObjectFactory.java
Harald Gliebe wrote: > > Hi, > > > Ole Husgaard wrote: > > > > Hi, > > > > I'm in a little over my head here, since i don't > > use web components or know that part of the JBoss > > code well. > > > > > > > > 2) "A transaction that is started by a servlet or JSP page > > must be completed > > > before the service method returns. That is, transactions > > may not span web > > > requests from a client. Returning from the service method > > with an active > > > transaction context is an error. The web container is > > required to detect > > > this > > > error and abort the transaction." > > > > > > This has probably to be done specific for Jetty/Tomcat. Do > > they also have > > > some kind of interceptor-architecture that permits us to > > add this kind of > > > checks? > > > If I understand the tm code correctly, it would fail if the > > transaction is > > > accessed from two requests that are handled in different > > threads, so in my > > > opinion it would be a good idea to have this check added. > > > > No, the TM handles different threads associated with the same > > tx fine, and the UT I wrote is simply a thin interface to > > the TM. So from the TM and UT point of view this should be no > > problem. > > Yes, I don't doubt that! I'm talking about http requests above. > If the web container handles one http request and the Servlet > begins a UserTransaction, then this transaction will be > associated to the thread. If the transaction isn't commited or > rolled back by the servlet, it is still associated to the thread. > If this thread is reused by the web container to serve the next > request (probably from a different client) this request will > be executed in the existing transaction context (what is wrong). > Thus, the requirement of the spec is that the web container > ensures that a transaction is completed at the end of each > http-request, by rolling back any non-completed transaction. > > This should be similar to what happens in the finally-part of > TxInterceptorBMT.invoke for stateless session beans. Ok. I do not know if the web containers do this, but if - they do not - they use thread pooling - a web component does not end a transaction you should get a javax.transaction.NotSupportedException at some time when a transaction is started, since the TM does not support nested transactions, and the transaction would stay active and still be associated with the reused thread. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: AW: [JBoss-dev] CVS update: jboss/src/main/org/jboss/tm/usertx/client ServerVMClientUserTransaction.java ClientUserTransaction.java ClientUserTransactionObjectFactory.java
rong). |> Thus, the requirement of the spec is that the web container |> ensures that a transaction is completed at the end of each |> http-request, by rolling back any non-completed transaction. how is this supposed to make web services transactional? you should have the option to define "statefull sessions" in http see and have the transactional boundaries live beyond the invocation of http. 25c marcf |> |> This should be similar to what happens in the finally-part of |> TxInterceptorBMT.invoke for stateless session beans. | |Ok. I do not know if the web containers do this, but if |- they do not |- they use thread pooling |- a web component does not end a transaction |you should get a javax.transaction.NotSupportedException at some |time when a transaction is started, since the TM does not support |nested transactions, and the transaction would stay active and |still be associated with the reused thread. | | |Best Regards, | |Ole Husgaard. | |___ |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
AW: AW: [JBoss-dev] CVS update: jboss/src/main/org/jboss/tm/usertx/client ServerVMClientUserTransaction.java ClientUserTransaction.java ClientUserTransactionObjectFactory.java
marc fleury wrote: > > rong). > |> Thus, the requirement of the spec is that the web container > |> ensures that a transaction is completed at the end of each > |> http-request, by rolling back any non-completed transaction. > > how is this supposed to make web services transactional? > you should have the option to define "statefull sessions" in > http see and > have the transactional boundaries live beyond the invocation of http. > 25c > marcf True. And it could be done quite easily by disassociating the transaction from the thread at the end of an HTTP request, storing the transaction id in the HttpSession and restoring the association when a new request for this session comes in. But then you would get long-running transactions (at least when the http requests comes from a human user) where database connections are hold open and objects are locked, leading to scalability problems. For web services the transactions might be necessary. Harald ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Website Issue.
Hello guys, Did anyone notice that the navigation menu on the left hand side of the JBoss.org site does not work when the user is in the survey module? The links are all incorrect since the context seems to have changed to 'survey' and all links are relative to the context. Regards Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] Reply-To: lines missing.
I have and this happened last month as well. However, I can't find the Reply-To setting any longer in the list administration form on sourceforge. A bug exists for this issue in the sourceforge project: http://sourceforge.net/tracker/index.php?func=detail&aid=467046&group_id=1&a tid=21 Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Ole Husgaard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, October 02, 2001 1:56 PM Subject: [JBoss-user] Reply-To: lines missing. > Hi, > > It seems that the usual "Reply-To: " line > is suddenly missing for mail sent on these lists. > > So just hitting the reply button means that the > reply goes to the sender instead of the list. > > Just to warn you, in case you haven't noticed. > > > Best Regards, > > Ole Husgaard. > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT modules
User: user57 Date: 01/10/02 14:09:45 Modified:.modules Log: o I completly spaced the 2.4.x build system cvs namespace requirements... these names need to be here for it to work. My appologies for those affected by the previous changes. Revision ChangesPath 1.63 +16 -1 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.62 retrieving revision 1.63 diff -u -r1.62 -r1.63 --- modules 2001/10/02 01:01:20 1.62 +++ modules 2001/10/02 21:09:45 1.63 @@ -173,6 +173,21 @@ ## Aliases ## -jboss-a jboss-all docs -a jboss-docs website -a jboss-website + + +# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # + +## +## Required for JBoss 2.4.x build system. +## + +jboss-d jbossjboss +jnp -d jnp jnp +jbosssx -d jbosssx jbosssx +jbossmq -d jbossmq jbossmq +jbosscx -d jbosscx jbosscx +jbosspool-d jbosspooljbosspool +jboss-j2ee -d jboss-j2ee jboss-j2ee +contrib -d contrib contrib ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Website Issue.
This should be fixed once I commit my changes to jboss-website/survey. --jason On Tue, 2 Oct 2001, Vinay Menon wrote: > Hello guys, > Did anyone notice that the navigation menu on the left hand > side of the JBoss.org site does not work when the user is in the survey > module? The links are all incorrect since the context seems to have changed > to 'survey' and all links are relative to the context. > > Regards > > Vinay > > > ___ > 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-dev] CVS update: website-survey/src/metadata - New directory
User: user57 Date: 01/10/02 14:31:23 website-survey/src/metadata - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org - New directory
User: user57 Date: 01/10/02 14:32:41 website-survey/src/main/org - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/web/survey - New directory
User: user57 Date: 01/10/02 14:32:08 website-survey/src/web/survey - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss - New directory
User: user57 Date: 01/10/02 14:32:43 website-survey/src/main/org/jboss - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey - New directory
User: user57 Date: 01/10/02 14:32:46 website-survey/src/main/org/jboss/survey - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/database - New directory
User: user57 Date: 01/10/02 14:31:23 website-survey/src/database - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/web - New directory
User: user57 Date: 01/10/02 14:31:23 website-survey/src/web - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/database/schema - New directory
User: user57 Date: 01/10/02 14:31:29 website-survey/src/database/schema - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main - New directory
User: user57 Date: 01/10/02 14:31:23 website-survey/src/main - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/web/survey-helper - New directory
User: user57 Date: 01/10/02 14:32:08 website-survey/src/web/survey-helper - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/ejb - New directory
User: user57 Date: 01/10/02 14:33:00 website-survey/src/main/org/jboss/survey/ejb - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/exception - New directory
User: user57 Date: 01/10/02 14:33:01 website-survey/src/main/org/jboss/survey/exception - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/util - New directory
User: user57 Date: 01/10/02 14:33:01 website-survey/src/main/org/jboss/survey/util - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/command - New directory
User: user57 Date: 01/10/02 14:33:00 website-survey/src/main/org/jboss/survey/command - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src - New directory
User: user57 Date: 01/10/02 14:31:16 website-survey/src - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/ejb/session - New directory
User: user57 Date: 01/10/02 14:33:37 website-survey/src/main/org/jboss/survey/ejb/session - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/database/schema/posgresql Survey.sql User.sql
User: user57 Date: 01/10/02 14:34:56 Added: src/database/schema/posgresql Survey.sql User.sql Log: o moved jboss-website/website/survey to jboss-website/survey (it's own module) Revision ChangesPath 1.1 website-survey/src/database/schema/posgresql/Survey.sql Index: Survey.sql === -- If the table and/or sequence already exists back them up and delete them -- Create empty Survey table CREATE TABLE Survey ( Id INT4 NOT NULL, User_IdINT4 NOT NULL, Permission INT2 NOT NULL, Jboss_Version VARCHAR( 50 ), Jboss_Download_TypeVARCHAR( 50 ) NOT NULL, Jboss_UsageVARCHAR( 2000 ), Jboss_Website VARCHAR( 50 ), Jboss_First_Time INT2 NOT NULL, Jboss_Other_Server INT4 NOT NULL, Jboss_Other_Server_NameVARCHAR( 50 ), Jboss_Reason VARCHAR( 2000 ), Environment_Equipement VARCHAR( 100 )NOT NULL, Environment_OS VARCHAR( 25 ) NOT NULL, Environment_Processors INT4 NOT NULL, Environment_Requests INT4, Environment_Database VARCHAR( 50 ), Environment_Data_Size INT4, Environment_Stateless_EJBs INT4 NOT NULL, Environment_Stateful_EJBs INT4 NOT NULL, Environment_Entity_EJBsINT4 NOT NULL, Environment_Message_EJBs INT4 NOT NULL, Jboss_Features VARCHAR( 50 ), Own_Interceptors INT2 NOT NULL, Own_Container_Invokers INT2 NOT NULL, Own_MBeans INT2 NOT NULL, Own_Comments VARCHAR( 2000 ), Creation_Date DATETIME NOT NULL, Modification_Date DATETIME NOT NULL ); CREATE SEQUENCE Survey_Seq; 1.1 website-survey/src/database/schema/posgresql/User.sql Index: User.sql === -- If the table and/or sequence already exists back them up and delete them -- Create empty User table (which must be named differently because it -- conflict with the keyword Users CREATE TABLE User_Info ( Id INT4 NOT NULL, First_Name VARCHAR( 50 ) NOT NULL, Last_Name VARCHAR( 50 ) NOT NULL, PasswordVARCHAR( 50 ) NOT NULL, Company VARCHAR( 50 ) NOT NULL, Job_Description VARCHAR( 100 )NOT NULL, Email VARCHAR( 100 )NOT NULL, SubscriptionINT2 NOT NULL, Industry_Type INT4 NOT NULL, Other_Industry_Type VARCHAR( 50 ) NOT NULL, Nr_Of_Employees INT4 NOT NULL, Support INT4 NOT NULL, Creation_Date DATETIME NOT NULL, Modification_Date DATETIME NOT NULL ); CREATE SEQUENCE User_Info_Seq; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/command SurveyHandler.java
User: user57
Date: 01/10/02 14:34:56
Added: src/main/org/jboss/survey/command SurveyHandler.java
Log:
o moved jboss-website/website/survey to jboss-website/survey (it's own
module)
Revision ChangesPath
1.1
website-survey/src/main/org/jboss/survey/command/SurveyHandler.java
Index: SurveyHandler.java
===
//
// File: SurveyHandler.java
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
// Version: $Revision: 1.1 $
// Last Checked In: $Date: 2001/10/02 21:34:56 $
// Last Checked In By: $Author: user57 $
//
package org.jboss.survey.command;
import org.jboss.survey.ejb.entity.SurveyData;
import org.jboss.survey.ejb.entity.UserData;
import org.jboss.survey.exception.ServiceUnavailableException;
import org.jboss.survey.exception.InvalidValueException;
import org.jboss.survey.ejb.session.SurveyManagement;
import org.jboss.survey.ejb.session.SurveyManagementHome;
import java.util.Collection;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
/**
* Is the glue between the client/JSP and the business rules managing
* EJBs. It also delivers the rights Value Objects on requests.
*
* @author Andreas Schaefer ([EMAIL PROTECTED])
* @version $Revision: 1.1 $
**/
public class SurveyHandler {
// -
// Static
// -
// -
// Members
// -
// -
// Constructor
// -
/**
* Default (no-args) constructor
**/
public SurveyHandler() {
}
// -
// Methods
// -
/**
* Returns the requested Survey
*
* @param pSurveyId Id of the requested Survey
*
* @return Survey Value Object
*
* @throws InvalidValueException If the requested Survey could not be found
* @throws ServiceUnavailable If the service is unaccessible or unusable
**/
public SurveyData getSurvey( int pSurveyId )
throws
InvalidValueException,
ServiceUnavailableException
{
try {
SurveyManagement aBean = getSurveyManagementBean();
return aBean.getSurvey( pSurveyId );
}
catch ( RemoteException pRE ) {
throw new ServiceUnavailableException(
"Remote communication error: " + pRE.getMessage()
);
}
}
/**
* Returns the all the available Surveys
*
* @return Survey Value Object List
*
* @throws ServiceUnavailable If the service is unaccessible or unusable
**/
public Collection getSurveys()
throws
ServiceUnavailableException
{
try {
SurveyManagement aBean = getSurveyManagementBean();
return aBean.getSurveys();
}
catch ( RemoteException pRE ) {
throw new ServiceUnavailableException(
"Remote communication error: " + pRE.getMessage()
);
}
}
/**
* Saves the given Survey (either create or edit the existing one)
*
* @param pSurvey Survey Value Object containing the Survey Information
*
* @return Updated Survey Data
*
* @throws InvalidValueException If the given Survey content is invalid
* @throws ServiceUnavailable If the service is unaccessible or unusable
**/
public SurveyData saveSurvey( SurveyData pSurvey )
throws
InvalidValueException,
ServiceUnavailableException
{
try {
SurveyManagement aBean = getSurveyManagementBean();
return aBean.saveSurvey( pSurvey );
}
catch ( RemoteException pRE ) {
throw new ServiceUnavailableException(
"Remote communication error: " + pRE.getMessage()
);
}
}
/**
* Removes the given Survey
*
* @param pSurveyId Survey ID of the Survey to be delete
*
* @throws Inval
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/ejb/session SequenceGeneratorBean.java SurveyManagementBean.java
User: user57
Date: 01/10/02 14:34:56
Added: src/main/org/jboss/survey/ejb/session
SequenceGeneratorBean.java
SurveyManagementBean.java
Log:
o moved jboss-website/website/survey to jboss-website/survey (it's own
module)
Revision ChangesPath
1.1
website-survey/src/main/org/jboss/survey/ejb/session/SequenceGeneratorBean.java
Index: SequenceGeneratorBean.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.survey.ejb.session;
import java.rmi.RemoteException;
import java.sql.Connection;
import java.sql.Statement;
import java.sql.ResultSet;
import java.sql.SQLException;
import javax.ejb.CreateException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;
import org.jboss.survey.ejb.Debug;
import org.jboss.survey.exception.ServiceUnavailableException;
/**
* Encapsulates the retrival of DB data
*
* @author Andreas Schaefer
* @version $Revision: 1.1 $
*
* @ejb:bean name="jboss/survey/SequenceGenerator"
* display-name="Generates unique Identifier for an Entity"
* type="Stateless"
* jndi-name="ejb/jboss/survey/SequenceGenerator"
* @ejb:env-entry name="DataSource_Name"
*value="SurveyDS"
* @ejb:resource_ref res-name="jdbc/SurveyDS"
*/
public class SequenceGeneratorBean
implements SessionBean
{
// -
// Static
// -
// -
// Members
// -
private SessionContext mContext;
// Only for test purposes
private int mNextNumber = 0;
// -
// Methods
// -
/**
* Delivers the next sequence number from the given Sequence Name
*
* @param pSequenceName Name of the Sequence Generator
*
* @return Next sequence number
*
* @throws RemoteException
*
* @ejb:interface-method view-type="remote"
**/
public int getNextNumber( String pSequenceName )
throws
ServiceUnavailableException,
RemoteException
{
Connection aConnection = null;
Statement aStatement = null;
try
{
// Get the Home Interface
Context aJNDIContext = new InitialContext();
String lDataSourceName = (String) aJNDIContext.lookup(
"java:comp/env/DataSource_Name"
);
// Get the Datasource
DataSource aSource = (DataSource) aJNDIContext.lookup( "java:/" +
lDataSourceName );
// Get JDBC Connection, create statement and get the result to return
aConnection = aSource.getConnection();
aStatement = aConnection.createStatement();
String aSql = "SELECT Nextval( '" + pSequenceName + "' ) ";
if( Debug.LEVEL >= Debug.REGULAR ) System.err.println( "Sql Statement: " +
aSql );
ResultSet aResult = aStatement.executeQuery( aSql );
if( aResult.next() )
{
return aResult.getInt( 1 );
}
else
{
return -1;
}
/* AS Hypersonic Way
// Get the Home Interface
Context aJNDIContext = new InitialContext();
// Get the Datasource
DataSource aSource = (DataSource) aJNDIContext.lookup( "java:/DefaultDS" );
// Get JDBC Connection, create statement and get the result to return
aConnection = aSource.getConnection();
aStatement = aConnection.createStatement();
//AS This is only working for a demo because two threads could get the same
//AS Sequence Number because of multi threading
String aSql = "SELECT MAX( id ) FROM " + pSequenceName;
if( Debug.LEVEL >= Debug.REGULAR ) System.err.println( "Sql Statement: " +
aSql );
ResultSet aResult = aStatement.executeQuery( aSql );
int lResult = -1;
if( aResult.next() ) {
lResult = aResult.getInt( 1 );
if( Debug.LEVEL >= Debug.REGULAR ) System.out.println( "Found maximum ID
ffrom Survey: " + lResult );
if( lResult <= 0 ) {
lResult =
[JBoss-dev] CVS update: website-survey build.xml
User: user57 Date: 01/10/02 14:34:56 Modified:.build.xml Log: o moved jboss-website/website/survey to jboss-website/survey (it's own module) Revision ChangesPath 1.2 +294 -13 website-survey/build.xml Index: build.xml === RCS file: /cvsroot/jboss/website-survey/build.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.xml 2001/10/01 20:55:33 1.1 +++ build.xml 2001/10/02 21:34:55 1.2 @@ -10,7 +10,7 @@ - + @@ -159,36 +159,69 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - - - - + + - - - - - + + + + @@ -227,6 +260,18 @@ + + + + + + + + + + + + @@ -243,7 +288,81 @@ --> + depends="init, + compile-bean-sources, + compile-classes, + compile-metadata, + compile-database"/> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -255,6 +374,123 @@ --> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -268,8 +504,53 @@ | This target should depend on other docs-* targets for each | different type of docuementation that is to be generated. --> + + + + + + + + + + + + + + + + + + + + + + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/exception InvalidValueException.java ServiceUnavailableException.java
User: user57
Date: 01/10/02 14:34:57
Added: src/main/org/jboss/survey/exception
InvalidValueException.java
ServiceUnavailableException.java
Log:
o moved jboss-website/website/survey to jboss-website/survey (it's own
module)
Revision ChangesPath
1.1
website-survey/src/main/org/jboss/survey/exception/InvalidValueException.java
Index: InvalidValueException.java
===
//
// File: InvalidValueException
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
// Version: $Revision: 1.1 $
// Last Checked In: $Date: 2001/10/02 21:34:56 $
// Last Checked In By: $Author: user57 $
//
package org.jboss.survey.exception;
import java.util.Collection;
/**
* An instance of this class is thrown when a Value Object
* contains an invalid value. It parameters can then be used
* with {@link java.text.MessageFormat MessageFormat} to get
* right message. The message this exceptions contains is not
* the text but the key to get the right text from it.
*
* @author Andreas Schaefer
* @version $Revision: 1.1 $
**/
public class InvalidValueException
extends Exception
{
// -
// Static
// -
// -
// Members
// -
private Object[] mParameters = new Object[ 0 ];
// -
// Constructor
// -
/**
* Constructor with a message handler and a list of parameters
*
* @param pMessageHandler Handler to lookup the right message
* @param pParameters One Parameter, array of parameters or a Collection
*of parameters or null
**/
public InvalidValueException( String pMessageHandler, Object pParameters )
{
super( pMessageHandler );
if( pParameters != null )
{
if( pParameters instanceof Collection )
{
mParameters = ( (Collection) pParameters ).toArray( new Object[ 0 ] );
}
else
{
if( pParameters instanceof Object[] )
{
mParameters = (Object[]) pParameters;
}
else
{
mParameters = new Object[] { pParameters };
}
}
}
}
// -
// Methods
// -
/**
* Returns the array of parameters coming along
*
* @return Array of parameters which are always defined but can be empty
**/
public Object[] getParameters()
{
return mParameters;
}
/**
* Describes the instance and its content for debugging purpose
*
* @return Using the one from the super class
**/
public String toString()
{
return super.toString();
}
/**
* Determines if the given instance is the same as this instance
* based on its content. This means that it has to be of the same
* class ( or subclass ) and it has to have the same content
*
* @return Returns the equals value from the super class
**/
public boolean equals( Object pTest )
{
return super.equals( pTest );
}
/**
* Returns the hashcode of this instance
*
* @return Hashcode of the super class
**/
public int hashCode()
{
return super.hashCode();
}
}
//
// EOF
1.1
website-survey/src/main/org/jboss/survey/exception/ServiceUnavailableException.java
Index: ServiceUnavailableException.java
===
//
// File: ServiceUnavailableException
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
// Version: $Revision: 1.1 $
// Last Checked In: $Date: 2001/10/02 21:34:56 $
// Last Checked In By: $Author: user57 $
//
package org.jboss.su
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/ejb Debug.java EJBUtils.java
User: user57
Date: 01/10/02 14:34:56
Added: src/main/org/jboss/survey/ejb Debug.java EJBUtils.java
Log:
o moved jboss-website/website/survey to jboss-website/survey (it's own
module)
Revision ChangesPath
1.1 website-survey/src/main/org/jboss/survey/ejb/Debug.java
Index: Debug.java
===
//
// File: Debug.java
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
// Version: $Revision: 1.1 $
// Last Checked In: $Date: 2001/10/02 21:34:56 $
// Last Checked In By: $Author: user57 $
//
package org.jboss.survey.ejb;
/**
* Debug Constants for the Sony ADOS EJBs
*
* @author Andreas Schaefer
* @version $Revision: 1.1 $
**/
public class Debug
{
// -
// Static
// -
public static final int NONE = 0;
public static final int CRITICAL = 1;
public static final int REGULAR = 2;
public static final int VERBOSE = 3;
public static final int LEVEL = REGULAR;
public static final int DEVELOPMENT = 0;
public static final int PRODUCTION = 1;
public static final int STAGE = DEVELOPMENT;
// -
// Members
// -
// -
// Constructor
// -
// -
// Methods
// -
}
//
// EOF
1.1 website-survey/src/main/org/jboss/survey/ejb/EJBUtils.java
Index: EJBUtils.java
===
//
// File: EJBUtils.java
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
// Version: $Revision: 1.1 $
// Last Checked In: $Date: 2001/10/02 21:34:56 $
// Last Checked In By: $Author: user57 $
//
package org.jboss.survey.ejb;
import java.io.InputStream;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Date;
import java.util.Iterator;
import java.util.Properties;
/**
* Utils for the Sony ADOS EJBs
*
* @author Andreas Schaefer
* @version $Revision: 1.1 $
**/
public class EJBUtils
{
// -
// Static
// -
private static Properties mMessageProperties;
static
{
mMessageProperties = getProperties( "message.properties" );
}
/**
* If defined it loads the given properties file and then returns
* the given properties instance
*
* @param pFileName File Name of the Properties file. If null then no file will
* be loaded.
*
* @return Properties instance
**/
public static Properties getProperties( String pFileName )
{
Properties aReturn = System.getProperties();
try
{
if( pFileName != null && !pFileName.equals( "" ) )
{
InputStream aPropertyStream =
EJBUtils.class.getClassLoader().getResourceAsStream(
"conf/" + pFileName
);
if( aPropertyStream != null )
{
aReturn.load( aPropertyStream );
}
}
}
catch( IOException ioe )
{
ioe.printStackTrace( System.err );
}
return aReturn;
}
public static String getMessage( String pMessageHandler, Object pParameters )
{
String aMessage = mMessageProperties.getProperty( pMessageHandler );
if( aMessage == null || aMessage.equals( "" ) )
{
return pMessageHandler;
}
// Check the given parameters and convert them to a collection if neccessary
Collection aParameters = null;
if( pParameters != null )
{
if( pParameters instanceof Collection )
{
aPara
[JBoss-dev] CVS update: website-survey/src/database/schema/posgresql - New directory
User: user57 Date: 01/10/02 14:31:31 website-survey/src/database/schema/posgresql - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/ejb/entity - New directory
User: user57 Date: 01/10/02 14:33:40 website-survey/src/main/org/jboss/survey/ejb/entity - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/metadata survey-application.xml survey-helper-application.xml survey-helper-web.xml survey-web.xml
User: user57 Date: 01/10/02 14:34:57 Added: src/metadata survey-application.xml survey-helper-application.xml survey-helper-web.xml survey-web.xml Log: o moved jboss-website/website/survey to jboss-website/survey (it's own module) Revision ChangesPath 1.1 website-survey/src/metadata/survey-application.xml Index: survey-application.xml === JBoss Survey survey.jar survey.war /survey 1.1 website-survey/src/metadata/survey-helper-application.xml Index: survey-helper-application.xml === JBoss Survey Helper survey-helper.war /survey/help 1.1 website-survey/src/metadata/survey-helper-web.xml Index: survey-helper-web.xml === JBoss Survey Helper 1.1 website-survey/src/metadata/survey-web.xml Index: survey-web.xml === JBoss Survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: CVSROOT modules
Thanks for the quick turn-around Jason, please pay close attention to what Scott has to say. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Tuesday, October 02, 2001 5:10 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] CVS update: CVSROOT modules | | | User: user57 | Date: 01/10/02 14:09:45 | | Modified:.modules | Log: | o I completly spaced the 2.4.x build system cvs namespace |requirements... | these names need to be here for it to work. My appologies for those | affected by the previous changes. | | Revision ChangesPath | 1.63 +16 -1 CVSROOT/modules | | Index: modules | === | RCS file: /cvsroot/jboss/CVSROOT/modules,v | retrieving revision 1.62 | retrieving revision 1.63 | diff -u -r1.62 -r1.63 | --- modules 2001/10/02 01:01:20 1.62 | +++ modules 2001/10/02 21:09:45 1.63 | @@ -173,6 +173,21 @@ | ## Aliases | ## | | -jboss -a jboss-all | docs-a jboss-docs | website -a jboss-website | + | + | +# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # |# # # # # # # # | + | +## | +## Required for JBoss 2.4.x build system. | +## | + | +jboss -d jbossjboss | +jnp -d jnp jnp | +jbosssx -d jbosssx jbosssx | +jbossmq -d jbossmq jbossmq | +jbosscx -d jbosscx jbosscx | +jbosspool -d jbosspooljbosspool | +jboss-j2ee -d jboss-j2ee jboss-j2ee | +contrib -d contrib contrib | | | | |___ |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-dev] CVS update: website-survey/src/main/org/jboss/survey/util Debug.java Helper.java SurveyPresentation.java UserPresentation.java
User: user57
Date: 01/10/02 14:34:57
Added: src/main/org/jboss/survey/util Debug.java Helper.java
SurveyPresentation.java UserPresentation.java
Log:
o moved jboss-website/website/survey to jboss-website/survey (it's own
module)
Revision ChangesPath
1.1 website-survey/src/main/org/jboss/survey/util/Debug.java
Index: Debug.java
===
//
// File: Debug.java
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
// Version: $Revision: 1.1 $
// Last Checked In: $Date: 2001/10/02 21:34:57 $
// Last Checked In By: $Author: user57 $
//
package org.jboss.survey.util;
import java.io.Serializable;
/**
* Debug Constants for the Sony ADOS
*
* @author Andreas Schaefer
* @version $Revision: 1.1 $
**/
public class Debug
{
// -
// Static
// -
public static final int NONE = 0;
public static final int CRITICAL = 1;
public static final int REGULAR = 2;
public static final int VERBOSE = 3;
public static final int LEVEL = CRITICAL;
// -
// Members
// -
// -
// Constructor
// -
// -
// Methods
// -
}
//
// EOF
1.1 website-survey/src/main/org/jboss/survey/util/Helper.java
Index: Helper.java
===
//
// File: Helper.java
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
// Version: $Revision: 1.1 $
// Last Checked In: $Date: 2001/10/02 21:34:57 $
// Last Checked In By: $Author: user57 $
package org.jboss.survey.util;
// import com.madplanet.web.util.Debug;
import java.net.URLEncoder;
import java.text.SimpleDateFormat;
import java.text.ParseException;
import java.util.Date;
import java.util.StringTokenizer;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
/**
* Contains some static helper methods
*
* @author Andreas Schaefer
* @version $Revision: 1.1 $
**/
public class Helper
{
// -
// Static
// -
public static SimpleDateFormat sDateFormatter = new SimpleDateFormat(
"MM/dd/" );
public static int BOGUS_NUMBER = -2;
// -
// Members
// -
// -
// Constructor
// -
/**
* Default (no-args) constructor
**/
public Helper()
{
}
// -
// Methods
// -
/**
* Looks up and returns the argument from the given request
*
* @param pRequest HTTP Request Object
* @param pName Name of the Parameter to look up
* @param pDefault Default value to be returned if not found or if the found
* parameter is not a valid integer
**/
public static int getIntParameter(
HttpServletRequest pRequest,
String pName,
int pDefault
) {
try
{
String aValue = pRequest.getParameter( pName );
if( aValue != null )
{
return new Integer( aValue ).intValue();
}
}
catch( Exception e )
{
}
return pDefault;
}
public static String getStringParameter(
HttpServletRequest pRequest,
String pName,
String pDefault
) {
try
{
String
[JBoss-dev] CVS update: website-forums/src/lib jive.jar
User: user57 Date: 01/10/02 14:55:11 Modified:src/lib jive.jar Log: o updating to jive 2.1.0 beta 1 Revision ChangesPath 1.2 +4723 -4843website-forums/src/lib/jive.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] problem with 2.4.1/jetty & jboss-website
Scott, AFAIK (and in this area it's not much): ENC=Enterprise Naming Context. This is implemented via JNDI. Jetty does not contain any JNDI related code - since this stuff only becomes relevant within e.g. JBoss. Thus it is all left to the integration code. The integration code does not contain any JNDI stuff. This is all left to my superclass - AbstractWebContainer. JBoss-2.4.0/Jetty-3.1.RC8 works. JBoss-2.4.1/Jetty-3.1.RC9 and JBoss-2.4.1/Jetty-3.1.1 display the problem. I have built JBoss-2.4.0/Jetty-3.1.RC9 and 3.1.1 distributions which both DO NOT display the problem. I have built a 2.4.2 release which does.display the problem. On the subject of the ClassLoader used for the webapp by Jetty. I have run some tests and this is ALWAYS the actual ClassLoader passed to it by the or a descendent of this. So as far as I understand (unless I am mistaken about what the ENC is): 1. Jetty does not and has never created the war ENC, but expects AbstractWebContainer to do so. 2. Some change seems to have occurred between 2.4.0 and 2.4.1 which has possibly exacerbated a shortfall in the Jetty integration. 3. The stacktrace shows that AbstratWebContainer is trying to bind a resource that has already been bound - possibly by it. I would really like to put this to bed sso and get a 2.4.2 release out. Any help that you can give me on this would be much appreciated, Why particularly do you implicate ClassLoaders? Would class name spaces have any relevance to JNDI namespaces ? could you explain. Jules Scott M Stark wrote: > I tried deploying the website.ear to JBoss-2.4.1a/Tomcat-3.2.3 and this > works. There must be an issue with Jetty not creating the war ENC with > the war class loader established as the thread context class loader. Show > the full stack trace of the exception. > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, September 27, 2001 6:20 PM > Subject: [JBoss-dev] problem with 2.4.1/jetty & jboss-website > > > I am getting this exception when deploying jboss-website to a freshcopy of > > jboss-2.4.1 with jetty/3.1.1: > > > > > > javax.naming.NameAlreadyBoundException; remaining name 'env' > > at > > org.jnp.server.NamingServer.createSubcontext(NamingServer.java:451) > > at > > org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:648) > > at > > org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:634) > > at > > > org.jboss.web.AbstractWebContainer.parseWebAppDescriptors(AbstractWebContain > er.java:292) > > at > > > org.jboss.web.AbstractWebContainer$DescriptorParser.parseWebAppDescriptors(A > bstractWebContainer.java:406) > > at org.jboss.jetty.SetupHandler.start(SetupHandler.java:63) > > at org.mortbay.http.HandlerContext.start(HandlerContext.java:1152) > > at > > > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. > java:338) > > > > > > It looks like the manual.ear deploys fine (which just has manual.war > > inside), but webside.ear failes (which has jbossgroup.war, website.war & > > snapshots.war). > > > > I am going to try and muck with the config somemore, but if anyone has any > > clues... > > > > --jason > > > > > > ___ > > 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-dev] CVS update: website-forums/src/etc jive_init.properties
User: user57 Date: 01/10/02 15:30:44 Removed: src/etc jive_init.properties Log: o using web.xml to set jiveHome ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [davidjencks@directvinternet.com]
(Maybe this time I will get this to the list-third try is the charm?) On 2001.10.02 15:07:05 -0400 David Jencks wrote: (forwarding to list, hope this is ok with you) This is exactly what I was thinking, and what the firebird-style versioning does for you. I am not suggesting storing much of anything in a persistent db, I haven't thought about that yet: what I am talking about is how to make the configuration changes transactional/atomic and allow "pre-completion" invocations complete with the old versions, whereas "post completion" invocations use the new versions. I think this is not that hard to do with firebird as a model, maybe adding the version id into the mbean object name. Needs some more thought. Some of this can be taken care of by copy on write invocation lists, but I'm not sure all of it can. Thanks david jencks On 2001.10.02 14:45:05 -0400 Ole Husgaard wrote: > Hi, > > I've been speculating about this in the context of bean > redeployment. > > Just creating a new configuration (or deployment) and atomically > switching over to it is not really enough: Old transactions that > have used the old configuration (or deployment) should continue > to use that, so the old configuration (or deployment) has to be > kept until all transactions that have ever used it have terminated. > > But to avoid service disruption, calls in the context of new > transactions that have not used the old configuration should be > using the new configuration at the same time as some old > transactions still use the old configuration. > > I agree that this can become very hairy. > > > Best Regards, > > Ole Husgaard. > > > David Jencks wrote: > > > > Don't panic marc, even I don't plan to implement this this week ;-) > > > > Here's the context I'm thinking about, and please note IANASA (I am not > a > > system administrator)... but if I were running the jboss cluster at > > Megacorp Conglomerates, I expect my audit trail requirements would > include > > knowing exactly what configuration was used to process each online b2b > soap > > enabled etc purchase order, yet allow on the fly hot updates to avoid > even > > momentary service disruptions. Also, you don't want half-completed > > configuration changes to start getting used - you want them to finish > > first. I'm just saying this point of view on requirements (if they are > > indeed desirable, I don't really know) is satisfied really well by the > > versioning transaction model of firebird/interbase: transactions get > > numbered as they come in, so you can tell from the log what order they > > happened in, and configuration changes are invisible to all > transactions > > (invocations) that start before the configuration change commits, > whereas > > those after the commit use the new configuration. Conceptually this > seems > > cleaner to me than the "valves" you were talking about to stop MIs > during > > reconfiguration. > > > > As Rickard says, this might have a lot of overhead, and at least some > of > > the properties of this system will come from careful use of copy on > write. > > [snip] > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-forums build.xml
User: user57
Date: 01/10/02 15:30:44
Modified:.build.xml
Log:
o using web.xml to set jiveHome
Revision ChangesPath
1.3 +9 -21 website-forums/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/website-forums/build.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.xml 2001/10/01 23:06:01 1.2
+++ build.xml 2001/10/02 22:30:44 1.3
@@ -10,7 +10,7 @@
-
+
@@ -133,7 +133,7 @@
-
+
@@ -174,12 +174,10 @@
-
-
@@ -238,26 +236,15 @@
-
-
+
+
Using jivesoftware.jive.home: ${jivesoftware.jive.home}
-
-
-
-
-
-
-
-
-
-
@@ -270,6 +257,9 @@
+
+
+
@@ -289,9 +279,6 @@
-
-
-
@@ -508,13 +495,14 @@
| servers to help setup testing environemnts. Users will also have
| to setup the database as specified in the Jive docs.
-->
-
+
+
Copied over basic Jive configuration files.
You will need finish the setup from the admin/setup page.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-forums/src/metadata jive-web.xml
User: user57 Date: 01/10/02 15:30:44 Modified:src/metadata jive-web.xml Log: o using web.xml to set jiveHome Revision ChangesPath 1.2 +14 -1 website-forums/src/metadata/jive-web.xml Index: jive-web.xml === RCS file: /cvsroot/jboss/website-forums/src/metadata/jive-web.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jive-web.xml 2001/10/01 23:06:01 1.1 +++ jive-web.xml 2001/10/02 22:30:44 1.2 @@ -1,7 +1,20 @@ - + + JBoss Jive Forums WebApp + + + jiveHome + @jivesoftware.jive.home@ + + + + JiveServlet + com.jivesoftware.forum.util.JiveServlet + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/database/schema/posgresql Survey.sql User.sql
User: user57 Date: 01/10/02 15:33:02 Removed: survey/database/schema/posgresql Survey.sql User.sql Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/metadata survey-application.xml survey-web.xml survey.help-application.xml survey.help-web.xml
User: user57 Date: 01/10/02 15:33:02 Removed: survey/metadata survey-application.xml survey-web.xml survey.help-application.xml survey.help-web.xml Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/src/client/org/jboss/survey/command SurveyHandler.java
User: user57 Date: 01/10/02 15:33:02 Removed: survey/src/client/org/jboss/survey/command SurveyHandler.java Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/src/client/org/jboss/survey/util Debug.java Helper.java SurveyPresentation.java UserPresentation.java
User: user57 Date: 01/10/02 15:33:02 Removed: survey/src/client/org/jboss/survey/util Debug.java Helper.java SurveyPresentation.java UserPresentation.java Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/src/ejb/org/jboss/survey/ejb/session SequenceGeneratorBean.java SurveyManagementBean.java
User: user57 Date: 01/10/02 15:33:04 Removed: survey/src/ejb/org/jboss/survey/ejb/session SequenceGeneratorBean.java SurveyManagementBean.java Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/src/ejb/org/jboss/survey/exception InvalidValueException.java ServiceUnavailableException.java
User: user57 Date: 01/10/02 15:33:04 Removed: survey/src/ejb/org/jboss/survey/exception InvalidValueException.java ServiceUnavailableException.java Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite build.xml
User: user57 Date: 01/10/02 15:33:02 Modified:.build.xml Log: o jboss-website/website/survey has been moved to jboss-website/survey Revision ChangesPath 1.18 +4 -197newsite/build.xml Index: build.xml === RCS file: /cvsroot/jboss/newsite/build.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- build.xml 2001/10/02 00:15:38 1.17 +++ build.xml 2001/10/02 22:33:02 1.18 @@ -10,9 +10,9 @@ - + - + @@ -152,13 +152,6 @@ - - - - - - - @@ -168,7 +161,6 @@ - @@ -188,14 +180,6 @@ - - - - - - - - @@ -210,28 +194,16 @@ - - - - - - - - - - - - @@ -248,15 +220,6 @@ - - - - - - - - - @@ -273,17 +236,6 @@ - - - - - - - - - - @@ -324,11 +276,6 @@ - - - - - @@ -435,82 +382,15 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -819,7 +626,7 @@ - https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey build.xml
User: user57 Date: 01/10/02 15:33:44 Modified:.build.xml Log: o fixed module.* properties Revision ChangesPath 1.3 +3 -3 website-survey/build.xml Index: build.xml === RCS file: /cvsroot/jboss/website-survey/build.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- build.xml 2001/10/02 21:34:55 1.2 +++ build.xml 2001/10/02 22:33:43 1.3 @@ -10,7 +10,7 @@ - + @@ -131,9 +131,9 @@ - + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/web.survey.help Client.List.View.jsp Client.Selection.View.jsp Email.Input.View.jsp Emailer.Controller.jsp Helper.js List.Controller.jsp List.Selection.View.jsp List.View.jsp Page.jsp Statistics.Controller.jsp Statistics.View.jsp Validation.js index.jsp
User: user57 Date: 01/10/02 15:33:04 Removed: survey/web.survey.help Client.List.View.jsp Client.Selection.View.jsp Email.Input.View.jsp Emailer.Controller.jsp Helper.js List.Controller.jsp List.Selection.View.jsp List.View.jsp Page.jsp Statistics.Controller.jsp Statistics.View.jsp Validation.js index.jsp Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/lib jboss-j2ee.jar
User: user57 Date: 01/10/02 15:33:02 Removed: survey/lib jboss-j2ee.jar Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/web.survey AssetTest.jsp ConfirmationPage.jsp ConfirmationPageHelp.jsp Environment1Page.jsp Environment1PageHelp.jsp Environment2Page.jsp Environment2PageHelp.jsp GoodbyePage.jsp HelpController.jsp JBossPage.jsp JBossPageHelp.jsp PersonalPage.jsp PersonalPageHelp.jsp Survey.jsp SurveyController.jsp Validation.js WelcomePage.jsp WelcomePageHelp.jsp index.jsp
User: user57 Date: 01/10/02 15:33:04 Removed: survey/web.survey AssetTest.jsp ConfirmationPage.jsp ConfirmationPageHelp.jsp Environment1Page.jsp Environment1PageHelp.jsp Environment2Page.jsp Environment2PageHelp.jsp GoodbyePage.jsp HelpController.jsp JBossPage.jsp JBossPageHelp.jsp PersonalPage.jsp PersonalPageHelp.jsp Survey.jsp SurveyController.jsp Validation.js WelcomePage.jsp WelcomePageHelp.jsp index.jsp Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/src/ejb/org/jboss/survey/ejb Debug.java EJBUtils.java
User: user57 Date: 01/10/02 15:33:03 Removed: survey/src/ejb/org/jboss/survey/ejb Debug.java EJBUtils.java Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/website build.xml
User: user57 Date: 01/10/02 15:34:27 Modified:website build.xml Log: o updated module config to include the forums and survey Revision ChangesPath 1.12 +10 -4 build/website/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/website/build.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- build.xml 2001/10/02 00:15:38 1.11 +++ build.xml 2001/10/02 22:34:27 1.12 @@ -10,7 +10,7 @@ - + @@ -177,14 +177,21 @@ + + + + + + + - + @@ -398,14 +405,13 @@ - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/survey/src/ejb/org/jboss/survey/ejb/entity AbstractData.java SurveyBean.java UserBean.java
User: user57 Date: 01/10/02 15:33:04 Removed: survey/src/ejb/org/jboss/survey/ejb/entity AbstractData.java SurveyBean.java UserBean.java Log: o jboss-website/website/survey has been moved to jboss-website/survey ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT modules
User: user57 Date: 01/10/02 15:39:49 Modified:.modules Log: o jboss-website now depends on jboss/j2ee which needs some extra thirdparty libs to compile. Revision ChangesPath 1.64 +3 -1 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.63 retrieving revision 1.64 diff -u -r1.63 -r1.64 --- modules 2001/10/02 21:09:45 1.63 +++ modules 2001/10/02 22:39:49 1.64 @@ -101,7 +101,9 @@ &jboss-website-modules jboss-website-thirdparty -a \ - thirdparty/oasis + thirdparty/oasis \ + thirdparty/sun/jaas \ + thirdparty/junit/junit jboss-website-modules-a \ _jboss_website_build \ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/bin update-website.sh
User: user57 Date: 01/10/02 15:40:08 Modified:src/bin update-website.sh Log: o don't be so loud when checking out stuff from CVS Revision ChangesPath 1.8 +3 -3 newsite/src/bin/update-website.sh Index: update-website.sh === RCS file: /cvsroot/jboss/newsite/src/bin/update-website.sh,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- update-website.sh 2001/09/28 03:21:12 1.7 +++ update-website.sh 2001/10/02 22:40:08 1.8 @@ -6,7 +6,7 @@ ## ## ### == ### -# $Id: update-website.sh,v 1.7 2001/09/28 03:21:12 user57 Exp $ +# $Id: update-website.sh,v 1.8 2001/10/02 22:40:08 user57 Exp $ ## ## Returns exit status 0 for success, 1 for errors and 2 for fatal errors. @@ -92,8 +92,8 @@ if [ "x$LOCALCVS" = "x" ]; then # pull down a fresh copy of jboss-website - info "Pulling down a fresh copy of jboss-website" - $CVS $CVS_OPTIONS get -AP jboss-website + info "Pulling down a fresh copy of jboss-website..." + $CVS -Q -r -f -z3 $CVS_OPTIONS get -AP jboss-website status=$? checkStatus $status 0 "cvs checkout failed" else ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
