Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: the ejb behavior is implemented in the actual linked list of interceptors that we put there, exactly what we do today from the ContainerFactory but completely and **genericaly** at the JMX layer. Building the EJB will be nothing more than passing standardjboss.xml topology of stacks. Gotcha. |It should be doable as MBeans, i.e. no real need to change the bus. The |interceptor stack map fairly well to JMX Adaptors. I am surprised Andreas is not on your case yet, the JMX adaptors in his eyes have a very different meaning. You seem to suppose that adaptors=interceptors (as in invoke() stacks). Andreas explains in the book that adaptors are really just an adaptor from the semantic of the calls coming from the connectors to the semantics of the JMX bus. Different things. That would be one way of looking at it. In that sense they map fairly well to the Bridge design pattern, i.e. converting between two worlds of perspectives. 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 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 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? |There are a couple of important points to lessen the crazy aspect: |1) There will not be nxn connections where n is number of services. The |*worst* case will be sxs connections where s is the *number of servers*. |RMI connections can be shared by MBeans in the same server. right, and even in the rabbit hole picture that is not limited to RMI (I am not saying you are saying this ;-). 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. But I suspect that for many first iteration it will nxs at least with the current implementation of the proxies. If we do smart stuff (like I outlined to bill and you privately) then we can actually reuse the connection. It is the power of the detyped invocation and we don't know what is behind or need to. True. |But you do have a point in that it might be the case that configuring |the stacks can be done *more efficiently* if done inside the server. |Maybe, maybe not. It's more clear cut than that. Take the debugging for example. Say that we want to trace particular flows in the system. What we would do is start sending radioactive messages with a trace flag IN THE MESSAGE. And the one that stamps the messages like that can be some code flag in the connector sure but that would be inferior since we can't update that part so easily (well you can in rabbit hole due to the dynamic hot deploy of server parts but that is beyond the point). The point is that we can put ANY NEW FANCY tracer in there dynamically that would add any complex type to the payload of the MI going in so we can do fancy tracing. Then we can remove the interceptor ENTIRELY, not even fuck with flag settings in JMX and what not. It is a whole new level of JMX infrastructure as plugin management and dynamic scripting of flows... all due to the JMX bus presence with a fully detyped invocation. 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) To me these are squarely system issues that are better dealt at the system level. +1. 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. |That's important for the five nines, indeed. Or six or seven or how |many nines you want. ahw wtf, nine nines.. that'd be something :-) 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. u 2 days to get the message through... glad its a Roger, you won't get many communications 8-) 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
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java
User: slaboure
Date: 01/10/02 00:17:07
Modified:src/main/org/jboss/ha/framework/server HAPartitionImpl.java
Log:
Optimization: we save three methods calls for each method invocation.
We could further improve this (one call) by using the same scheme in HARMIServerImpl.
Revision ChangesPath
1.3 +11 -1
jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java
Index: HAPartitionImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HAPartitionImpl.java 2001/10/02 04:06:47 1.2
+++ HAPartitionImpl.java 2001/10/02 07:17:07 1.3
@@ -69,6 +69,8 @@
protected Logger log = null;
+ protected long currentViewId = -1;
+
final MethodLookup method_lookup_clos=new MethodLookupClos ();
public HAPartitionImpl (String partitionName, JChannel channel, boolean
deadlock_detection) throws Exception
@@ -153,6 +155,10 @@
this.members = view.GetMembers ();
log.info (Num cluster members: + members.size ());
+ // Update the initial view id
+ //
+ this.currentViewId = view.GetVid().GetId();
+
// We must now syncrhonize new state transfer subscriber
//
boolean rc = channel.GetState (null, 8000);
@@ -201,7 +207,7 @@
public long getCurrentViewId()
{
- return channel.GetView().GetVid().GetId();
+ return this.currentViewId;
}
// ***
@@ -370,6 +376,10 @@
{
try
{
+ // we update the view id
+ //
+ this.currentViewId = newView.GetVid().GetId();
+
if (this.members == null)
{
// Initial viewAccepted
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
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 blanwhite 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. ---BeginMessage--- 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 @@
property environment=env /
!-- Override with your JBoss server dist location if the JBOSS_DIST env var is
not set --
property name=jboss.dist value=${env.JBOSS_DIST}/
-!-- Override with your web server servlet jar location. The default assumes
that
- JBOSS_DIST points to a JBoss/Tomcat bundle distribution
- --
-property name=servlet.jar
value=${env.JBOSS_DIST}}/../tomcat/lib/servlet.jar/
+
property name=src.dir value=${basedir}/
property name=src.resources value=${basedir}/resources/
property name=build.dir value=${basedir}/build-examples/
property name=dist.dir value=${basedir}/../../dist-examples/
+
+target name=validate-servlet
+!-- Override with your web server servlet jar location.
+ The default assumes that JBOSS_DIST points to a
+ JBoss/Tomcat bundle distribution
+ --
+available property=servlet.jar
value=${env.JBOSS_DIST}/../tomcat/lib/servlet.jar
file=${env.JBOSS_DIST}/../tomcat/lib/servlet.jar/
+available property=servlet.jar
value=${env.JBOSS_DIST}/../jetty/lib/javax.servlet.jar
file=${env.JBOSS_DIST}/../jetty/lib/javax.servlet.jar/
+available property=servlet.jar
value=${env.JBOSS_DIST}/../catalina/common/lib/servlet.jar
file=${env.JBOSS_DIST}/../catalina/common/lib/servlet.jar/
+available property=servlet.jar
value=${env.JBOSS_DIST}/../catalina/common/lib/servlet.jar
file=${env.TOMCAT_HOME}/lib/servlet.jar/
+property name=servlet.jar value=COULD_NOT_FIND_SERVLET_JAR/
-path id=base.path_22
-pathelement location=${jboss.dist}/client/ejb.jar/
-pathelement location=${jboss.dist}/client/jaas.jar/
-pathelement location=${jboss.dist}/client/jbosssx-client.jar/
-pathelement location=${jboss.dist}/client/jboss-client.jar/
-pathelement location=${jboss.dist}/client/jnp-client.jar/
-pathelement location=${servlet.jar}/
-/path
-path id=base.path_23
-pathelement location=${jboss.dist}/client/jboss-j2ee.jar/
-pathelement location=${jboss.dist}/client/jaas.jar/
-pathelement location=${jboss.dist}/client/jbosssx-client.jar/
-pathelement location=${jboss.dist}/client/jboss-client.jar/
-pathelement location=${jboss.dist}/client/jnp-client.jar/
-pathelement location=${servlet.jar}/
-/path
+path id=base.path_22
+pathelement location=${jboss.dist}/client/ejb.jar/
+pathelement location=${jboss.dist}/client/jaas.jar/
+pathelement location=${jboss.dist}/client/jbosssx-client.jar/
+pathelement location=${jboss.dist}/client/jboss-client.jar/
+pathelement location=${jboss.dist}/client/jnp-client.jar/
+pathelement location=${servlet.jar}/
+/path
+path id=base.path_24
+pathelement location=${jboss.dist}/client/jboss-j2ee.jar/
+pathelement location=${jboss.dist}/client/jaas.jar/
+pathelement location=${jboss.dist}/client/jbosssx-client.jar/
+pathelement location=${jboss.dist}/client/jboss-client.jar/
+pathelement location=${jboss.dist}/client/jnp-client.jar/
+pathelement location=${servlet.jar}/
+/path
+/target
-target name=validate
+target name=validate-jboss depends=validate-servlet
available property=classpath_id value=base.path_22
file=${jboss.dist}/client/ejb.jar /
-available property=classpath_id value=base.path_23
file=${jboss.dist}/client/jboss-j2ee.jar /
+available property=classpath_id value=base.path_24
file=${jboss.dist}/client/jboss-j2ee.jar /
+
/target
target name=fail_if_not_valid unless=classpath_id
-fail message=jboss.dist=${jboss.dist} is not a valid JBoss dist
directory/
+fail message=jboss.dist=${jboss.dist} is not a valid JBOSS_DIST
directory. If using a bundled JBoss version set JBOSS_DIST to the jboss/ subdir./
/target
-target name=init depends=validate,fail_if_not_valid
+target name=init depends=validate-jboss,fail_if_not_valid
property name=classpath refid=${classpath_id} /
echo message=Using JBoss
[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
classpath path=${classpath} /
- include name=org/jboss/docs/interest/*.java /
+ include name=org/jboss/docs/interest/Interest.java /
+ include name=org/jboss/docs/interest/InterestBean.java /
+ include name=org/jboss/docs/interest/InterestHome.java /
+ include name=org/jboss/docs/interest/InterestClient.java /
/javac
/target
+target name=compile-servlet
+ mkdir dir=${build.classes.dir}/
+ javac srcdir=${src.dir}
+ destdir=${build.classes.dir}
+ debug=on
+ deprecation=on
+ optimize=off
+
+ classpath path=${classpath} /
+ include name=org/jboss/docs/interest/InterestServlet.java /
+ /javac
+/target
+
!-- Tutorial ejb jar --
target name=ejb-jar depends=compile
delete dir=${build.interest.dir}/META-INF/
@@ -38,8 +54,9 @@
/fileset
/jar
/target
+
!-- Tutorial web app war --
-target name=war depends=compile
+target name=war depends=compile-servlet
delete dir=${build.interest.dir}/WEB-INF/
mkdir dir=${build.interest.dir}/WEB-INF/classes/org/jboss/docs/interest/
copy file=${src.dir}/org/jboss/docs/interest/web.xml
todir=${build.interest.dir}/WEB-INF /
___
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.
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
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++
|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 server.
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.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at
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) | at | org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:151) | at |
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] 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 a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @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 Binary file 1.3 +359 -450 newsite/src/docs/doco_files/documentation-example.zip Binary file ___ 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=detailaid=467046group_id=1a 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: list 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/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
[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 = 1;
}
}
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.1 2001/10/01 20:55:33 user57 Exp $ --
+!-- $Id: build.xml,v 1.2 2001/10/02 21:34:55 user57 Exp $ --
project default=main name=JBoss Website/Survey
@@ -159,36 +159,69 @@
pathelement path=${junit.junit.lib}/junit.jar/
/path
+!-- JavaMail --
+property name=sun.javamail.root value=${project.thirdparty}/sun/javamail/
+property name=sun.javamail.lib value=${sun.javamail.root}/lib/
+path id=sun.javamail.classpath
+ pathelement path=${sun.javamail.lib}/mail.jar/
+/path
+
+!-- Servlets --
+property name=sun.servlet.root value=${project.thirdparty}/sun/servlet/
+property name=sun.servlet.lib value=${sun.servlet.root}/lib/
+path id=sun.servlet.classpath
+ pathelement path=${sun.servlet.lib}/servlet.jar/
+/path
+
+!-- Log4j --
+property name=apache.log4j.root value=${project.thirdparty}/apache/log4j/
+property name=apache.log4j.lib value=${apache.log4j.root}/lib/
+path id=apache.log4j.classpath
+ pathelement path=${apache.log4j.lib}/log4j.jar/
+/path
+
!-- The combined library classpath --
path id=library.classpath
+ path refid=sun.javamail.classpath/
+ path refid=sun.servlet.classpath/
+ path refid=apache.log4j.classpath/
/path
/target
!-- Configure the external modules which this module depends on. --
target name=_configure-modules unless=configure-modules.disable
+!-- J2EE --
+property name=jboss.j2ee.root value=${project.root}/j2ee/output/
+property name=jboss.j2ee.lib value=${jboss.j2ee.root}/lib/
+path id=jboss.j2ee.classpath
+ pathelement path=${jboss.j2ee.lib}/jboss-j2ee.jar/
+/path
+
+!-- Website (for .jsp includes) --
+property name=jboss.website.root value=${project.root}/website/output/
+property name=jboss.website.docs value=${jboss.website.root}/docs/
+
!-- The combined dependent module classpath --
path id=dependentmodule.classpath
+ path refid=jboss.j2ee.classpath/
/path
/target
!-- Configure the tasks used by this module. --
target name=_configure-tasks unless=configure-tasks.disable
!-- Where source files live --
-property name=source.bin value=${module.source}/bin/
+property name=source.java value=${module.source}/main/
property name=source.metadata value=${module.source}/metadata/
-property name=source.examples value=${module.source}/examples/
-property name=source.stylesheets value=${module.source}/stylesheets/
-property name=source.docs value=${module.source}/docs/
-property name=source.xdocs value=${module.source}/xdocs/
+property name=source.database value=${module.source}/database/
+property name=source.web value=${module.source}/web/
!-- Where build generated files will go --
-property name=build.bin value=${module.output}/bin/
property name=build.metadata value=${module.output}/metadata/
-property name=build.snapshots value=${module.output}/snapshots/
-property name=build.docs value=${module.output}/docs/
-property name=build.xdocs value=${module.output}/xdocs/
-property name=build.stylesheets value=${module.output}/stylesheets/
+property name=build.web value=${module.output}/web/
+property name=build.database value=${module.output}/database/
property name=build.lib value=${module.output}/lib/
+property name=build.beans value=${module.output}/beans/
+property name=build.classes value=${module.output}/classes/
!-- Install/Release structure --
property name=install.id value=${module.name}-${module.version}/
@@ -227,6 +260,18 @@
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
property name=junit.jvm.options value=-Ddummy/
+
+!-- XDoclet --
+path id=xdoclet.task.classpath
+ path refid=javac.classpath/
+ pathelement location=${project.tools}/lib/xdoclet.jar/
+ pathelement location=${project.tools}/lib/ant.jar/
+/path
+taskdef
[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
[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 )
{
aParameters =
[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 === ?xml version=1.0 encoding=UTF-8? !DOCTYPE application !-- $Id: survey-application.xml,v 1.1 2001/10/02 21:34:57 user57 Exp $ -- application display-nameJBoss Survey/display-name module ejbsurvey.jar/ejb /module module web web-urisurvey.war/web-uri context-root/survey/context-root /web /module /application 1.1 website-survey/src/metadata/survey-helper-application.xml Index: survey-helper-application.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE application !-- $Id: survey-helper-application.xml,v 1.1 2001/10/02 21:34:57 user57 Exp $ -- application display-nameJBoss Survey Helper/display-name module web web-urisurvey-helper.war/web-uri context-root/survey/help/context-root /web /module /application 1.1 website-survey/src/metadata/survey-helper-web.xml Index: survey-helper-web.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app !-- $Id: survey-helper-web.xml,v 1.1 2001/10/02 21:34:57 user57 Exp $ -- web-app display-nameJBoss Survey Helper/display-name /web-app 1.1 website-survey/src/metadata/survey-web.xml Index: survey-web.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app !-- $Id: survey-web.xml,v 1.1 2001/10/02 21:34:57 user57 Exp $ -- web-app display-nameJBoss Survey/display-name /web-app ___ 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-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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.2 2001/10/01 23:06:01 user57 Exp $ --
+!-- $Id: build.xml,v 1.3 2001/10/02 22:30:44 user57 Exp $ --
project default=main name=JBoss Website/Forums
@@ -133,7 +133,7 @@
!-- Module name(s) version --
property name=module.name value=forums/
property name=module.Name value=JBoss Website Forums/
-property name=module.version value=unspecified/
+property name=module.version value=DEV/
!-- Invoke the rest of the configuration targets --
call target=_configure-tools/
@@ -174,12 +174,10 @@
!-- Configure the tasks used by this module. --
target name=_configure-tasks unless=configure-tasks.disable
!-- Where source files live --
-property name=source.etc value=${module.source}/etc/
property name=source.metadata value=${module.source}/metadata/
property name=source.lib value=${module.source}/lib/
!-- Where build generated files will go --
-property name=build.etc value=${module.output}/etc/
property name=build.lib value=${module.output}/lib/
property name=build.metadata value=${module.output}/metadata/
property name=build.jive value=${module.output}/jive/
@@ -238,26 +236,15 @@
target name=compile
description=Compile all source files.
depends=init,
- compile-etc,
compile-metadata,
compile-jive/
- !-- Compile etc files (manifests and such) --
- target name=compile-etc depends=init
+ !-- Compile metadata files --
+ target name=compile-metadata depends=init
!-- this property must be set for the config/copy to work --
require property=jivesoftware.jive.home/
echoUsing jivesoftware.jive.home: ${jivesoftware.jive.home}/echo
-mkdir dir=${build.etc}/
-copy todir=${build.etc} filtering=yes
- fileset dir=${source.etc}
- include name=**/*/
- /fileset
-/copy
- /target
-
- !-- Compile metadata files --
- target name=compile-metadata depends=init
mkdir dir=${build.metadata}/
copy todir=${build.metadata} filtering=yes
fileset dir=${source.metadata}
@@ -270,6 +257,9 @@
target name=compile-jive depends=init
mkdir dir=${build.jive}/
unjar src=${source.lib}/jive.jar dest=${build.jive}/
+
+!-- make sure this doesn't confuse jive or anyone else --
+delete file=${build.jive}/application/WEB-INF/classes/jive_init.properties/
/target
@@ -289,9 +279,6 @@
fileset dir=${build.jive}/application
include name=*/**/
/fileset
- zipfileset prefix=WEB-INF/classes dir=${build.etc}
-include name=jive_init.properties/
- /zipfileset
/war
!-- Build the forums.ear --
@@ -508,13 +495,14 @@
| servers to help setup testing environemnts. Users will also have
| to setup the database as specified in the Jive docs.
--
- target name=setup-jive-home
+ target name=setup-jive-home depends=init
copy todir=${jivesoftware.jive.home}
fileset dir=${build.jive}/application/WEB-INF/jiveHome
include name=*/**/
/fileset
/copy
+echo message= * * * /
echoCopied over basic Jive configuration files./echo
echoYou will need finish the setup from the admin/setup page./echo
/target
___
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 @@ ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app -!-- $Id: jive-web.xml,v 1.1 2001/10/01 23:06:01 user57 Exp $ -- +!-- $Id: jive-web.xml,v 1.2 2001/10/02 22:30:44 user57 Exp $ -- web-app + display-nameJBoss Jive Forums WebApp/display-name + + context-param + param-namejiveHome/param-name + param-value@jivesoftware.jive.home@/param-value + /context-param + + servlet + servlet-nameJiveServlet/servlet-name + servlet-classcom.jivesoftware.forum.util.JiveServlet/servlet-class + load-on-startup/ + /servlet + /web-app ___ 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/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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.17 2001/10/02 00:15:38 user57 Exp $ --
+!-- $Id: build.xml,v 1.18 2001/10/02 22:33:02 user57 Exp $ --
-project default=main name=JBoss/Website
+project default=main name=JBoss Website/Website
!-- == --
!-- Initialization --
@@ -152,13 +152,6 @@
!-- Configure the thirdparty libraries required by this module. --
target name=_configure-libraries unless=configure-libraries.disable
-!-- Java Authentication and Authorization Service (JAAS) --
-property name=sun.jaas.root value=${project.thirdparty}/sun/jaas/
-property name=sun.jaas.lib value=${sun.jaas.root}/lib/
-path id=sun.jaas.classpath
- pathelement path=${sun.jaas.lib}/jaas.jar/
-/path
-
!-- JUnit --
property name=junit.junit.root value=${project.thirdparty}/junit/junit/
property name=junit.junit.lib value=${junit.junit.root}/lib/
@@ -168,7 +161,6 @@
!-- The combined library classpath --
path id=library.classpath
- path refid=sun.jaas.classpath/
/path
/target
@@ -188,14 +180,6 @@
property name=source.stylesheets value=${module.source}/stylesheets/
property name=source.docs value=${module.source}/docs/
property name=source.xdocs value=${module.source}/xdocs/
-!-- Where source files live for JBoss Survey --
-property name=survey.root value=${module.root}/survey/
-property name=survey.lib value=${survey.root}/lib/
-property name=survey.source.metadata value=${survey.root}/metadata/
-property name=survey.ejb.source value=${survey.root}/src/ejb/
-property name=survey.client.source value=${survey.root}/src/client/
-property name=survey.web.source value=${survey.root}/web.survey/
-property name=survey.help.web.source value=${survey.root}/web.survey.help/
!-- Where build generated files will go --
property name=build.bin value=${module.output}/bin/
@@ -210,28 +194,16 @@
property name=build.html.printable value=${build.html}/printable/
property name=build.pdf value=${module.output}/pdf/
property name=build.lib value=${module.output}/lib/
-!-- Where Survey build generated files will go --
-property name=build.metadata.survey
value=${module.output}/metadata/survey/
-property name=build.classes value=${module.output}/classes/
-property name=build.gen value=${module.output}/generated/
!-- Install/Release structure --
property name=install.id value=${module.name}-${module.version}/
property name=release.id value=${install.id}/
property name=install.root value=${module.output}/${install.id}/
-!-- Log4j --
-property name=apache.log4j.root value=${project.thirdparty}/apache/log4j/
-property name=apache.log4j.lib value=${apache.log4j.root}/lib/
-path id=apache.log4j.classpath
- pathelement path=${apache.log4j.lib}/log4j.jar/
-/path
-
!-- The combined thirdparty classpath --
path id=thirdparty.classpath
path refid=library.classpath/
path refid=dependentmodule.classpath/
- path refid=apache.log4j.classpath/
/path
!-- This module is based on Java 1.2 --
@@ -248,15 +220,6 @@
path refid=thirdparty.classpath/
/path
-!-- The classpath required to build survey. --
-path id=survey.classpath
- pathelement path=${survey.lib}/jboss-j2ee.jar/
- pathelement path=${project.thirdparty}/sun/javamail/lib/mail.jar/
- pathelement path=${project.thirdparty}/sun/servlet/lib/servlet.jar/
- path refid=javac.classpath/
-/path
-property name=survey.classpath refid=survey.classpath/
-
!-- The classpath required to build javadocs. --
path id=javadoc.classpath
path refid=javac.classpath/
@@ -273,17 +236,6 @@
!-- Controls for the compile-snapshot target --
property name=snapshot.cvsroot
value=:pserver:[EMAIL PROTECTED]:/cvsroot/jboss/
-
-!-- xdoclet --
-path id=xdoclet.task.classpath
- path
[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 @@ !---- !-- == -- -!-- $Id: build.xml,v 1.2 2001/10/02 21:34:55 user57 Exp $ -- +!-- $Id: build.xml,v 1.3 2001/10/02 22:33:43 user57 Exp $ -- project default=main name=JBoss Website/Survey @@ -131,9 +131,9 @@ target name=_configure unless=configure.disable !-- Module name(s) version -- -property name=module.name value=forums/ +property name=module.name value=survey/ property name=module.Name value=JBoss Website Survey/ -property name=module.version value=unspecified/ +property name=module.version value=DEV/ !-- Invoke the rest of the configuration targets -- call target=_configure-tools/ ___ 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: 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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.11 2001/10/02 00:15:38 user57 Exp $ --
+!-- $Id: build.xml,v 1.12 2001/10/02 22:34:27 user57 Exp $ --
project default=main name=JBoss Website/Build
@@ -177,14 +177,21 @@
module name=forums/
module name=survey/
+ !-- Support modules --
+ module name=j2ee/
+
!-- Module groups --
group name=standard
include modules=website, manual, forums, survey/
/group
+ group name=support
+include modules=j2ee/
+ /group
+
!-- Module group sets --
group name=default
-include groups=standard/
+include groups=support, standard/
/group
/moduleconfig
@@ -398,14 +405,13 @@
property name=_module.name value=survey override=true/
property name=_module.output override=true
value=${project.root}/${_module.name}/output/
-!--
mkdir dir=${install.deploy}/
copy todir=${install.deploy}
fileset dir=${_module.output}/lib
include name=survey.ear/
+include name=survey-helper.ear/
/fileset
/copy
---
/target
target name=_module-survey-all depends=_module-survey-most
___
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
[JBoss-dev] CVS update: CVSROOT modules
User: user57 Date: 01/10/02 16:00:01 Modified:.modules Log: o needed for the jboss-website/survey module Revision ChangesPath 1.65 +3 -0 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.64 retrieving revision 1.65 diff -u -r1.64 -r1.65 --- modules 2001/10/02 22:39:49 1.64 +++ modules 2001/10/02 23:00:01 1.65 @@ -103,6 +103,9 @@ jboss-website-thirdparty -a \ thirdparty/oasis \ thirdparty/sun/jaas \ + thirdparty/sun/javamail \ + thirdparty/sun/servlet \ + thirdparty/apache/log4j \ thirdparty/junit/junit jboss-website-modules-a \ ___ 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 16:16:13 Modified:.modules Log: o added jboss-plugins and plugins alias Revision ChangesPath 1.66 +3 -0 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.65 retrieving revision 1.66 diff -u -r1.65 -r1.66 --- modules 2001/10/02 23:00:01 1.65 +++ modules 2001/10/02 23:16:13 1.66 @@ -56,6 +56,8 @@ ## Plugins ## +jboss-plugins-d plugins contrib + _plugins_varia -d variacontrib/varia _plugins_jetty -d jettycontrib/jetty @@ -180,6 +182,7 @@ docs -a jboss-docs website -a jboss-website +plugins -a jboss-plugins # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs cvs.jsp
User: user57 Date: 01/10/02 16:20:05 Modified:src/docs cvs.jsp Log: o removed alias doc for jboss, added docs for jboss-plugins plugins Revision ChangesPath 1.5 +6 -6 newsite/src/docs/cvs.jsp Index: cvs.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/cvs.jsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- cvs.jsp 2001/10/01 20:52:45 1.4 +++ cvs.jsp 2001/10/02 23:20:05 1.5 @@ -63,27 +63,27 @@ p class=headCVS MODULES/p p class=text - The list of available modules has recently changed. Below is a list - of the currently supported modules. These modules are created via - ttCVSROOT/modules/tt, so look there for more information about how - they work. + Below is a list of the currently supported modules. These modules are + created via ttCVSROOT/modules/tt, so look there for more information + about how they work. ul class=text libjboss-all/b: Everything required to build JBoss. libjboss-docs/b: JBoss documenation module (contains the manual). libjboss-website/b: The JBoss website. libjboss-mq/b: The JBossMQ standalone server. + libjboss-plugins/b: Plugins to the JBoss server. libtools/b: Tools for building modules. libthirdparty/b: Thridparty support libraries. /ul p class=text - The following aliases are also available. + The following aliases are also available: ul class=text - libjboss/b: jboss-all libdocs/b: jboss-docs libwebsite/b: jboss-website + libplugins/b: jboss-plugins /ul p class=headCVS Administration Polcies/p ___ 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 16:22:52 Modified:.modules Log: o -d plugins - -d jboss-plugins Revision ChangesPath 1.67 +1 -1 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.66 retrieving revision 1.67 diff -u -r1.66 -r1.67 --- modules 2001/10/02 23:16:13 1.66 +++ modules 2001/10/02 23:22:52 1.67 @@ -56,7 +56,7 @@ ## Plugins ## -jboss-plugins-d plugins contrib +jboss-plugins-d jboss-pluginscontrib _plugins_varia -d variacontrib/varia _plugins_jetty -d jettycontrib/jetty ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/metadata snapshots-web.xml
User: user57
Date: 01/10/02 17:14:54
Modified:src/metadata snapshots-web.xml
Log:
o removed -${build.number} from snaps, as it will just make it hard to
put a preatty face on top of them.
o some currently unused context config...
Revision ChangesPath
1.2 +11 -1 newsite/src/metadata/snapshots-web.xml
Index: snapshots-web.xml
===
RCS file: /cvsroot/jboss/newsite/src/metadata/snapshots-web.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- snapshots-web.xml 2001/08/31 05:30:32 1.1
+++ snapshots-web.xml 2001/10/03 00:14:54 1.2
@@ -1,7 +1,17 @@
?xml version=1.0 encoding=UTF-8?
!DOCTYPE web-app
-!-- $Id: snapshots-web.xml,v 1.1 2001/08/31 05:30:32 user57 Exp $ --
+!-- $Id: snapshots-web.xml,v 1.2 2001/10/03 00:14:54 user57 Exp $ --
web-app
+ display-nameJBoss Unstable Source Snapshots/display-name
+
+ !--
+ | which modules (unstable) have been exported for snapshots.
+--
+ context-param
+ param-namesnapshot.modules/param-name
+ param-value@snapshot.modules@/param-value
+ /context-param
+
/web-app
___
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 17:14:52
Modified:.build.xml
Log:
o removed -${build.number} from snaps, as it will just make it hard to
put a preatty face on top of them.
o some currently unused context config...
Revision ChangesPath
1.19 +51 -45newsite/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/newsite/build.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- build.xml 2001/10/02 22:33:02 1.18
+++ build.xml 2001/10/03 00:14:52 1.19
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.18 2001/10/02 22:33:02 user57 Exp $ --
+!-- $Id: build.xml,v 1.19 2001/10/03 00:14:52 user57 Exp $ --
project default=main name=JBoss Website/Website
@@ -185,6 +185,7 @@
property name=build.bin value=${module.output}/bin/
property name=build.metadata value=${module.output}/metadata/
property name=build.snapshots value=${module.output}/snapshots/
+property name=build.snapshots.tmp value=${build.snapshots}/tmp/
property name=build.docs value=${module.output}/docs/
property name=build.xdocs value=${module.output}/xdocs/
property name=build.stylesheets value=${module.output}/stylesheets/
@@ -236,6 +237,9 @@
!-- Controls for the compile-snapshot target --
property name=snapshot.cvsroot
value=:pserver:[EMAIL PROTECTED]:/cvsroot/jboss/
+
+property name=snapshot.modules
+ value=jboss-all jboss-mq jboss-plugins/
/target
@@ -301,11 +305,12 @@
/fileset
/chmod
/target
-
- !-- Compile cvs source snapshots --
- target name=compile-snapshots depends=init unless=snapshot.bypass
-mkdir dir=${build.snapshots}/
+ !-- Export the cvs modules for snapshots --
+ target name=_compile-snapshots-export-cvs
+ depends=init
+ unless=snapshot-export-cvs.bypass
+mkdir dir=${build.snapshots.tmp}/
echoExporting CVS modules for snaphots.../echo
!-- Make sure there is an entry for this cvsroot --
@@ -313,56 +318,63 @@
cvs cvsroot=${snapshot.cvsroot}
command=-Q -r -f -z3 export
date=TODAY
- package=jboss-all jboss-mq jboss-docs
- dest=${build.snapshots}/
+ package=${snapshot.modules}
+ dest=${build.snapshots.tmp}/
+ /target
-!-- to keep this simple, these jars task live here --
-mkdir dir=${build.lib}/
+ !-- Compile cvs source snapshots --
+ target name=compile-snapshots
+ unless=snapshot.bypass
+ depends=init, _compile-snapshots-export-cvs
+mkdir dir=${build.snapshots}/
-!-- build jboss-all-xxx.zip --
-zip zipfile=${build.lib}/jboss-all-${build.number}.zip
- fileset dir=${build.snapshots}
+!-- build jboss-all.zip --
+zip zipfile=${build.snapshots}/jboss-all.zip
+ fileset dir=${build.snapshots.tmp}
include name=jboss-all/**/
/fileset
/zip
-!-- build jboss-all-xxx.tgz --
-tar tarfile=${build.lib}/jboss-all-${build.number}.tar longfile=gnu
- basedir=${build.snapshots}
+!-- build jboss-all.tgz --
+tar tarfile=${build.snapshots}/jboss-all.tar
+ longfile=gnu
+ basedir=${build.snapshots.tmp}
includes=jboss-all/**
/tar
-gzip src=${build.lib}/jboss-all-${build.number}.tar
- zipfile=${build.lib}/jboss-all-${build.number}.tgz/
+gzip src=${build.snapshots}/jboss-all.tar
+ zipfile=${build.snapshots}/jboss-all.tgz/
-!-- build jboss-mq-xxx.zip --
-zip zipfile=${build.lib}/jboss-mq-${build.number}.zip
- fileset dir=${build.snapshots}
+!-- build jboss-mq.zip --
+zip zipfile=${build.snapshots}/jboss-mq.zip
+ fileset dir=${build.snapshots.tmp}
include name=jboss-mq/**/
/fileset
/zip
-!-- build jboss-mq-xxx.tgz --
-tar tarfile=${build.lib}/jboss-mq-${build.number}.tar longfile=gnu
- basedir=${build.snapshots}
+!-- build jboss-mq.tgz --
+tar tarfile=${build.snapshots}/jboss-mq.tar
+ longfile=gnu
+ basedir=${build.snapshots.tmp}
includes=jboss-mq/**
/tar
-gzip src=${build.lib}/jboss-mq-${build.number}.tar
- zipfile=${build.lib}/jboss-mq-${build.number}.tgz/
+gzip src=${build.snapshots}/jboss-mq.tar
+ zipfile=${build.snapshots}/jboss-mq.tgz/
-!-- build jboss-docs-xxx.zip --
-zip zipfile=${build.lib}/jboss-docs-${build.number}.zip
- fileset dir=${build.snapshots}
-include name=jboss-docs/**/
+!-- build jboss-plugins.zip --
+zip
[JBoss-dev] CVS update: newsite/src/bin update-website.sh
User: user57 Date: 01/10/02 17:57:02 Modified:src/bin update-website.sh Log: o duh... using CVS_OPTIONS properly Revision ChangesPath 1.9 +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.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- update-website.sh 2001/10/02 22:40:08 1.8 +++ update-website.sh 2001/10/03 00:57:02 1.9 @@ -6,7 +6,7 @@ ## ## ### == ### -# $Id: update-website.sh,v 1.8 2001/10/02 22:40:08 user57 Exp $ +# $Id: update-website.sh,v 1.9 2001/10/03 00:57:02 user57 Exp $ ## ## Returns exit status 0 for success, 1 for errors and 2 for fatal errors. @@ -23,7 +23,7 @@ CVS=cvs fi CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/jboss -CVS_OPTIONS=-q -r -f -z3 -d $CVSROOT +CVS_OPTIONS=-Q -r -f -z3 -d $CVSROOT # Where we will will work from if [ x$WORKROOT = x ]; then @@ -93,7 +93,7 @@ if [ x$LOCALCVS = x ]; then # pull down a fresh copy of jboss-website info Pulling down a fresh copy of jboss-website... - $CVS -Q -r -f -z3 $CVS_OPTIONS get -AP jboss-website + $CVS $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
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILServerILService.java
User: starksm
Date: 01/10/02 19:08:54
Modified:src/main/org/jboss/mq/il/oil Tag: Branch_2_4
OILServerILService.java
Log:
We need to check the socketAddress against 0.0.0.0/0.0.0.0
because this is not a valid address on Win32 while it is for
*NIX. See BugParade bug #4343286.
Revision ChangesPath
No revision
No revision
1.2.2.3 +7 -1 jbossmq/src/main/org/jboss/mq/il/oil/OILServerILService.java
Index: OILServerILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILServerILService.java,v
retrieving revision 1.2.2.2
retrieving revision 1.2.2.3
diff -u -r1.2.2.2 -r1.2.2.3
--- OILServerILService.java 2001/09/30 01:14:11 1.2.2.2
+++ OILServerILService.java 2001/10/03 02:08:52 1.2.2.3
@@ -50,7 +50,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.2 $
+ * @version$Revision: 1.2.2.3 $
*/
public class OILServerILService extends org.jboss.mq.il.ServerILJMXService
implements Runnable, OILServerILServiceMBean {
protected ServerSocket serverSocket;
@@ -136,6 +136,12 @@
worker = new Thread(server.threadGroup, this, OIL Worker);
worker.start();
+ /* We need to check the socketAddress against 0.0.0.0/0.0.0.0
+ because this is not a valid address on Win32 while it is for
+ *NIX. See BugParade bug #4343286.
+ */
+ if( socketAddress.toString().equals(0.0.0.0/0.0.0.0) )
+ socketAddress = InetAddress.getLocalHost();
serverIL = new OILServerIL(socketAddress, serverSocket.getLocalPort());
bindJNDIReferences();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/uil UILServerILService.java
User: starksm
Date: 01/10/02 19:08:55
Modified:src/main/org/jboss/mq/il/uil Tag: Branch_2_4
UILServerILService.java
Log:
We need to check the socketAddress against 0.0.0.0/0.0.0.0
because this is not a valid address on Win32 while it is for
*NIX. See BugParade bug #4343286.
Revision ChangesPath
No revision
No revision
1.2.2.3 +7 -1 jbossmq/src/main/org/jboss/mq/il/uil/UILServerILService.java
Index: UILServerILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/uil/UILServerILService.java,v
retrieving revision 1.2.2.2
retrieving revision 1.2.2.3
diff -u -r1.2.2.2 -r1.2.2.3
--- UILServerILService.java 2001/09/30 01:14:11 1.2.2.2
+++ UILServerILService.java 2001/10/03 02:08:54 1.2.2.3
@@ -50,7 +50,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.2 $
+ * @version$Revision: 1.2.2.3 $
*/
public class UILServerILService extends org.jboss.mq.il.ServerILJMXService
implements Runnable, UILServerILServiceMBean {
protected ServerSocket serverSocket;
@@ -137,6 +137,12 @@
worker = new Thread(server.threadGroup, this, UIL Worker);
worker.start();
+ /* We need to check the socketAddress against 0.0.0.0/0.0.0.0
+ because this is not a valid address on Win32 while it is for
+ *NIX. See BugParade bug #4343286.
+ */
+ if( socketAddress.toString().equals(0.0.0.0/0.0.0.0) )
+ socketAddress = InetAddress.getLocalHost();
serverIL = new UILServerIL(socketAddress, serverSocket.getLocalPort());
bindJNDIReferences();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILServerILService.java
User: starksm
Date: 01/10/02 19:09:09
Modified:src/main/org/jboss/mq/il/oil OILServerILService.java
Log:
We need to check the socketAddress against 0.0.0.0/0.0.0.0
because this is not a valid address on Win32 while it is for
*NIX. See BugParade bug #4343286.
Revision ChangesPath
1.10 +7 -1 jbossmq/src/main/org/jboss/mq/il/oil/OILServerILService.java
Index: OILServerILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILServerILService.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- OILServerILService.java 2001/09/30 00:40:16 1.9
+++ OILServerILService.java 2001/10/03 02:09:09 1.10
@@ -46,7 +46,7 @@
* Implements the ServerILJMXService which is used to manage the JVM IL.
*
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class OILServerILService extends org.jboss.mq.il.ServerILJMXService
implements Runnable, OILServerILServiceMBean
{
@@ -366,6 +366,12 @@
worker = new Thread(server.threadGroup, this, OIL Worker);
worker.start();
+ /* We need to check the socketAddress against 0.0.0.0/0.0.0.0
+ because this is not a valid address on Win32 while it is for
+ *NIX. See BugParade bug #4343286.
+ */
+ if( socketAddress.toString().equals(0.0.0.0/0.0.0.0) )
+ socketAddress = InetAddress.getLocalHost();
serverIL = new OILServerIL(socketAddress, serverSocket.getLocalPort());
bindJNDIReferences();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
