[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/jdbc HypersonicDatabase.java HypersonicDatabaseMBean.java
User: peter_f
Date: 01/11/15 03:40:08
Modified:varia/src/main/org/jboss/jdbc HypersonicDatabase.java
HypersonicDatabaseMBean.java
Log:
Minor fixes - cleaned up some -added preRegister() -added a crude read in of
configuration (port, silent, trace) - added start of HSQLDB DatabaseMAnager, now
accesible from localhost:8082
Revision ChangesPath
1.7 +182 -180 contrib/varia/src/main/org/jboss/jdbc/HypersonicDatabase.java
Index: HypersonicDatabase.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/jdbc/HypersonicDatabase.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- HypersonicDatabase.java 2001/10/15 15:09:41 1.6
+++ HypersonicDatabase.java 2001/11/15 11:40:08 1.7
@@ -12,145 +12,160 @@
import java.io.IOException;
import java.io.File;
import java.net.URL;
+import java.util.Hashtable;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
-
import javax.management.*;
-
// our patched HSQLDB Server class
import org.hsqldb.Embedded_Server;
-
+import org.hsqldb.util.Embedded_DatabaseManager;
import org.jboss.system.URLClassLoader;
import org.jboss.system.ServiceMBeanSupport;
+import DatabaseManagerSwing;
/**
-* Integration with Hypersonic SQL (c).
-*Starts a patched HSQLDB 1.61 Hypersonic database in-VM.
-*http://sourceforge.net/projects/hsqldb/
-*
-* @see HypersonicDatabaseMBean
-* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
-* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
-* @author a href=mailto:[EMAIL PROTECTED];Peter Fagerlund/a
-* @version $Revision: 1.6 $
-*/
-public class HypersonicDatabase
-extends ServiceMBeanSupport
-implements HypersonicDatabaseMBean, MBeanRegistration
-{
- // Constants -
-
- // Attributes
- Thread runner;
- //Process proc; // whats this ?
- MBeanServer server;
-
-// does not call System.exit() at shutdown
+ * Integration with Hypersonic SQL (c). Starts a patched HSQLDB 1.61 Hypersonic
database in-VM.
+ * http://sourceforge.net/projects/hsqldb/
+ * @see HypersonicDatabaseMBean
+ * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
+ * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
+ * @author a href=mailto:[EMAIL PROTECTED];Peter Fagerlund/a
+ * @version $Revision: 1.7 $
+ */
+public class HypersonicDatabase extends ServiceMBeanSupport implements
HypersonicDatabaseMBean, MBeanRegistration {
+// Constants -
+// Attributes
+// HSQLDB Thread
+Thread dbRunner;
+// HSQLDB DatabaseMAnager Thread
+Thread dbMRunner;
+// Mbean Server
+MBeanServer server;
+// HSQLDB patched server class
org.hsqldb.Embedded_Server embeddedDBServer;
-
- String name = jboss; // Database name will be appended to db.properties
location/hypersonic/
- int port = 1476; // Default port
- boolean silent = true;
- boolean trace = false;
-
- // Static
-
- // Constructors --
- public HypersonicDatabase()
- {
- }
-
- // Public
- // Settings
- public void setDatabase(String name)
- {
- this.name = name;
- }
-
- public String getDatabase()
- {
- return name;
- }
-
- public void setPort(int port)
- {
- this.port = port;
- }
-
- public int getPort()
- {
- return port;
- }
-
- public void setSilent(boolean silent)
- {
- this.silent = silent;
- }
-
- public boolean getSilent()
- {
- return silent;
- }
-
- public void setTrace(boolean trace)
- {
- this.trace = trace;
- }
-
- public boolean getTrace()
- {
- return trace;
- }
-
- public ObjectName getObjectName(MBeanServer server, ObjectName name)
- throws javax.management.MalformedObjectNameException
- {
- this.server = server;
- return name == null ? new ObjectName(OBJECT_NAME) : name;
- }
-
- public String getName()
- {
- return Hypersonic;
- }
-
- public void startService()
[JBoss-dev] Log in DB
I been playing with reading in the server.log to hsqldb ...where i create a
table LOG with {id,stamp,service,type,message}, it is really cool to do a
SELECT * FROM LOG WHERE MESSAGE LIKE '%jmx%' ORDER BY SERVICE
I also glanced at log4j's SocketAppender and SocketNode ...
There is a log4j client called Chainsaw that is a kind of SocketNode and
then all one have to do in JBossRH is add to log4j.properties a default
SocketAppender. But this do not give me the sql syntax for filtering and
being able to also look at several log nodes at the same time.
So i am thinking of creating a kind of SocketNode that will use a hsqldb
instance, should i submit it as patch or where is a good place for it ? ...
Also does JSR-77 have something here that i can use should look at ? ...
/peter_f
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml
User: slaboure Date: 01/11/15 05:50:45 Added: src/xdocs/howto howtoclustering.xml Log: Added quick and simple clustering howto Revision ChangesPath 1.1 manual/src/xdocs/howto/howtoclustering.xml Index: howtoclustering.xml === section id=clustering lang=en titleClustering in JBoss 3.0 alpha/title paraAuthors: author firstnameSacha/firstname surnameLabourey/surname /author email[EMAIL PROTECTED]/email author firstnameBill/firstname surnameBurke/surname /author email[EMAIL PROTECTED]/email /para section titleIntroduction/title section titleWhat this article is about/title paraThis document introduces basic clustering setup for Entity Beans, Stateful Session Beans and Stateless Session Beans. More advanced documentation is available in the main documentation (book)./para paraClustering should be considered in alpha state. Feedback is highly welcome./para paraClustering is built on top of the ulink url = http://www.javagroups.com/;JavaGroups/ulink framework and requires JDK 1.3.x./para paraIn order to create a cluster of JBoss nodes, you simply need to launch several JBoss (with clustering activated, see below) instances on different hosts. JBoss instances will automatically detect their neighbors and form a cluster./para /section /section section titleGeneral setup/title section paraClustering features are available in the pre 3.0 sources. First get the latest sources from CVS or download one of the sources daily snapshot. You then need to build JBoss server (run jboss-all/build/build.bat or jboss-all/build/build.sh). For more information read this xref linkend=intro.examples.source/. /para paraThe resulting JBoss server can be found in jboss-all/build/output/jboss-3.0.0alpha./para paraTo activate global clustering support, you need to copy the file jboss-all/cluster/etc/cluster-service.xml in the /deploy directory of your newly built JBoss server. Clustering is now activated in your JBoss server./para /section /section section titleStateless Session Beans/title section paraTo make a Stateless Session Bean (SLSB) active in a cluster, you need to modify its deployment settings in jboss.xml:/para paraprogramlisting![CDATA[ jboss enterprise-beans session ejb-namenextgen.StatelessSession/ejb-name jndi-namenextget.StatelessSession/jndi-name clusteredTrue/clustered /session /enterprise-beans /jboss ]]/programlisting/para paraThus, you simply need to add the lt;clusteredgt; tag to your existing jboss.xml configuration file./para /section /section section titleStateful Session Beans/title section paraTo make a Stateful Session Bean (SFSB) active in a cluster, you need to modify its deployment settings in jboss.xml:/para paraprogramlisting![CDATA[ jboss enterprise-beans session ejb-namenextgen.StatefulSession/ejb-name jndi-namenextget.StatefulSession/jndi-name clusteredTrue/clustered /session /enterprise-beans /jboss ]]/programlisting/para paraThus, like for SLSB, you simply need to add the lt;clusteredgt; tag to your existing jboss.xml configuration file. By default, bean state is replicated in-memory in sub-groups of two nodes./para /section /section section titleEntity Beans/title section paraTo make an Entity Bean (EB) active in a cluster, you need to modify its deployment settings in jboss.xml:/para paraprogramlisting![CDATA[ jboss enterprise-beans entity ejb-namenextgen.EnterpriseEntity/ejb-name
[JBoss-dev] CVS update: manual/src/xdocs jbossdocs.xml
User: slaboure Date: 01/11/15 05:50:45 Modified:src/xdocs jbossdocs.xml Log: Added quick and simple clustering howto Revision ChangesPath 1.11 +3 -1 manual/src/xdocs/jbossdocs.xml Index: jbossdocs.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/jbossdocs.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jbossdocs.xml 2001/11/05 18:19:44 1.10 +++ jbossdocs.xml 2001/11/15 13:50:45 1.11 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=UTF-8? -!-- $Id: jbossdocs.xml,v 1.10 2001/11/05 18:19:44 schaefera Exp $ -- +!-- $Id: jbossdocs.xml,v 1.11 2001/11/15 13:50:45 slaboure Exp $ -- !DOCTYPE book SYSTEM file:@oasis.docbook.xml.root@/docbookx.dtd [ !ENTITY preface.xml SYSTEM preface.xml !ENTITY jbossintro.xml SYSTEM jbossintro.xml @@ -43,6 +43,7 @@ !ENTITY howtopetstore.xmlSYSTEM howto/howtopetstore.xml !ENTITY howtococoon.xml SYSTEM howto/howtococoon.xml !ENTITY howtossl.xml SYSTEM howto/howtossl.xml + !ENTITY howtoclustering.xml SYSTEM howto/howtoclustering.xml ] book @@ -123,6 +124,7 @@ howtojaxp.xml; howtocmp2.xml; + howtoclustering.xml; /chapter chapter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: jars in sars ?
If I remember correctly it worked once but I think marc asked me to take it out again. If it works, you can put the jars anywhere you want in the sar: I would recommend the top level. There is also a feature whereby you include a tag like this local-directory path=local-directory/ in your jbsoo-service.xml and the contents of local-directory are copied literally to the db directory. However, this does not (as I recall) get added to the classpath. If I did indeed remove jars in sars (I recomend trying it to see;-), it would be pretty trivial to put it back (maybe 1 line change) Would you like to lobby for it? thanks david jencks On 2001.11.15 04:45:45 -0500 Julian Gosnell wrote: Is this supported yet ? Where should they be / /META-INF/lib etc Or can I do it via /META-INF/MANIFEST.mf ? I want to stick all the Jetty jars into the jetty-service.sar - so I can hot swap not only the instance, but the version of Jetty that I am running. Cheers Guys, Jules __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] can't build jboss from cvs
Adam, while the tone is really not appropriate (only I get to bang on Jason like that), I agree that BM can be frustrating. It is however functional and powerful, we do need a simple file describing this is how to build. Right now the BM paper is way too complex, I am not sure we need to understand how bm works, just how to build the files. That readme is missing and it can frustrate newbie developers like you but really Jason we do need a README-BUILD file at the top of the directory something that says. Go to build/, type sh build.sh or build.bat according to platform, the results will be in output/, have a good day and basta! the build.sh in server can confuse newbies, (ehmmm and me as well :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Adam |Heath |Sent: Thursday, November 15, 2001 2:19 AM |To: Jason Dillon |Cc: JBoss Development |Subject: RE: [JBoss-dev] can't build jboss from cvs | | |On Wed, 14 Nov 2001, Jason Dillon wrote: | | If you are trying to build a 3.0 .deb then please use the |'jboss-all' module | from cvs and use 'build/build.sh release' to create a release |suitable for | stuffing into the package. The files will be inder |'build/output/jboss-*/ | |Ok, I've done this, and everything has built fine. | |The layout of build/output looks useable, and I can produce debs from that. |I'll be moving stuff around, to make it fit properly in FHS. I'll |be making |some things into symlinks, to give jboss a correct view on the world. In |other cases, I'll modify the configuration files to access the correct |locations directly. | |Now, to the biggest issue with all this. Could the final jboss |tarball that |is created, *NOT* have any external source? I can understand |having a tarball |that does have this source, but could it be called |jboss-bundle-src.tar.gz, or |something. If there is no source tarball that is in this pristince state, |then I will not be able to upload jboss to Debian, because then it |would mean |that Debian is distributing non-free software, which is not allowed. | |Making debs of course, doesn't really matter about what is |included and what |isn't. But for actual upload to the Debian archive(and all its mirrors), I |*NEED* this non-free code and external code removed from the |source tarball. |Even if this means the build system contains broken references to these |missing files, that is fine. | |Additionally, I tried setting build.compiler=jikes in |build/build.xml, but it |didn't compile blindly fast. Is this the correct way to use jikes? | | |___ |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] Separating JMX/EJB
|I intend to write a whitey on it some day too, but basically it goes |something like this: |* Meta-programming is good, but not inherent to EJB true, but a sophism You are intelligent, but intelligence is not inherent to Rickard Oberg (I am intelligent as well), does that make Rickard Oberg dumb? |* The EJB programming model in general is flawed. (See EJB-INTEREST for |lots of conflicting answers to common questions. If experts can't figure |it out, how are mortals supposed to?!) could it be because experts are donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses? I think so. Anyway when you really make your points, make sure to be specific about the model in general :) that's not going to cut it. |* In particular, dynamic (re)configuration of EJB is not possible, and |it should be (compare with JMX/Jini) false |* The EJB persistence model is flawed, compared with JDO. true boloney, sliced thick, with peanuts in the middle, will end up as chunky 2c toilet wisdom marcf | |/Rickard | |-- |Rickard Öberg | | |___ |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] Invocation and MethodInvocation
|But isn't the state that the security interceptor uses really meta-data |about the container? Shouldn't the interceptors get all meta-data from afaik yes, and getting that information from the invocation pointers to the container (container here as a repository of metadata) is a way to go. |the *container*? If that is done, you'd get very clean separation of |concerns, where the interceptor act upon the meta-data, but is not |responsible for the actual meta-data. To me that seems more natural. yes, I agree. |So, the point isn't that the security interceptors should be stateless. |In fact, they may very well be stateful. However, they should not have |state *particular to any one container* (compare with Stateless Session |Beans). Following Turin, the state here is really context of the state machine, there is no context that stays with the machine once the invocation is gone through. If there is, it is in cache (think EJB) not in the interceptors. |Also, the Model MBeans would be responsible for reading the meta-data |from XML, which would then be provided through the standard methods |(getMBeanInfo) to the interceptors. This allows the interceptor/state |decoupling mentioned above. If the meta-data moves to RDF with |namespaces you could also have multiple aspects of a container in *one* |XML file (I'm not sure why people haven't done this already). | |To me the only reason to use multiple XML files is that namespaces |aren't used. If namespaces were introduced it should be trivial to merge |them all into one (ejb-jar.xml). h you have been pushing this RDF thingy for the past months, if it does indeed allow for a one file admin, it might be worth it. Right now we are going exactly the opposite way with the full file split across many little files, possibly in sars... interesting |Do take time to look into Aspect Oriented Programming if you have time. |Volume 44/Issue 10 of Communications of the ACM |(http://portal.acm.org/toc.cfm?id=383845type=issuecoll=portaldl= |ACMidx=J79part=magazineWantType=Magazinestitle=CACM) |have lots of great articles on the subject, and there are lots of |parallels with how JBoss works already. Yes, Aspect programming is the compilation heavy approach by PARC to meta-programming. If you read this carefully you see that scripting is probably the middle ground between compilation heavy PARC and XML light EJB. Research but there is really no reason why intercepting mbeans wouldn't be close to it. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: |I intend to write a whitey on it some day too, but basically it goes |something like this: |* Meta-programming is good, but not inherent to EJB true, but a sophism You are intelligent, but intelligence is not inherent to Rickard Oberg (I am intelligent as well), does that make Rickard Oberg dumb? What an utterly stupid remark. What I meant was: MP is good, EJB has it, but it's not the only way to get MP. |* The EJB programming model in general is flawed. (See EJB-INTEREST for |lots of conflicting answers to common questions. If experts can't figure |it out, how are mortals supposed to?!) could it be because experts are donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses? I think so. Anyway when you really make your points, make sure to be specific about the model in general :) that's not going to cut it. What utterly stupid remarks. Marc, Marc, time to return to reality, yoh, we're over hree |* In particular, dynamic (re)configuration of EJB is not possible, and |it should be (compare with JMX/Jini) false Because..? 1) Bean A uses bean B. B dies, but C that implements the same interface is still alive. Now what's A supposed to do? How will it be notified that B is dead, and how is it supposed to find C? (with hardcoding these dependencies in of course) 2) Bean A stores files in a particular directory. The name of the directory changes. A needs to be alerted of this. How? Change the XML file with environment settings and redeploy? Gee.. great... |* The EJB persistence model is flawed, compared with JDO. true boloney, sliced thick, with peanuts in the middle, will end up as chunky 2c toilet wisdom Thanks for your input, you really helped show why EJB is good, or rather, why my reasons to not use EJB are false. Thanks again. Now back to our regular programming. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
marc fleury wrote: h you have been pushing this RDF thingy for the past months, if it does indeed allow for a one file admin, it might be worth it. Right now we are going exactly the opposite way with the full file split across many little files, possibly in sars... interesting Well, namespaces can be used with or without RDF. It's just a very nice way to get multiple aspects of a particular element into one XML file without element name clashes. Simple too. |Do take time to look into Aspect Oriented Programming if you have time. |Volume 44/Issue 10 of Communications of the ACM |(http://portal.acm.org/toc.cfm?id=383845type=issuecoll=portaldl= |ACMidx=J79part=magazineWantType=Magazinestitle=CACM) |have lots of great articles on the subject, and there are lots of |parallels with how JBoss works already. Yes, Aspect programming is the compilation heavy approach by PARC to meta-programming. To be precise, AspectJ is the compilation heavy approach. Aspect Oriented Programmin in general is more of a philosophy that can be implemented in numerous ways, the interceptor architecture of JBoss being one of them. The interceptors in JBoss fit really well with the notion of aspects in AOP. If you read this carefully you see that scripting is probably the middle ground between compilation heavy PARC and XML light EJB. Research but there is really no reason why intercepting mbeans wouldn't be close to it. Yes, scripting will make it easier to insert aspect join points. Good point. To me it seems like AspectJ has this scripting aspect to it, although it uses pre-runtime compilation to get it into bytecode. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: jars in sars ?
Use the codebase reference of the sar format, don't package the jar. This already works. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Thursday, November 15, 2001 4:46 AM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] RH: jars in sars ? | | | |Is this supported yet ? | |Where should they be |/ |/META-INF/lib |etc | |Or can I do it via /META-INF/MANIFEST.mf ? | |I want to stick all the Jetty jars into the |jetty-service.sar - so I can hot swap not only the |instance, but the version of Jetty that I am running. | |Cheers Guys, | | |Jules | | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? -danch Scott M Stark wrote: Any of the interceptors can be made stateless, its a question of the cost of reassociating the state from the container meta-data and having to cast from an opaque generic form to the data required by the interceptor. The current state in the security interceptors is just cached data derived from the container meta-data. In the case of the SecurityProxyInterceptor the derived data can be an expensive transformation of the container meta-data. |should not need to know or store the interceptor-specific state info for |its chain. IMHO using a catch-all (or cache-all) map is a bit of a hack. |In particular, this conflicts directly with the security proxy interceptor. But isn't the state that the security interceptor uses really meta-data about the container? Shouldn't the interceptors get all meta-data from the *container*? If that is done, you'd get very clean separation of concerns, where the interceptor act upon the meta-data, but is not responsible for the actual meta-data. To me that seems more natural. So, the point isn't that the security interceptors should be stateless. In fact, they may very well be stateful. However, they should not have state *particular to any one container* (compare with Stateless Session Beans). ___ 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] Invocation and MethodInvocation
danch wrote: When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? Bean instance, container, and client. Yes. It may only hold state that is relevant for the particular work it is doing, such how to do it. For example, an invocation monitor sending messages to JMS might have an instance variable with the name of the topic to send messages to. That name is not client specific, it is not instance specific, and it is not container specific, but it is nevertheless state. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation and MethodInvocation
|When we talk about 'stateless' interceptors, do we really mean |stateless, or do we merely mean stateless with regard to bean instance |and client? bean instance and client marcf |-danch | |Scott M Stark wrote: | | Any of the interceptors can be made stateless, its a question of the cost | of reassociating the state from the container meta-data and having to | cast from an opaque generic form to the data required by the interceptor. | The current state in the security interceptors is just cached |data derived | from the container meta-data. In the case of the SecurityProxyInterceptor | the derived data can be an expensive transformation of the container | meta-data. | ||should not need to know or store the interceptor-specific state info | | for | ||its chain. IMHO using a catch-all (or cache-all) map is a bit of a | | hack. | ||In particular, this conflicts directly with the security proxy | | interceptor. | | |But isn't the state that the security interceptor uses really meta-data |about the container? Shouldn't the interceptors get all meta-data from |the *container*? If that is done, you'd get very clean separation of |concerns, where the interceptor act upon the meta-data, but is not |responsible for the actual meta-data. To me that seems more natural. | |So, the point isn't that the security interceptors should be stateless. |In fact, they may very well be stateful. However, they should not have |state *particular to any one container* (compare with Stateless Session |Beans). | | | | | | ___ | 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] Invocation and MethodInvocation
|Bean instance, container, and client. Yes. It may only hold state that |is relevant for the particular work it is doing, such how to do it. For |example, an invocation monitor sending messages to JMS might have an |instance variable with the name of the topic to send messages to. That |name is not client specific, it is not instance specific, and it is not |container specific, but it is nevertheless state. And Turin calls them state machines. I would rather quote the genius that got it started than the wallpaper patterns of the itzy bitzy weeny bozos of today marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Separating JMX/EJB
|What an utterly stupid remark. Laaa laa la laa laaa laa ! ( I am not listening ) |What I meant was: MP is good, EJB has it, but it's not the only way to |get MP. La! la ! la! la! la! la! | could it be because experts are donkey-dick-sucking-monkeys that don't | know their ass from their tinny winny pinuses? I think so. |What utterly stupid remarks. Marc, Marc, time to return to reality, |yoh, we're over hree Me gna! you gna! La La Laaa L! |Because..? |1) Bean A uses bean B. B dies, but C that implements the same interface |is still alive. Now what's A supposed to do? How will it be notified |that B is dead, and how is it supposed to find C? (with hardcoding these |dependencies in of course) Rickard you are talking of dependencies. The EJB spec defines dependencies in XML (soft) the proxies can implement failover, if you need notification (say to restart) you can be notified through many other frameworks including JMX and jini. |2) Bean A stores files in a particular directory. The name of the |directory changes. A needs to be alerted of this. How? Change the XML |file with environment settings and redeploy? Gee.. great... A notification of state change can be achieved by other means. A simple reset of context in most cases would do that. Rickard these are truly minor points that can be solved for the price of a callback on the bean. They are by no means show stoppers that invalidate the model (which really doesn't worry itself with these). We can do it simply in JBoss by offering an MBean in the EJB, you can certainly push for it in spec commitee (if you are in the commitee). Heck! require an MBean for the properties (pointers and what not), and you are done. |Thanks for your input, you really helped show why EJB is good, or |rather, why my reasons to not use EJB are false. Thanks again. | |Now back to our regular programming. Come to our trainings :) we really go down and dirty with the persistence, the finders, the metaprogramming and the semantics of EJB. It is all kosher. You should really come in London, snore marcf | |/Rickard | |-- |Rickard Öberg | | |___ |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] RH: jars in sars ?
|I assume that's what I am already doing.. | |but now assume that as well as altering the glue code, |that lives as classes in the sar, I actually want to |make changes to Jetty, and have them deployed into RH |whilst it is running... | |I can | |1. package a new Jetty jar in the jetty sar - ideal, |but not supported ? | |2. unpack my new jetty jar into the sar and deploy |that - I assume that would work | | |I'll try 2. I'd rather have 1. We will get you that. Unless David Jencks added that, I don't remember putting it myself, we will do it. marcf | |Thanks for your time, | | |Jules | | --- marc fleury [EMAIL PROTECTED] wrote: Use |the codebase reference of the sar format, don't | package the jar. This | already works. | | marcf | | |-Original Message- | |From: [EMAIL PROTECTED] | ||[mailto:[EMAIL PROTECTED]]On | Behalf Of | |Julian Gosnell | |Sent: Thursday, November 15, 2001 4:46 AM | |To: [EMAIL PROTECTED] | |Subject: [JBoss-dev] RH: jars in sars ? | | | | | | | |Is this supported yet ? | | | |Where should they be | |/ | |/META-INF/lib | |etc | | | |Or can I do it via /META-INF/MANIFEST.mf ? | | | |I want to stick all the Jetty jars into the | |jetty-service.sar - so I can hot swap not only the | |instance, but the version of Jetty that I am | running. | | | |Cheers Guys, | | | | | |Jules | | | | | |__ | |Do You Yahoo!? | |Everything you'll ever need on one web page from | News and Sport to | |Email and Music Charts | |http://uk.my.yahoo.com | | | |___ | |Jboss-development mailing list | |[EMAIL PROTECTED] | ||https://lists.sourceforge.net/lists/listinfo/jboss-development | | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
They are talking stateless with regard to any container instance. - Original Message - From: danch [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 7:07 AM Subject: Re: [JBoss-dev] Invocation and MethodInvocation When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client? -danch Scott M Stark wrote: Any of the interceptors can be made stateless, its a question of the cost of reassociating the state from the container meta-data and having to cast from an opaque generic form to the data required by the interceptor. The current state in the security interceptors is just cached data derived from the container meta-data. In the case of the SecurityProxyInterceptor the derived data can be an expensive transformation of the container meta-data. |should not need to know or store the interceptor-specific state info for |its chain. IMHO using a catch-all (or cache-all) map is a bit of a hack. |In particular, this conflicts directly with the security proxy interceptor. But isn't the state that the security interceptor uses really meta-data about the container? Shouldn't the interceptors get all meta-data from the *container*? If that is done, you'd get very clean separation of concerns, where the interceptor act upon the meta-data, but is not responsible for the actual meta-data. To me that seems more natural. So, the point isn't that the security interceptors should be stateless. In fact, they may very well be stateful. However, they should not have state *particular to any one container* (compare with Stateless Session Beans). ___ 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] Separating JMX/EJB
|Hehe.. you're so screwed... awhh.. why do I even bother.. :-) As much as I really love to argue with you I really want to work on RH and put it out, but these discussions are down the road, really I extend the invitation again, I will try to get you to come to one of the trainings. |Alright, you may have a point, but it's not really valid until it gets |implemented *well*. sure. It is not there yet, if the point is valid (meaning people really ask for it) then it might see the light of day. |So you'd need to go outside EJB for such a common requirement as runtime |reconfiguration? Is that good? JMX isn't bad. We like it :) it might become a part of the J2EE spec (it should) so there you have it. |like EJB, is because it's overused. People use it for things they |shouldn't use it for, especially for web applications where the web |client and EJB's are in the same JVM. And you still need to go through |the remote interface, thus introducing a whole bunch of heavyweight |patterns such as Data Transfer Objects. The weight of the container is minimal, it is serialization that is heavy, but really that's enough for today we will take it again down the road kid, thanks for your attention marcf | | |/Rickard | | |-- |Rickard Öberg | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: jars in sars ?
I assume that's what I am already doing.. but now assume that as well as altering the glue code, that lives as classes in the sar, I actually want to make changes to Jetty, and have them deployed into RH whilst it is running... I can 1. package a new Jetty jar in the jetty sar - ideal, but not supported ? 2. unpack my new jetty jar into the sar and deploy that - I assume that would work I'll try 2. I'd rather have 1. Thanks for your time, Jules --- marc fleury [EMAIL PROTECTED] wrote: Use the codebase reference of the sar format, don't package the jar. This already works. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Thursday, November 15, 2001 4:46 AM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] RH: jars in sars ? | | | |Is this supported yet ? | |Where should they be |/ |/META-INF/lib |etc | |Or can I do it via /META-INF/MANIFEST.mf ? | |I want to stick all the Jetty jars into the |jetty-service.sar - so I can hot swap not only the |instance, but the version of Jetty that I am running. | |Cheers Guys, | | |Jules | | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
- Original Message - From: marc fleury [EMAIL PROTECTED] To: Rickard Öberg [EMAIL PROTECTED]; Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 6:59 AM Subject: RE: [JBoss-dev] Invocation and MethodInvocation |But isn't the state that the security interceptor uses really meta-data |about the container? Shouldn't the interceptors get all meta-data from afaik yes, and getting that information from the invocation pointers to the container (container here as a repository of metadata) is a way to go. |the *container*? If that is done, you'd get very clean separation of |concerns, where the interceptor act upon the meta-data, but is not |responsible for the actual meta-data. To me that seems more natural. yes, I agree. Really, what am I cleaning up by moving container derived data out of the interceptors? The fact that the meta-data is in the container is simply a matter of choice. The security meta-data is really an interceptor property. No where in the codebase is the EJBSecurityManager for the container used but in the SecurityInterceptor and SecurityProxyInterceptor. The same is true of the SecurityProxyInterceptor. The custom securityProxy at the Container is also not used anywhere but in the SecurityProxyInterceptor and its supporting classes. By virtue of the fact that one can define interceptors per bean class we are supporting interceptors that are tied to their container in interceptor specific ways. Users are writing interceptors that have their own state based on data derived from container meta-data in an interceptor specific way, and the container has no knowledge of this state. |So, the point isn't that the security interceptors should be stateless. |In fact, they may very well be stateful. However, they should not have |state *particular to any one container* (compare with Stateless Session |Beans). Following Turin, the state here is really context of the state machine, there is no context that stays with the machine once the invocation is gone through. If there is, it is in cache (think EJB) not in the interceptors. This is a restriction on the current view of the interceptors. You can argue that interceptors must be stateless. This simply pushes each stateful interceptor to develop their own session cache management layer. What are we gaining from this change in the interceptor model? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
marc fleury wrote: |What an utterly stupid remark. Laaa laa la laa laaa laa ! ( I am not listening ) Hehe.. you're so screwed... awhh.. why do I even bother.. :-) |Because..? |1) Bean A uses bean B. B dies, but C that implements the same interface |is still alive. Now what's A supposed to do? How will it be notified |that B is dead, and how is it supposed to find C? (with hardcoding these |dependencies in of course) Rickard you are talking of dependencies. The EJB spec defines dependencies in XML (soft) the proxies can implement failover, if you need notification (say to restart) you can be notified through many other frameworks including JMX and jini. Well, EJB's can't use Jini (can't hold on to a ServiceDiscoveryManager for example). If you want the proxies to do the failover, which would be entirely possible, you need to be able to let them point to many various instances of possibly different implementations. I guess the EJB interface/spec in itself would allow for this, but it would require quite a lof of the EJB container, as opposed to a rather simple hack in JMX/Jini. Alright, you may have a point, but it's not really valid until it gets implemented *well*. |2) Bean A stores files in a particular directory. The name of the |directory changes. A needs to be alerted of this. How? Change the XML |file with environment settings and redeploy? Gee.. great... A notification of state change can be achieved by other means. A simple reset of context in most cases would do that. Rickard these are truly minor points that can be solved for the price of a callback on the bean. They are by no means show stoppers that invalidate the model (which really doesn't worry itself with these). We can do it simply in JBoss by offering an MBean in the EJB, you can certainly push for it in spec commitee (if you are in the commitee). Heck! require an MBean for the properties (pointers and what not), and you are done. So you'd need to go outside EJB for such a common requirement as runtime reconfiguration? Is that good? Sorry, but it's still bad. However, one of the key reasons why I don't like EJB, is because it's overused. People use it for things they shouldn't use it for, especially for web applications where the web client and EJB's are in the same JVM. And you still need to go through the remote interface, thus introducing a whole bunch of heavyweight patterns such as Data Transfer Objects. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, David Jencks wrote: Out of curiousity, where does connector (jbosscx) fit into your packaging scheme? For 3.0 you might consider putting the contents of pool and connector into one package (if they aren't already) as pool is now small and only used by jbosscx. The stuff I did for 2.4 was done based on jar names. If it was a separate jar, I split it off. This is obviously not the correct way to do it. It should be split based on the functionality. I'm still learning about all the different functionality parts of jboss, and how they relate. Previously, I had just downloaded jboss-tomcat, and ran it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
On 2001.11.15 11:09:40 -0500 Scott M Stark wrote: I feel like its deja vu all over again. About a month ago I had this same conversation with Scott and concluded that having an instance of interceptor for each chain is definitely the way to go. Here are some reasons: Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. I vote for instances of interceptors per chain. The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. david jencks - Original Message - From: marc fleury [EMAIL PROTECTED] To: Rickard Öberg [EMAIL PROTECTED]; Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 6:59 AM Subject: RE: [JBoss-dev] Invocation and MethodInvocation |But isn't the state that the security interceptor uses really meta-data |about the container? Shouldn't the interceptors get all meta-data from afaik yes, and getting that information from the invocation pointers to the container (container here as a repository of metadata) is a way to go. |the *container*? If that is done, you'd get very clean separation of |concerns, where the interceptor act upon the meta-data, but is not |responsible for the actual meta-data. To me that seems more natural. yes, I agree. Really, what am I cleaning up by moving container derived data out of the interceptors? The fact that the meta-data is in the container is simply a matter of choice. The security meta-data is really an interceptor property. No where in the codebase is the EJBSecurityManager for the container used but in the SecurityInterceptor and SecurityProxyInterceptor. The same is true of the SecurityProxyInterceptor. The custom securityProxy at the Container is also not used anywhere but in the SecurityProxyInterceptor and its supporting classes. By virtue of the fact that one can define interceptors per bean class we are supporting interceptors that are tied to their container in interceptor specific ways. Users are writing interceptors that have their own state based on data derived from container meta-data in an interceptor specific way, and the container has no knowledge of this state. |So, the point isn't that the security interceptors should be stateless. |In fact, they may very well be stateful. However, they should not have |state *particular to any one container* (compare with Stateless Session |Beans). Following Turin, the state here is really context of the state machine, there is no context that stays with the machine once the invocation is gone through. If there is, it is in cache (think EJB) not in the interceptors. This is a restriction on the current view of the interceptors. You can argue that interceptors must be stateless. This simply pushes each stateful interceptor to develop their own session cache management layer. What are we gaining from this change in the interceptor model? ___ 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] RH: jars in sars ?
On 2001.11.15 10:42:54 -0500 Julian Gosnell wrote: I assume that's what I am already doing.. I think so too but now assume that as well as altering the glue code, that lives as classes in the sar, I actually want to make changes to Jetty, and have them deployed into RH whilst it is running... I can 1. package a new Jetty jar in the jetty sar - ideal, but not supported ? 2. unpack my new jetty jar into the sar and deploy that - I assume that would work 3. (with jars separate, not in jetty.sar, just a plain jetty-service.xml) Remove the out of date jar, jetty-service.xml will suspend all its mbeans, redeploy new jar, jetty-service.xml will automatically redeploy all its mbeans. This is supposed to work now, although I haven't tested it extensively with the new mbean-refs in place. If you try and find it doesn't work PLEASE let me know. I think at the moment just copying a new jar over the old one doesn't work-- IMHO notifying to undeploy old version and redeploy new version is the job of the autodeployer, but I haven't had a chance to update it yet. It is also possible that you have to explicitly undeploy the old jar with the ServiceDeployer. Anyway I will try to find a few minutes to make jars go back in sars ;-) david jencks I'll try 2. I'd rather have 1. Thanks for your time, Jules --- marc fleury [EMAIL PROTECTED] wrote: Use the codebase reference of the sar format, don't package the jar. This already works. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Thursday, November 15, 2001 4:46 AM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] RH: jars in sars ? | | | |Is this supported yet ? | |Where should they be |/ |/META-INF/lib |etc | |Or can I do it via /META-INF/MANIFEST.mf ? | |I want to stick all the Jetty jars into the |jetty-service.sar - so I can hot swap not only the |instance, but the version of Jetty that I am running. | |Cheers Guys, | | |Jules | | |__ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
David Jencks wrote: Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. Seems logical to put the MBeanInfo object of the container in the thingy that gets passed on. The interceptors can the extract whatever metadata about the container they want from that. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. What if two interceptors are interested in the same metadata? The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. Also, a stateless interceptor can be used for any container. If you want to just have tx's, you'd go find a tx-interceptor, and put it in the invocation chain. The interceptor will extract the metadata it needs about the container using the MBeanInfo, and do its work. If it is stateful, how will the interceptor get its metadata? I hope it won't load it itself... that would make it dependent on the type of object the interceptor chain is being used on (since it may be used on things that are not EJB containers). /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
- Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 8:55 AM Subject: Re: [JBoss-dev] Invocation and MethodInvocation The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. Also, a stateless interceptor can be used for any container. If you want to just have tx's, you'd go find a tx-interceptor, and put it in the invocation chain. The interceptor will extract the metadata it needs about the container using the MBeanInfo, and do its work. If it is stateful, how will the interceptor get its metadata? I hope it won't load it itself... that would make it dependent on the type of object the interceptor chain is being used on (since it may be used on things that are not EJB containers). This is the crux of this issue. Some interceptors are stateful and are tied to the type of container they are being used with. The EJB security model is completely different than the Web security model. All the security related interceptors due is translate from the container specific model to the generic JAAS implmentation in fact. I can force a container independent model on the interceptors that show up at the top-level, but internally, the security interceptor is going to have to determine how to enforce the container specific view. Its fine to support sharing of stateless interceptors, but to say this is the only way interceptors should be handled forces a refactoring of exising usage without sufficient justification. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
On 2001.11.15 11:55:18 -0500 Rickard Öberg wrote: David Jencks wrote: Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. Seems logical to put the MBeanInfo object of the container in the thingy that gets passed on. The interceptors can the extract whatever metadata about the container they want from that. If you pass the head of the chain with every invocation call, obviously the interceptor can extract whatever metadata it needs, compute whatever derived info is necessary, and use it. But if these computations take on the order of seconds, which is definitely a possibility and I think the case with the security proxy interceptor [NOT the security interceptor] (and the interceptor I have for rule engines), you need to precompute the derived info and save it somewhere in an initialization step. No matter which approach we use, this initialization step is necessary. I am saying that storing the results of the initialization in the interceptor makes more sense than putting it in an untyped map in the head of the chain. Doing this systematically also means you don't need to pass the head of the chain when you are traversing it with a method invocation. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. What if two interceptors are interested in the same metadata? They each store the info they are interested in. If its the same as another interceptor, who cares? The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. Also, a stateless interceptor can be used for any container. If you want to just have tx's, you'd go find a tx-interceptor, and put it in the invocation chain. The interceptor will extract the metadata it needs about the container using the MBeanInfo, and do its work. what I'm talking about can also be used for any container. The metadata extraction occurs during chain initialization. If it is stateful, how will the interceptor get its metadata? I hope it won't load it itself... that would make it dependent on the type of object the interceptor chain is being used on (since it may be used on things that are not EJB containers). Lets set up an example mbean code=org.jboss.system.InterceptorFactory name=JB:service=TxInterceptor attribute name=classorg.jboss.ejb.TxInterceptor/attribute mbean code=org.jboss.system.InterceptorFactory name=JB:service=SecurityInterceptor attribute name=classorg.jboss.ejb.SecurityInterceptor/attribute mbean code=org.jboss.system.InterceptorChainFactory name=JB:service=MyChain mbean-ref-list name=Interceptors mbean-ref-list-elementJB:service=TxInterceptor/mbean-ref-list-element mbean-ref-list-elementJB:service=SecurityInterceptor/mbean-ref-list-element /mbean-ref-list mbean code=org.jboss.ejb.Container name=JB:service=example mbean-ref name=InterceptorChainFactoryJB:service=MyChain/mbean-ref attribute name=EjbNamemyEjb/attribute /mbean when the mbeans are started up, the Container gets the metadata for the ejb, asks the InterceptorChainFactory for an interceptor chain containing new instances of the specified interceptors from the interceptor factories, and initializes (starts) it by sending itself or the metadata down the chain. Each interceptor extracts whatever info it needs from the metadata and saves it in the most convenient form in itself, in typed objects. Method invocations go down the chain, and the interceptor instances use their specially calculated info to do their job. Note that the InterceptorFactory mbeans can of course include additional attributes to further specialize the instances they create. david jencks /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: jars in sars ?
On Thu, 15 Nov 2001, David Jencks wrote: 3. (with jars separate, not in jetty.sar, just a plain jetty-service.xml) Remove the out of date jar, jetty-service.xml will suspend all its mbeans, redeploy new jar, jetty-service.xml will automatically redeploy all its mbeans. This is supposed to work now, although I haven't tested it extensively with the new mbean-refs in place. If you try and find it doesn't work PLEASE let me know. I think at the moment just copying a new jar over the old one doesn't work-- IMHO notifying to undeploy old version and redeploy new version is the job of the autodeployer, but I haven't had a chance to update it yet. It is also possible that you have to explicitly undeploy the old jar with the ServiceDeployer. For 2.4.3, I had a symlnk from the deploy folder, into my build directory, at the jar that is created. When I would update said jar, jboss would undeploy then redeploy automatically. I hope this feature hasn't gone away. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
Scott M Stark wrote: This is the crux of this issue. Some interceptors are stateful and are tied to the type of container they are being used with. The EJB security model is completely different than the Web security model. All the security related interceptors due is translate from the container specific model to the generic JAAS implmentation in fact. That is beside the point. If I have an MBean *wanting* the EJB security model, I'd like to be able to invoke it using the EJB interceptor, without the interceptor complaining about it. It shouldn't care what the end destination is, as long as the container can provide the right meta-data. I can force a container independent model on the interceptors that show up at the top-level, but internally, the security interceptor is going to have to determine how to enforce the container specific view. Its fine to support sharing of stateless interceptors, but to say this is the only way interceptors should be handled forces a refactoring of exising usage without sufficient justification. That is your opinion :-) /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation and MethodInvocation
|Seems logical to put the MBeanInfo object of the container in the thingy |that gets passed on. The interceptors can the extract whatever metadata |about the container they want from that. yes, I agree. |Also, a stateless interceptor can be used for any container. If you want well that would really be the point. Scripting the flow in the aspect sense becomes quite trivial and manageable. |to just have tx's, you'd go find a tx-interceptor, and put it in the |invocation chain. The interceptor will extract the metadata it needs |about the container using the MBeanInfo, and do its work. That is the beauty of it, also we can leverage the metadata talk of EJB to add transactional demarcation to flows... any flow, any object, same tags, as we agree there, just that is really powerful. No additional work whatsoever, aspect programming for the masses. |If it is stateful, how will the interceptor get its metadata? I hope it |won't load it itself... that would make it dependent on the type of |object the interceptor chain is being used on (since it may be used on |things that are not EJB containers). sure, the EJB container would not be real except for a metadata repository of MBeanInfo describing the context for the invocation pertaining to the EJB kind. David, as I said previously, I work by increment, step by step professor, step by step. Right now the design that Rickard did is the one that you are defending. i.e. the stack of interceptors per instance. I am ok with that. In my roadmap I actually don't intend to replace it so far. So even though we are advocating the more advanced view it would require more retooling, and I am worried about the amount of work there. I don't want to get all mighty on your asses since as I said I don't think I will implement this in the near future. But the vision of Turin's slave machines is a powerful one, we are so close to implementing it in JBoss, and everyone seems to be pushing this view almost without knowing, that something in me says do it... apart from the elegance I think it would be an extremelly flexible framework. But again, too much for now. Please drop it now, let's avoid empty discussions and focus on the task at hand. marcf | |/Rickard | |-- |Rickard Öberg | | |___ |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] RH: jars in sars ?
On 2001.11.15 12:29:23 -0500 Adam Heath wrote: On Thu, 15 Nov 2001, David Jencks wrote: 3. (with jars separate, not in jetty.sar, just a plain jetty-service.xml) Remove the out of date jar, jetty-service.xml will suspend all its mbeans, redeploy new jar, jetty-service.xml will automatically redeploy all its mbeans. This is supposed to work now, although I haven't tested it extensively with the new mbean-refs in place. If you try and find it doesn't work PLEASE let me know. I think at the moment just copying a new jar over the old one doesn't work-- IMHO notifying to undeploy old version and redeploy new version is the job of the autodeployer, but I haven't had a chance to update it yet. It is also possible that you have to explicitly undeploy the old jar with the ServiceDeployer. For 2.4.3, I had a symlnk from the deploy folder, into my build directory, at the jar that is created. When I would update said jar, jboss would undeploy then redeploy automatically. I hope this feature hasn't gone away. Still there for ejb-jars and ears and I presume wars. Probably not there for rars and sars/ non-ejb jars. Will be there soon I hope for everything. The responsibility for this undeploy-redeploy is IMHO currently in the wrong places, and I'm not done moving it. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Separating JMX/EJB
Sorry to chime in so late, but I have a few comments... Firstly, from Rickard. I intend to write a whitey on it some day too, but basically it goes something like this: * Meta-programming is good, but not inherent to EJB * The EJB programming model in general is flawed. (See EJB-INTEREST for lots of conflicting answers to common questions. If experts can't figure it out, how are mortals supposed to?!) Every programming model is flawed. The same thing is happening to EJB as did CORBA as it matures. These so-called experts you talk about get in there and beef up a rather simple specification to support all of their esoteric use cases. What these experts end up doing making these specifications more resitant to change and the industry ends up having to think of another programming model. I saw this crap when I was in the CORBA world. I agree with Marc. These experts are donkey-dick-sucking-monkeys that don't know their ass from their tinny winny pinuses.(Thanks for the humor Marc, I really needed it.) Nextly |Because..? |1) Bean A uses bean B. B dies, but C that implements the same interface |is still alive. Now what's A supposed to do? How will it be notified |that B is dead, and how is it supposed to find C? (with hardcoding these |dependencies in of course) Rickard you are talking of dependencies. The EJB spec defines dependencies in XML (soft) the proxies can implement failover, if you need notification (say to restart) you can be notified through many other frameworks including JMX and jini. Well, EJB's can't use Jini (can't hold on to a ServiceDiscoveryManager for example). If you want the proxies to do the failover, which would be entirely possible, you need to be able to let them point to many various instances of possibly different implementations. I guess the EJB interface/spec in itself would allow for this, but it would require quite a lof of the EJB container, as opposed to a rather simple hack in JMX/Jini. Actually, it would not require a lot of the container. Sacha Labourey and I have developed a pretty simple framework to provide fail-over and load-balancing for EJBs. Basically, we've integrated JavaGroups into this framework and will eventually see if JINI/JavaSpaces can fit in as well. Alright, you may have a point, but it's not really valid until it gets implemented *well*. Well, it is implemented. Go check it out. It's probably flawed, but it will do the job for now. |2) Bean A stores files in a particular directory. The name of the |directory changes. A needs to be alerted of this. How? Change the XML |file with environment settings and redeploy? Gee.. great... A notification of state change can be achieved by other means. A simple reset of context in most cases would do that. Rickard these are truly minor points that can be solved for the price of a callback on the bean. They are by no means show stoppers that invalidate the model (which really doesn't worry itself with these). We can do it simply in JBoss by offering an MBean in the EJB, you can certainly push for it in spec commitee (if you are in the commitee). Heck! require an MBean for the properties (pointers and what not), and you are done. So you'd need to go outside EJB for such a common requirement as runtime reconfiguration? Is that good? Sorry, but it's still bad. However, one of the key reasons why I don't like EJB, is because it's overused. People use it for things they shouldn't use it for, especially for web applications where the web client and EJB's are in the same JVM. And you still need to go through the remote interface, thus introducing a whole bunch of heavyweight patterns such as Data Transfer Objects. Why do people think that EJB's only purpose is for remoting? I think its great for defining transaction and security boundaries between interfaces and hiding the implementation of this from the programmer. The real power of EJB is in the packaging and deployment. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Invocation and MethodInvocation
David Jencks wrote: If you pass the head of the chain with every invocation call, obviously the interceptor can extract whatever metadata it needs, compute whatever derived info is necessary, and use it. But if these computations take on the order of seconds, which is definitely a possibility and I think the case with the security proxy interceptor [NOT the security interceptor] (and the interceptor I have for rule engines), you need to precompute the derived info and save it somewhere in an initialization step. No matter which approach we use, this initialization step is necessary. I am saying that storing the results of the initialization in the interceptor makes more sense than putting it in an untyped map in the head of the chain. Doing this systematically also means you don't need to pass the head of the chain when you are traversing it with a method invocation. This seems to have more to do with caching than the decision on where to keep the data. AFAICT there's no problem with caching the data in the interceptor (although you'd have to do it in a hashtable, with the end-point MBean name as key), to allow such initialization work to be done. As long as you can always re-get the data from the MBean, and that the MBean is really *in charge of* the state. Is the reason you want interceptors stateful only for performance? If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. What if two interceptors are interested in the same metadata? They each store the info they are interested in. If its the same as another interceptor, who cares? Well, *how do they get that info*?? As above, if two interceptors *cache* the data that is fine, because then they're not *in charge of* the data from an architectural/design point of view. It is then inherently shareable. If the metadata belongs to any of the interceptors, then somewhere there needs to be knowledge about what interceptor needs what metadata so that they can be provided this. In the stateless model they are themselves responsible for accessing whatever they need from the container (or whatever the end-point is), thus encapsulating the knowledge of that need. Also, a stateless interceptor can be used for any container. If you want to just have tx's, you'd go find a tx-interceptor, and put it in the invocation chain. The interceptor will extract the metadata it needs about the container using the MBeanInfo, and do its work. what I'm talking about can also be used for any container. The metadata extraction occurs during chain initialization. What you mean is that during chain init a particular instance is being created for that chain. Right? What I'm saying is that interceptors exist independently of these chains, i.e. they may exist before any chains exist, it's just that without a chain they are never invoked. When the chains are created particular interceptors are chosen for that chain, and then used. Those interceptors may however be part of other chains acting concurrently. mbean code=org.jboss.system.InterceptorFactory name=JB:service=TxInterceptor attribute name=classorg.jboss.ejb.TxInterceptor/attribute mbean code=org.jboss.system.InterceptorFactory name=JB:service=SecurityInterceptor attribute name=classorg.jboss.ejb.SecurityInterceptor/attribute mbean code=org.jboss.system.InterceptorChainFactory name=JB:service=MyChain mbean-ref-list name=Interceptors mbean-ref-list-elementJB:service=TxInterceptor/mbean-ref-list-element mbean-ref-list-elementJB:service=SecurityInterceptor/mbean-ref-list-element /mbean-ref-list mbean code=org.jboss.ejb.Container name=JB:service=example mbean-ref name=InterceptorChainFactoryJB:service=MyChain/mbean-ref attribute name=EjbNamemyEjb/attribute /mbean snip Excellent! Nothing like an example to clarify things. Here's mine: mbean code=org.jboss.ejb.TxInterceptor name=JB:service=TxInterceptor attribute name=transactionManagerjava:/MyTM/attribute /mbean mbean code=org.jboss.ejb.SecurityInterceptor name=JB:service=SecurityInterceptor attribute name=realmMyCompanyRealm/attribute /mbean mbean code=org.jboss.system.InterceptorChainFactory name=JB:service=MyChain mbean-ref-list name=Interceptors mbean-ref-list-element JB:service=TxInterceptor /mbean-ref-list-element mbean-ref-list-element JB:service=SecurityInterceptor /mbean-ref-list-element /mbean-ref-list /mbean mbean code=org.jboss.ejb.Container name=JB:service=example mbean-ref name=InterceptorChainFactory JB:service=MyChain /mbean-ref attribute name=EjbNamemyEjb/attribute /mbean -- The interceptors are MBeans, and thus
RE: [JBoss-dev] Invocation and MethodInvocation
|Its fine to support sharing of stateless interceptors, but to say this is |the only |way interceptors should be handled forces a refactoring of exising usage |without sufficient justification. Neither Rickard nor I are saying this. We are saying, gosh, most interceptors are generic (including the ones you are describing, it would just mean that some come specific to the bean, big deal, we don't preclude it), then let's factor them in a clean way we we can talk to them independenly through the JMX bus and thus offer trivial scripting of flows (you want to add transaction behaviour to an assembly, you can). There can be as many mbeans as there are security types. Even one per container, it is irrelevant but at least that metadata would be dynamically updatable (defeating one of the points rickard makes about ejb). Look for the umpth time, we are talking of code that won't materialize in the next coming weeks. I will go with the lindfors/oberg initial description of the stack, which is just what we have with some more flexibility in the loading of configurations. Ineed toturnoffthisemail station : - ) marcf | | | |___ |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] CVS update: manual/src/xdocs/howto howtoclustering.xml
Well sorry David... I will remove this from the howto. We *will* write this doco but it is still not in it. In the meantime: - either you come in Switzerland and I pay you for $10 of beer/milk/... - I answer your questions ;) Cheers, Sacha -Message d'origine- De : David Jencks [mailto:[EMAIL PROTECTED]] Envoyé : jeudi, 15 novembre 2001 19:05 À : Sacha Labourey Cc : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml I'm a little confused. This indicates that more extensive documentation is in the main documentation, which I assumed meant the for pay doco, so I went and bought the only one I could find ($9.99, JBossDocs.zip) However, I can't find any mention of clustering in it. What am I missing? Thanks david jencks On 2001.11.15 08:50:45 -0500 Sacha Labourey wrote: User: slaboure Date: 01/11/15 05:50:45 Added: src/xdocs/howto howtoclustering.xml Log: Added quick and simple clustering howto Revision ChangesPath 1.1 manual/src/xdocs/howto/howtoclustering.xml Index: howtoclustering.xml === section id=clustering lang=en titleClustering in JBoss 3.0 alpha/title paraAuthors: author firstnameSacha/firstname surnameLabourey/surname /author email[EMAIL PROTECTED]/email author firstnameBill/firstname surnameBurke/surname /author email[EMAIL PROTECTED]/email /para section titleIntroduction/title section titleWhat this article is about/title paraThis document introduces basic clustering setup for Entity Beans, Stateful Session Beans and Stateless Session Beans. More advanced documentation is available in the main documentation (book)./para paraClustering should be considered in alpha state. Feedback is highly welcome./para paraClustering is built on top of the ulink url = http://www.javagroups.com/;JavaGroups/ulink framework and requires JDK 1.3.x./para paraIn order to create a cluster of JBoss nodes, you simply need to launch several JBoss (with clustering activated, see below) instances on different hosts. JBoss instances will automatically detect their neighbors and form a cluster./para /section /section section titleGeneral setup/title section paraClustering features are available in the pre 3.0 sources. First get the latest sources from CVS or download one of the sources daily snapshot. You then need to build JBoss server (run jboss-all/build/build.bat or jboss-all/build/build.sh). For more information read this xref linkend=intro.examples.source/. /para paraThe resulting JBoss server can be found in jboss-all/build/output/jboss-3.0.0alpha./para paraTo activate global clustering support, you need to copy the file jboss-all/cluster/etc/cluster-service.xml in the /deploy directory of your newly built JBoss server. Clustering is now activated in your JBoss server./para /section /section section titleStateless Session Beans/title section paraTo make a Stateless Session Bean (SLSB) active in a cluster, you need to modify its deployment settings in jboss.xml:/para paraprogramlisting![CDATA[ jboss enterprise-beans session ejb-namenextgen.StatelessSession/ejb-name jndi-namenextget.StatelessSession/jndi-name clusteredTrue/clustered /session /enterprise-beans /jboss ]]/programlisting/para paraThus, you simply need to add the lt;clusteredgt; tag to your existing jboss.xml configuration file./para /section /section section titleStateful Session Beans/title section paraTo make a Stateful Session Bean (SFSB) active in a cluster, you need to modify its deployment settings in jboss.xml:/para paraprogramlisting![CDATA[ jboss enterprise-beans session ejb-namenextgen.StatefulSession/ejb-name jndi-namenextget.StatefulSession/jndi-name clusteredTrue/clustered /session /enterprise-beans /jboss ]]/programlisting/para paraThus, like for SLSB, you simply need to
[JBoss-dev] [ jboss-Change Notes-482188 ] JBoss Farm Service
Change Notes item #482188, was opened at 2001-11-15 09:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=482188group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Andreas Schaefer (schaefera) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss Farm Service Initial Comment: I added a new farm service allowing to create a set of computers with a set of common services. The boxes run JBoss on their own in contrast to a cluster. The farm is set up by deploying the farm-service.xml on each node participating in the farm. Then the user can deploy any service (service.xml or SAR file) on the /deploy/farm directory and it is deployed on each node of the farm (which means the files also appears on the /deploy/farm directory of each node. Now when a file is removed form /deploy/farm it will also be removed from any other node. Have fun - Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=482188group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml
User: slaboure Date: 01/11/15 10:07:09 Modified:src/xdocs/howto howtoclustering.xml Log: David has lost $9.99. ;) Revision ChangesPath 1.2 +19 -19manual/src/xdocs/howto/howtoclustering.xml Index: howtoclustering.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtoclustering.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- howtoclustering.xml 2001/11/15 13:50:45 1.1 +++ howtoclustering.xml 2001/11/15 18:07:09 1.2 @@ -1,24 +1,24 @@ -section id=clustering lang=en - titleClustering in JBoss 3.0 alpha/title +section id=clustering lang=en + titleClustering in JBoss 3.0 alpha/title paraAuthors: author firstnameSacha/firstname surnameLabourey/surname - /author - email[EMAIL PROTECTED]/email + /author + email[EMAIL PROTECTED]/email author firstnameBill/firstname surnameBurke/surname /author - email[EMAIL PROTECTED]/email - /para + email[EMAIL PROTECTED]/email + /para section - titleIntroduction/title + titleIntroduction/title section - titleWhat this article is about/title - paraThis document introduces basic clustering setup for Entity Beans, Stateful Session Beans and Stateless Session Beans. More advanced documentation is available in the main documentation (book)./para - paraClustering should be considered in alpha state. Feedback is highly welcome./para + titleWhat this article is about/title + paraThis document introduces basic clustering setup for Entity Beans, Stateful Session Beans and Stateless Session Beans. More advanced documentation will soon be available./para + paraClustering should be considered in alpha state. Feedback is highly welcome./para paraClustering is built on top of the ulink url = http://www.javagroups.com/;JavaGroups/ulink framework and requires JDK 1.3.x./para paraIn order to create a cluster of JBoss nodes, you simply need to launch several JBoss (with clustering activated, see below) instances on different hosts. JBoss instances will automatically detect their neighbors and form a cluster./para /section @@ -30,8 +30,8 @@ paraClustering features are available in the pre 3.0 sources. First get the latest sources from CVS or download one of the sources daily snapshot. You then need to build JBoss server (run jboss-all/build/build.bat or jboss-all/build/build.sh). For more information read this xref linkend=intro.examples.source/. /para paraThe resulting JBoss server can be found in jboss-all/build/output/jboss-3.0.0alpha./para paraTo activate global clustering support, you need to copy the file jboss-all/cluster/etc/cluster-service.xml in the /deploy directory of your newly built JBoss server. Clustering is now activated in your JBoss server./para - /section - /section + /section + /section section titleStateless Session Beans/title @@ -49,8 +49,8 @@ /jboss ]]/programlisting/para paraThus, you simply need to add the lt;clusteredgt; tag to your existing jboss.xml configuration file./para - /section - /section + /section + /section section titleStateful Session Beans/title @@ -68,8 +68,8 @@ /jboss ]]/programlisting/para paraThus, like for SLSB, you simply need to add the lt;clusteredgt; tag to your existing jboss.xml configuration file. By default, bean state is replicated in-memory in sub-groups of two nodes./para - /section - /section + /section + /section section titleEntity Beans/title @@ -89,8 +89,8 @@ paraThus, like for SLSB and SFSB, you simply need to add the lt;clusteredgt; tag to your existing jboss.xml configuration file. By default, bean state is replicated in-memory in sub-groups of two nodes./para paraAs Entity Beans clustering in JBoss is based on pessimistic locking at the database level, your database must support SQL instruction like
[JBoss-dev] CVS update: newsite/src/docs/developers cvs.jsp
User: user57 Date: 01/11/15 10:24:58 Modified:src/docs/developers cvs.jsp Log: missed this Revision ChangesPath 1.7 +0 -5 newsite/src/docs/developers/cvs.jsp Index: cvs.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/cvs.jsp,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- cvs.jsp 2001/11/15 05:35:15 1.6 +++ cvs.jsp 2001/11/15 18:24:58 1.7 @@ -123,11 +123,6 @@ /ul /p - p class=text - The build system is currently being stabilized, but has changed - since the writting of this user's guide document. - /p - p class=headWHAT IS CVS (Concurrent Versions System) ?/p p class=text ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
Why are you splitting it up at all? I guess I can see why you would want to split up thirdparty stuff, perhaps even client stuff... but there is no reason (or desire) to have the rest split up on a cvs module basis (or generated jar basis). To make things more cpmlicated for you, jboss will want to have its thirdparty jars installed into lib/ext, which seems like it will complicate the process of splitting those up into packages. I played with debian for some time (once I could get the damn thing installed... or rather once someone told me not to use the custom mode so the installer would not ask me a billon questions). I thought apt was nice, though to upgrade to woody, I had to keep running apt-get over and over and over and over... finally it worked. So, I did not write this to knock debian or there package system, but more to find out the motivation to make the package and why you inist on this level of seperation. I would expect a jboss-system and jboss-client as core packages, then put the extra plugins (from jboss-plugins) like the iiop and such into there own. There is no reason the split up the jboss-system package into smaller bits (like a jboss-naming or jboss-j2ee packages) because they are completly useless out of the context of the supporting modules. Modules are not realeased individialy, but as a whole. They do not have there own versioning, they use the versioning from the cvs project from which they are a member. I know this is hard to understand based on the currect pyhsical cvs layout. Perhaps we can fix that once 3.0 has been moved to production, perhaps 3.2 as well. Why not simply make a .deb from the archives released to sf.net? If the point is to generate a .deb that is the easiest thing todo, which will also have the least amount of maintenece required by you (or another) when building an updated package. I am not against building .debs, .rpms or whatever, but we need to keep them uptodate with the current releases. we need to make sure the packaging suites the needs of our users (not the ultra-purist package system designers). And we need to make sure it is easy to maintain the package generation. Ideally an optional target of the build/build.xml for the given project should make packages, so you, me, scott or anyone could generate them... and not have to know the details of the packaging system. I will respond to your other email when I get into work. Could you explain (in a brief-like manner), your motivation to split up everything in jboss at the cvs module level? --jason On Thu, 15 Nov 2001, Adam Heath wrote: On Thu, 15 Nov 2001, David Jencks wrote: Out of curiousity, where does connector (jbosscx) fit into your packaging scheme? For 3.0 you might consider putting the contents of pool and connector into one package (if they aren't already) as pool is now small and only used by jbosscx. The stuff I did for 2.4 was done based on jar names. If it was a separate jar, I split it off. This is obviously not the correct way to do it. It should be split based on the functionality. I'm still learning about all the different functionality parts of jboss, and how they relate. Previously, I had just downloaded jboss-tomcat, and ran it. ___ 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] Separating JMX/EJB
-Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 1:11 PM To: Bill Burke; Rickard Öberg Cc: Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] Separating JMX/EJB can'tturn off the freaking email. |The real power |of EJB is in the packaging and deployment. you on dope? Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. Bill marcf | |Bill | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Separating JMX/EJB
Maybe I'll just shut up before I make (more of) a fool of myself. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, November 15, 2001 1:11 PM To: Bill Burke; Rickard Öberg Cc: Jboss-Development@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] Separating JMX/EJB can'tturn off the freaking email. |The real power |of EJB is in the packaging and deployment. you on dope? marcf | |Bill | | ___ 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] Invocation and MethodInvocation
marc fleury wrote: I was planning on putting a reference to the container ie. the repository of chain configuration, IN the invocation itself. You then have a self describing invocation. The rugged interceptor can then come and say alright little fella, give me the tx tag you want big schme! 2 links instead of one, and no lookup in there. Good. again abstract the end-point into a chain it is a different beast where the identity is the sum of mbeans, that container is really the repository of the path for a given logical type of flow. EJB has little reality in this approach, it only exists as a temporary list of interceptors and plugins. Alright, I'm cool with that. BTW, this notion is extremely similar to some meta-physics theories, which I find to be very amusing. :-) Funny how real-life concepts tends to finds its way into programming. I also think the real problem is in the nature of this beast, too disruptive a view. I am ok with dealing with it, but I think that for most people the real interceptor chain is reassuring also as in its first incarnation, I doubt it will bring more functionality, you will find resistence in the brains to let go and really go with this detyped/stateless/dynamic/shared flow system view of the world. It is fundamentally a SYSTEM view, really what JBoss is all about these days. Where there was a reassuring container we now have a new beast, lightweight and dynamic with very little reality. Yeah, now we're talking! It is always frightening to let go of adopted beliefs, but boy is the rush worth it ;-) Maybe for JBoss 4 then... I think that an application such as a rule engine dynamically scripting the flow of invocation *graphically* where you can see your flow, will be a proof, but we really are far from that at this point. So for the 4th time today, let's try to keep the religiousness of this discussion in a pure academic world, since I won't code it this week. I would really like to code for the rest of the day... can I go ? You're excused. Go code. I'm glad you got the above though. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Separating JMX/EJB
Bill Burke wrote: Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. While the packaging is cool, IMHO it's more of a practical detail than a real advancement. To me, personally, it's all about the meta-programming and dynamicity of building large constructs from small blocks, which is enabled by having simple blocks that fit together like lego. JBoss is like lego. In many forms and different shapes, sizes and colors, but at the same time it's all the same. It's a nice illusion though. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml
On 2001.11.15 13:04:48 -0500 Sacha Labourey wrote: Well sorry David... I will remove this from the howto. We *will* write this doco but it is still not in it. In the meantime: - either you come in Switzerland and I pay you for $10 of beer/milk/... - I answer your questions ;) Well, switzerland is pretty nice but maybe not this week;-) Basically I'm trying to figure out if I can fix what I broke. Did you try the second set of files I sent? On my machine, they start up fine with no exception. I've tried the jnditester modified with my 2 ip addresses, and get javax.naming.CommunicationException: Could not obtain connection to any of these urls: 192.168.0.3:1100,192.168.0.1:1100 at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:795) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:349) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:342) at javax.naming.InitialContext.lookup(InitialContext.java:350) at jnditester.main(jnditester.java:30) both on my modified copy and on a jboss-3 version without any of my mbean-ref stuff (i.e. before I broke anything). I'm not sure where to look. Thanks david jencks Cheers, Sacha -Message d'origine- De : David Jencks [mailto:[EMAIL PROTECTED]] Envoyé : jeudi, 15 novembre 2001 19:05 À : Sacha Labourey Cc : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml I'm a little confused. This indicates that more extensive documentation is in the main documentation, which I assumed meant the for pay doco, so I went and bought the only one I could find ($9.99, JBossDocs.zip) However, I can't find any mention of clustering in it. What am I missing? Thanks david jencks On 2001.11.15 08:50:45 -0500 Sacha Labourey wrote: User: slaboure Date: 01/11/15 05:50:45 Added: src/xdocs/howto howtoclustering.xml Log: Added quick and simple clustering howto Revision ChangesPath 1.1 manual/src/xdocs/howto/howtoclustering.xml Index: howtoclustering.xml === section id=clustering lang=en titleClustering in JBoss 3.0 alpha/title paraAuthors: author firstnameSacha/firstname surnameLabourey/surname /author email[EMAIL PROTECTED]/email author firstnameBill/firstname surnameBurke/surname /author email[EMAIL PROTECTED]/email /para section titleIntroduction/title section titleWhat this article is about/title paraThis document introduces basic clustering setup for Entity Beans, Stateful Session Beans and Stateless Session Beans. More advanced documentation is available in the main documentation (book)./para paraClustering should be considered in alpha state. Feedback is highly welcome./para paraClustering is built on top of the ulink url = http://www.javagroups.com/;JavaGroups/ulink framework and requires JDK 1.3.x./para paraIn order to create a cluster of JBoss nodes, you simply need to launch several JBoss (with clustering activated, see below) instances on different hosts. JBoss instances will automatically detect their neighbors and form a cluster./para /section /section section titleGeneral setup/title section paraClustering features are available in the pre 3.0 sources. First get the latest sources from CVS or download one of the sources daily snapshot. You then need to build JBoss server (run jboss-all/build/build.bat or jboss-all/build/build.sh). For more information read this xref linkend=intro.examples.source/. /para paraThe resulting JBoss server can be found in jboss-all/build/output/jboss-3.0.0alpha./para paraTo activate global clustering support, you need to copy the file jboss-all/cluster/etc/cluster-service.xml in the /deploy directory of your newly built JBoss server. Clustering is now activated in your JBoss server./para /section /section section titleStateless Session Beans/title section paraTo make a Stateless Session Bean (SLSB) active in a cluster, you need
Re: [JBoss-dev] Separating JMX/EJB
Rickard Oberg wrote: Bill Burke wrote: Nope. I guess when you come from the CORBA world to EJB, everything looks powerful. The packaging, (jars, wars, ears, and with jboss, sars) is just not available in the CORBA world. That's what its all about man. Packaging, integration, configuration, and deployment. All these new frameworks year after year think they're the coolest and that they're solving all these new cool problems. When in reality they solve the same problems the last latest/greatest framework did, except, usually, the packaging, integration, configuration and deployment get more seemless. While the packaging is cool, IMHO it's more of a practical detail than a real advancement. practical details are very important in the traditional IT world. Most developers are nowhere near as dedicated and talented as those who've been taking part in this conversation. To me, personally, it's all about the meta-programming and dynamicity of building large constructs from small blocks, which is enabled by having simple blocks that fit together like lego. JBoss is like lego. In many forms and different shapes, sizes and colors, but at the same time it's all the same. It's a nice illusion though. Very cool, indeed. But don't knock practicality 8^}) -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml
On 2001.11.15 14:16:37 -0500 Bill Burke wrote: Shit David, I really need to make some time to help you out. It's my crappy code anyways. Have you modified the files you've sent me? Nope, still trying to figure out what's going on. I'm working on a couple of other things too. Should I be able to deploy clustered ejb's without the HAJNDI apparently working? Is the deal that I deploy on one server and can see them deployed on the other? Do they get bound into normal jndi so I can see them in jndiview? Does jndiview show whats in HAJNDI? Thanks! david -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Thursday, November 15, 2001 2:02 PM To: Sacha Labourey Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml On 2001.11.15 13:04:48 -0500 Sacha Labourey wrote: Well sorry David... I will remove this from the howto. We *will* write this doco but it is still not in it. In the meantime: - either you come in Switzerland and I pay you for $10 of beer/milk/... - I answer your questions ;) Well, switzerland is pretty nice but maybe not this week;-) Basically I'm trying to figure out if I can fix what I broke. Did you try the second set of files I sent? On my machine, they start up fine with no exception. I've tried the jnditester modified with my 2 ip addresses, and get javax.naming.CommunicationException: Could not obtain connection to any of these urls: 192.168.0.3:1100,192.168.0.1:1100 at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:795) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:349) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:342) at javax.naming.InitialContext.lookup(InitialContext.java:350) at jnditester.main(jnditester.java:30) both on my modified copy and on a jboss-3 version without any of my mbean-ref stuff (i.e. before I broke anything). I'm not sure where to look. Thanks david jencks Cheers, Sacha -Message d'origine- De : David Jencks [mailto:[EMAIL PROTECTED]] Envoyé : jeudi, 15 novembre 2001 19:05 À : Sacha Labourey Cc : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml I'm a little confused. This indicates that more extensive documentation is in the main documentation, which I assumed meant the for pay doco, so I went and bought the only one I could find ($9.99, JBossDocs.zip) However, I can't find any mention of clustering in it. What am I missing? Thanks david jencks On 2001.11.15 08:50:45 -0500 Sacha Labourey wrote: User: slaboure Date: 01/11/15 05:50:45 Added: src/xdocs/howto howtoclustering.xml Log: Added quick and simple clustering howto Revision ChangesPath 1.1 manual/src/xdocs/howto/howtoclustering.xml Index: howtoclustering.xml === section id=clustering lang=en titleClustering in JBoss 3.0 alpha/title paraAuthors: author firstnameSacha/firstname surnameLabourey/surname /author email[EMAIL PROTECTED]/email author firstnameBill/firstname surnameBurke/surname /author email[EMAIL PROTECTED]/email /para section titleIntroduction/title section titleWhat this article is about/title paraThis document introduces basic clustering setup for Entity Beans, Stateful Session Beans and Stateless Session Beans. More advanced documentation is available in the main documentation (book)./para paraClustering should be considered in alpha state. Feedback is highly welcome./para paraClustering is built on top of the ulink url = http://www.javagroups.com/;JavaGroups/ulink framework and requires JDK 1.3.x./para paraIn order to create a cluster of JBoss nodes, you simply need to launch several JBoss (with clustering activated, see below) instances on different hosts. JBoss instances will automatically detect their neighbors and form a cluster./para /section /section section titleGeneral setup/title section paraClustering features are available in
Re: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, Jason Dillon wrote: Why are you splitting it up at all? I guess I can see why you would want to split up thirdparty stuff, perhaps even client stuff... but there is no reason (or desire) to have the rest split up on a cvs module basis (or generated jar basis). I am going to split it up along lines that make sense in jboss development. I don't know what lines yet make sense, so it remains to be seen how it ends up. To make things more cpmlicated for you, jboss will want to have its thirdparty jars installed into lib/ext, which seems like it will complicate the process of splitting those up into packages. Not a problem. The jars in the other debs will reside in /usr/share/java, so I can just make symlinks to them. This allows for code reuse, reduced disk usage, reduced download size, etc. I played with debian for some time (once I could get the damn thing installed... or rather once someone told me not to use the custom mode so the installer would not ask me a billon questions). The current installing in debian stable(potato) is difficult for those not familiar with it. testing(woody) is not much better, but is somewhat. The next version of debian after testing will be much better, but that installer is no where near usable. I thought apt was nice, though to upgrade to woody, I had to keep running apt-get over and over and over and over... finally it worked. Sometimes these are bugs in the packages. The maintainers didn't do full upgrade testing. Other times, they are bugs in dpkg(which apt calls) itself. Lots of these bugs have been fixed in dpkg(segfaults, buffer overruns, even speedups) for testing/woody. So, I did not write this to knock debian or there package system, but more to find out the motivation to make the package and why you inist on this level of seperation. We could argue which OS is better than which other OS all day. I don't think it has any bearing on this discussion. The actual layout of the files depends on the distribution, but the logical separation doesn't. I would expect a jboss-system and jboss-client as core packages, then put the extra plugins (from jboss-plugins) like the iiop and such into there own. For example, I have jnp-server.deb and jboss-server.deb(for 2.4.3). Both contain jnpserver.jar. You can not have both installed at the same time, as they both run a JNDI daemon. I did this for those who might only want a JNDI daemon on a node. For each separate deb(that makes sense to have a separate deb) that also has a -client.jar, I make a separate -client.deb. Again, for 3.0, I am not sure how things are going to be split yet. Even for 2.4.3, I did the splitting based on jar name, and not on the services each provided. There is no reason the split up the jboss-system package into smaller bits (like a jboss-naming or jboss-j2ee packages) because they are completly useless out of the context of the supporting modules. If other packages in Debian only depend on a 'j2ee' package, and there could be several packages that provide a 'j2ee' package, then jboss-j2ee should be split. But that is something that doesn't really affect the jboss community. Modules are not realeased individialy, but as a whole. They do not have there own versioning, they use the versioning from the cvs project from which they are a member. I know this is hard to understand based on the currect pyhsical cvs layout. Perhaps we can fix that once 3.0 has been moved to production, perhaps 3.2 as well. That's not a problem. There will be a single jboss source packages, that produces multiple debs, each with the same version. Why not simply make a .deb from the archives released to sf.net? If the point is to generate a .deb that is the easiest thing todo, which will also have the least amount of maintenece required by you (or another) when building an updated package. That's what I did for my first version of 2.4.3 debs. I then split it into multiple. I am not against building .debs, .rpms or whatever, but we need to keep them uptodate with the current releases. we need to make sure the packaging suites the needs of our users (not the ultra-purist package system designers). And we need to make sure it is easy to maintain the package generation. Ideally an optional target of the build/build.xml for the given project should make packages, so you, me, scott or anyone could generate them... and not have to know the details of the packaging system. Debian packaging works by creating a debian directory off the top, and having text files, make files, shell scripts, etc describe what has to be done. There is a very defined api to the main entry point, debian/rules(chmod +x, generally a make file), so make hooking into external systems easy. I will respond to your other email when I get into work. Could you explain (in a brief-like manner), your motivation to split up everything in jboss at the cvs module level? I
Re: [JBoss-dev] Invocation and MethodInvocation
snip I think that an application such as a rule engine dynamically scripting the flow of invocation *graphically* where you can see your flow, will be a proof, but we really are far from that at this point. (Oh yeah? how far?) OK, this is the one capability the one interceptor approach has that the factory approach doesn't. Do you have an example where this is useful? So for the 4th time today, let's try to keep the religiousness of this discussion in a pure academic world, since I won't code it this week. I would really like to code for the rest of the day... can I go ? But what will we do???;-) david marcf | |/Rickard | |-- |Rickard Öberg | | | |___ |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] CVS update: manual/src/xdocs/howto howtoclustering.xml
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Thursday, November 15, 2001 2:18 PM To: Bill Burke Cc: Sacha Labourey; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml On 2001.11.15 14:16:37 -0500 Bill Burke wrote: Shit David, I really need to make some time to help you out. It's my crappy code anyways. Have you modified the files you've sent me? Nope, still trying to figure out what's going on. I'm working on a couple of other things too. Should I be able to deploy clustered ejb's without the HAJNDI apparently working? Is the deal that I deploy on one server and can see them deployed on the other? Do they get bound into normal jndi so I can see them in jndiview? Does jndiview show whats in HAJNDI? HA-JNDI is not a required service. HA-JNDI delegates to local jndi if it can't find a reference. EJBs are only bound to local JNDI. You must deploy an ejb on every node in the cluster right now. The Farm stuff may help out or net boot here. Bill Thanks! david -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Thursday, November 15, 2001 2:02 PM To: Sacha Labourey Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml On 2001.11.15 13:04:48 -0500 Sacha Labourey wrote: Well sorry David... I will remove this from the howto. We *will* write this doco but it is still not in it. In the meantime: - either you come in Switzerland and I pay you for $10 of beer/milk/... - I answer your questions ;) Well, switzerland is pretty nice but maybe not this week;-) Basically I'm trying to figure out if I can fix what I broke. Did you try the second set of files I sent? On my machine, they start up fine with no exception. I've tried the jnditester modified with my 2 ip addresses, and get javax.naming.CommunicationException: Could not obtain connection to any of these urls: 192.168.0.3:1100,192.168.0.1:1100 at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:795) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:349) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:342) at javax.naming.InitialContext.lookup(InitialContext.java:350) at jnditester.main(jnditester.java:30) both on my modified copy and on a jboss-3 version without any of my mbean-ref stuff (i.e. before I broke anything). I'm not sure where to look. Thanks david jencks Cheers, Sacha -Message d'origine- De : David Jencks [mailto:[EMAIL PROTECTED]] Envoyé : jeudi, 15 novembre 2001 19:05 À : Sacha Labourey Cc : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] CVS update: manual/src/xdocs/howto howtoclustering.xml I'm a little confused. This indicates that more extensive documentation is in the main documentation, which I assumed meant the for pay doco, so I went and bought the only one I could find ($9.99, JBossDocs.zip) However, I can't find any mention of clustering in it. What am I missing? Thanks david jencks On 2001.11.15 08:50:45 -0500 Sacha Labourey wrote: User: slaboure Date: 01/11/15 05:50:45 Added: src/xdocs/howto howtoclustering.xml Log: Added quick and simple clustering howto Revision ChangesPath 1.1 manual/src/xdocs/howto/howtoclustering.xml Index: howtoclustering.xml === section id=clustering lang=en titleClustering in JBoss 3.0 alpha/title paraAuthors: author firstnameSacha/firstname surnameLabourey/surname /author email[EMAIL PROTECTED]/email author firstnameBill/firstname surnameBurke/surname /author email[EMAIL PROTECTED]/email /para section titleIntroduction/title section titleWhat this article is about/title paraThis document introduces basic clustering setup for Entity Beans, Stateful Session Beans and Stateless Session Beans. More advanced documentation is available in the main documentation (book)./para paraClustering should be considered in alpha state. Feedback is highly welcome./para paraClustering is built
[JBoss-dev] JSR-77: Management Services
Hi Geeks As you maybe know JSR-77 defines a vendor-neutral way to manage J2EE application server. JSR-77 works like JMX except that it uses only a few data types (basic data types, String and Stats (statistic data containers)). The rest are links to other managed objects. Thus you can navigate through the app. server following the links until you get the information you need (something like when you surf through the net). Right now the MEJB (mantatory EJB to enable a JSR-77 client to access and work with the app. server) is available but empty. Therefore I would suggest the following implementation of the JSR-77 spec.: - MEJB maps JSR-77 links to the JSR-77 MBeans - JSR-77 MBeans are the bridge between JSR-77 spec. and the JBoss implementation - JSR-77 MBean represents a ManagedObject which make the mapping JSR-77 -- JBoss pretty easy - Each JBoss service is reponsible to create the appropriate JSR-77 MBeans and to provide the information to link it with its parents whereas the JSR-77 MBean know how to create the links I dropped the idea of a controller getting the information from the services and creating the JSR-77 MBeans. The service MBean has the appropriate knowledge to create the JSR-77 MBean and thus make the controller superfluous. As time permits I will start make the first implementation to show what this means code-wise. Feedback ? x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
Why are you splitting it up at all? I guess I can see why you would want to split up thirdparty stuff, perhaps even client stuff... but there is no reason (or desire) to have the rest split up on a cvs module basis (or generated jar basis). I am going to split it up along lines that make sense in jboss development. I don't know what lines yet make sense, so it remains to be seen how it ends up. If this is the case, then you will probably want to build off of jboss-all, since that it was most/all developers use. To make things more cpmlicated for you, jboss will want to have its thirdparty jars installed into lib/ext, which seems like it will complicate the process of splitting those up into packages. Not a problem. The jars in the other debs will reside in /usr/share/java, so I can just make symlinks to them. This allows for code reuse, reduced disk usage, reduced download size, etc. Hopefully the installed .jars will have some version number seperation (like jaxp v1.0.1 vs jaxp v1.1) otherwise you will end up with version incompatiblities. Also, you will be signing yourself up to maintain these, if there is not a active reliable maintainer for them already. For example, I have jnp-server.deb and jboss-server.deb(for 2.4.3). Both contain jnpserver.jar. You can not have both installed at the same time, as they both run a JNDI daemon. I did this for those who might only want a JNDI daemon on a node. This seperation does not make sence for 3.0. If you want to run a JNDI server on a node, you will need the rest of the server components to get it running, then simply modify the config to only run the required components for the JNDI service. For each separate deb(that makes sense to have a separate deb) that also has a -client.jar, I make a separate -client.deb. Again, for 3.0, I am not sure how things are going to be split yet. Even for 2.4.3, I did the splitting based on jar name, and not on the services each provided. Fine. A bit overkill, but fine. There is no reason the split up the jboss-system package into smaller bits (like a jboss-naming or jboss-j2ee packages) because they are completly useless out of the context of the supporting modules. If other packages in Debian only depend on a 'j2ee' package, and there could be several packages that provide a 'j2ee' package, then jboss-j2ee should be split. But that is something that doesn't really affect the jboss community. No other Debian package will depend ong jboss-j2ee... or rather no other package should depend on jboss-j2ee. If a package is dependent on jboss it should depend on the entire jboss package or the client package (or appropriant client package as you slice them up). Why not simply make a .deb from the archives released to sf.net? If the point is to generate a .deb that is the easiest thing todo, which will also have the least amount of maintenece required by you (or another) when building an updated package. That's what I did for my first version of 2.4.3 debs. I then split it into multiple. What do you gain from splitting them up? I will respond to your other email when I get into work. Could you explain (in a brief-like manner), your motivation to split up everything in jboss at the cvs module level? I assume that each separate cvs module wholy contains a separate service. I am not sure if this is correct, as I only checked out 3.0 yesterday, and there are no docs to read(either about building, or general features) available on the web for me to read. Each cvs module is a *rough* seperation of different functionality insided of JBoss. Each cvs module contains zero or more services, utilies and other functional bits which together make up the JBoss distribution as a whole (from jboss-all at least). There are other projects (like jboss-plugins) which may need to be split up by a service by service basis, but the core should not. I could see that it might be easy to build packages out of one cvs module (client, doc whatever packages too), but I don't see how that buys anything for either the developer or users standpoint. A user will want to run the server or will want to access client libraries to connect to the server... that is about it. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] can't build jboss from cvs
I will start working on this today. I assume this is more important than the NNTP stuff I need to finish up? --jason On Thu, 15 Nov 2001, marc fleury wrote: Adam, while the tone is really not appropriate (only I get to bang on Jason like that), I agree that BM can be frustrating. It is however functional and powerful, we do need a simple file describing this is how to build. Right now the BM paper is way too complex, I am not sure we need to understand how bm works, just how to build the files. That readme is missing and it can frustrate newbie developers like you but really Jason we do need a README-BUILD file at the top of the directory something that says. Go to build/, type sh build.sh or build.bat according to platform, the results will be in output/, have a good day and basta! the build.sh in server can confuse newbies, (ehmmm and me as well :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Adam |Heath |Sent: Thursday, November 15, 2001 2:19 AM |To: Jason Dillon |Cc: JBoss Development |Subject: RE: [JBoss-dev] can't build jboss from cvs | | |On Wed, 14 Nov 2001, Jason Dillon wrote: | | If you are trying to build a 3.0 .deb then please use the |'jboss-all' module | from cvs and use 'build/build.sh release' to create a release |suitable for | stuffing into the package. The files will be inder |'build/output/jboss-*/ | |Ok, I've done this, and everything has built fine. | |The layout of build/output looks useable, and I can produce debs from that. |I'll be moving stuff around, to make it fit properly in FHS. I'll |be making |some things into symlinks, to give jboss a correct view on the world. In |other cases, I'll modify the configuration files to access the correct |locations directly. | |Now, to the biggest issue with all this. Could the final jboss |tarball that |is created, *NOT* have any external source? I can understand |having a tarball |that does have this source, but could it be called |jboss-bundle-src.tar.gz, or |something. If there is no source tarball that is in this pristince state, |then I will not be able to upload jboss to Debian, because then it |would mean |that Debian is distributing non-free software, which is not allowed. | |Making debs of course, doesn't really matter about what is |included and what |isn't. But for actual upload to the Debian archive(and all its mirrors), I |*NEED* this non-free code and external code removed from the |source tarball. |Even if this means the build system contains broken references to these |missing files, that is fine. | |Additionally, I tried setting build.compiler=jikes in |build/build.xml, but it |didn't compile blindly fast. Is this the correct way to use jikes? | | |___ |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] can't build jboss from cvs
Something needs to be explained about how debian packaging works. It will help with the understanding of a few things below. Debian source packages contain 3 files(normally) 1: A tarball This tarball is generally an unmodified upstream release, except that it is renamed. 2: A diff This diff contains modifications done to the upstream source, plus the files in debian/, that say how the debs should be layed out. 3: A .dsc This is a simple text file, that describes meta data about the source package. The tarball is prefered to be unmodified, so that md5sums can match with what upstream has. The modifications done to upstream is generally supposed to be minor. If something major is done, or bug fixes where done, then these should be sent upstream. On Thu, 15 Nov 2001, Jason Dillon wrote: Does the stuff in j2ee and naming depend on other jboss items? Do they depend on the jboss module? If no, then I started at the wrong spot. If you look in each build.xml there is a target called '_configure-modules', this section shows the dependency on other modules (or in the case of the build module shows how the modules are organized). Ah, this is very useful information. For any splitting I end up doing, this will help me greatly. Is everything in thirdparty exact copies of external libraries, that get built, or just checked in pre-compiled version, or a mixture of the two? Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Please see my forthcoming mail, explaining this(I didn't want to include it in this mail, because it would make it too cluttered). In either case, since they are third party modules, and not part of jboss, they can not be packaged with jboss in Debian. Fine, as long as you make for sure that there are packages available that contains the *exact* version of these libraries (version appropriately so that things don't break when they are updated). Are the things in thirdparty and tools the latest available? Or are they somewhat old, as making jboss work with newer versions would be too much work right now(right now not precluding it will work later on)? If jboss has patched these upstream sources, have the patches then been sent upstream? Nothing in thirdparty has been patched. They are the same files from downloaded distributions. Good. I'm not building a single jboss deb. What I have done for 2.4, is make separate debs, split along the same lines as each top-level directory in the 2.4.3 tarball. I am not interested in the .deb'ification of 2.4.x at all. I would expect that the package structure of 2.4 would be mostly if not completly different than 3.0. Because 3.0 is imminent, I won't be releasing the debs of 2.4 to a wide audience. Those who will see it, are people here at work, and a few interested Debian developers, who are also interested in JBoss. I am using these people as my alpha and beta testers, so I can make sure that the Debian packaging is correct and functional. * * * I am interested in the creation of .deb's to make it easier for people to get/install/use JBoss. I am very concerned that what you are doing will cause support and maintenece problems. I would rather like to avoid having differing instructions for debian and non-debian users. I would also like to avoid help me emails about users who have the wrong version of thirdparty .deb packages installed... especially when I don't really know who makes and maintains them. Well, for things that exist in thirdparty, there are already existing debs in debian. I will make jboss depend on those debs, and modify build.xml to use the system install versions, instead of the local versions. Also, there is not a single type Debian user. It is true, that doing something along the lines of 'apt-get install jboss' should give you an almost exact copy of what you would get when downloading a precompiled JBoss tarball. However, there are users more advanced than this, who may, for whatever reasons they have, not want the full JBoss environment, and only install a smaller set of features. The way this is accomplished, is with dependencies between debs. You have mentioned that there is a '_configure-modules' target in the build.xmls, that shows the dependencies. This information would be 'ported' to the Debian dependency system, and would allow for micro installation of services. I've seen talk about 3.0 mbeans supporting 'dependencies' by using mbean-refs(and lists). This information could be put into the .deb as well. What happens when an mbean depends on another mbean, but isn't distributed along side it? How is it installed onto the system? Does JBoss throw an error when a mbean-ref doesn't exist? If these dependencies were part of the deb, then the package would not install/configure,
Re: [JBoss-dev] JSR-77: Management Services
Hi David Is there a link to the spec? No, JSR-77 is not published right now. I will provide the docs from the JSR-77 classes which should give you a hint how it works by the end of the week. Does this mean that for every existing mbean (instance) in jboss, we will have an additional JSR-77 mbean? I imagine it is obvious if you know anything about how this works ;-) but why can't you have the existing (service(mbeans implement the appropriate jsr-77 interfaces? JSR-77 does not provide interfaces but only a model and meta-model. JSR-77 should be dynamic like JMS and therefore we don't have interfaces. Every vendor can add their own stuff as long as the core is compatible. Also a service does not map a JSR-77 mbean one to one. It can be that a service maps to many JSR-77 mbeans or that many services map to one JSR-77 mbean. Could describe the nature of the links a bit? It is some sort of an ObjectName (code wise it is the same) from JMX but it only points to another ManagedObject. For instance, how would you navigate to --a rardeployment --the ServiceController --an ejb container J2EEManagement: is a management domain - many J2EEApplications - many J2EEModules - either WebModule - many Servlets - either EjbModule - many EJBs - either RarModule etc. Any light you could shed would be most welcome Unfortunately JSR-77 is not published publicly therefore I cannot give you the spec. But have a look at the JavaDoc I add to the JBossMgt project by the end of the week. Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq: persistence implementation questions
I'll look through the code more closely. But recovery is testable. What you have to do is create some corrupt data files (probably by using a byte-level editor to munge some existing data files). Then you need some scripts to start up the server with those files -- which doesn't fit so well with a pure-Java Junit-based test suite. (You could also create the files by making versions of the server which quit at various awkward places.) What this won't test so easily is recovery from failures during recovery. How about using JUnit to corrupt some files, then startup the component which reads those files and test that is throws the proper exceptions? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] can't build jboss from cvs
Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Fine. Lets not upload a source package. Fine, as long as you make for sure that there are packages available that contains the *exact* version of these libraries (version appropriately so that things don't break when they are updated). Are the things in thirdparty and tools the latest available? Or are they somewhat old, as making jboss work with newer versions would be too much work right now(right now not precluding it will work later on)? Depends. They are the latest version that works with JBoss, or that has been tested to work with JBoss. In most cases they are the latest, but in some cases they are not. I am interested in the creation of .deb's to make it easier for people to get/install/use JBoss. I am very concerned that what you are doing will cause support and maintenece problems. I would rather like to avoid having differing instructions for debian and non-debian users. I would also like to avoid help me emails about users who have the wrong version of thirdparty .deb packages installed... especially when I don't really know who makes and maintains them. Well, for things that exist in thirdparty, there are already existing debs in debian. I will make jboss depend on those debs, and modify build.xml to use the system install versions, instead of the local versions. Are you SURE there is a package for the correct version of EACH ? However, there are users more advanced than this, who may, for whatever reasons they have, not want the full JBoss environment, and only install a smaller set of features. This will not be supported, why waste time trying to rig up a package system to handle it? Advanced users will either make there own packages or abandon packages in this situation and trim down the release themselves. The way this is accomplished, is with dependencies between debs. You have mentioned that there is a '_configure-modules' target in the build.xmls, that shows the dependencies. This information would be 'ported' to the Debian dependency system, and would allow for micro installation of services. Again, the cvs module seperation is not meant as a functional or component seperation tool to generate these types of packages. These dependencies show which modules are required to build the given module... they don't show which modules you would need to do something usefull with it. I've seen talk about 3.0 mbeans supporting 'dependencies' by using mbean-refs(and lists). This information could be put into the .deb as well. What happens when an mbean depends on another mbean, but isn't distributed along side it? How is it installed onto the system? Does JBoss throw an error when a mbean-ref doesn't exist? I am not sure, but this would be more along the lines from which you would want to seperate packages. I think it would be really cool if a debian user could 'apt-get jboss' and in a few minutes/seconds have a functional server which they could start working with right away. That's my goal. However, I do want to support the advanced users that know more about JBoss, and want to fine tune the installation set. Ok. I consider myself an advanced user. I basically want the entire release. I suppose that I could live with out the cluster jars and such... but it seems like to cost involved with making those split ups is not worth it. If you are going to setup a .deb release system you need to think about the other users which may have to maintain your work. Lets not make things overly complicated if the pay off is not worth it. I do not think it is worth it here... unless you can keep it really simple. I also think that there are huge maintenece issues envolved with making this happen. Thus I would lean twords a .deb building system that took worked off our existing release and made use of the support files which are contained there. It will, except for most things in thirdparty and tools. Ok. How do you plan on solving this? This is a BIG issue. Debian packages are designed so that when upgrading from one version to another, the configuration is carried over. If, for some reason, the new version of a package has a subtle change to the configuration, then generally a script is written that facilitates this change. Ok, so now we have a script maintenence issue... perhaps one for each of the packages that have been split up... lots of them based on what I have read so far. This is only for advanced users, using debian or an apt-get compatible unix. What percent of the user/admin population does this cover? What percentage could live with a small set of larger grain packages? What percentage could live with a single package? Splitting them up is just not worth the
[JBoss-dev] [ #481645 ] setRollbackOnly in beforeCompletion
Hi Geeks According to the EJB spec. a Context.setRollback() in beforeCompletion() should rollback. It seems that JBoss is doing this but it throws a RollbackException telling it is unable to commit. Is this ok ? x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
Out of curiousity, where does connector (jbosscx) fit into your packaging scheme? For 3.0 you might consider putting the contents of pool and connector into one package (if they aren't already) as pool is now small and only used by jbosscx. Why not move the pool stuff into jboss/connector (jbosscx) and drop pool? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 1 to Many Relations
OK i'm playing with the latest RH CVS and testing out 1 to many
relations (bi directional). So ..
Table1 {
primary_key int,
}
TableMany {
primary_key int,
table1_key int,
}
class Table1 {
int getPrimary_key()
Collection getTableMany();
}
class TableMany {
int getPrimary_key();
int getTable1_key();
}
the problem is that when it tries to fetch TableMany it looks for a
field called table1_key_primary_key. It would seem that the
default key
should not be made up but the foreign key of the other side of the
relationship. So line 80 of JDBCRelationshipRoleMetaData.java should
just be
tempCmrFieldName = relatedRole.getEntityName();
1. Defaults can be overridden.
2. What happens when you have two one-to-many relationships between Table1
and TableMany?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations
Can you supply the quick 5 line example on properly creating loggers and logging a message. I have been having trouble changing the log levels for cmp. I tried and failed to turn only the CMP channel up to DEFAULT for the console appender for my testing, so I end up turning up the entire console appender to DEFAULT. Do we have docs on this somewhere (not that you need to write some, just wondering)? -dain -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 4:10 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations There was a copy and paste user error in the ERROR description. It should read: ERROR, use the ERROR level priority for events that indicate a disruption in a request or the ability to service a request. A service should have some capacity to continue to service requests in the presence of ERRORs. - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 1:59 PM Subject: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations These are the log4j priority usage recommendations that I intend on introducing into Main next week. Reply with any critque or questions. TRACE, use TRACE the level priority for log messages that are directly associated with activity that corresponds requests. Further, such messages should not be submitted to a Logger unless the Logger category priority threshold indicates that the message will be rendered. Use the Logger.isTraceEnabled() method to determine if the category priority threshold is enabled. The point of the TRACE priority is to allow for deep probing of the JBoss server behavior when necessary. When the TRACE level priority is enabled, you can expect the number of messages in the JBoss server log to grow at least a x N, where N is the number of requests received by the server, a some constant. The server log may well grow as power of N depending on the request-handling layer being traced. DEBUG, use the DEBUG level priority for log messages that convey extra information regarding life-cycle events. Developer or in depth information required for support is the basis for this priority. The important point is that when the DEBUG level priority is enabled, the JBoss server log should not grow proportionally with the number of server requests. Looking at the DEBUG and INFO messages for a given service category should tell you exactly what state the service is in, as well as what server resources it is using: ports, interfaces, log files, etc. INFO, use the INFO level priority for service life-cycle events and other crucial related information. Looking at the INFO messages for a given service category should tell you exactly what state the service is in. WARN, use the WARN level priority for events that may indicate a non-critical service error. Resumable errors, or minor breaches in request expectations fall into this category. The distinction between WARN and ERROR may be hard to discern and so its up to the developer to judge. The simplest criterion is would this failure result in a user support call. If it would use ERROR. If it would not use WARN. ERROR, use the ERROR level priority for events that indicate non-critical errors that do represent a disruption in a request or the ability to service a request. A service should have some capacity to continue to service requests in the presence of ERRORs. FATAL, use the FATAL level priority for events that indicate a critical service failure. If a service issues a FATAL error it is completely unable to service requests of any kind. 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.logging.Logger priority usage recommendations
Its really just log4j stuff. All that we are doing is introducing a facade
over
the log4j Category to directly support the use of the custom trace priority
and hide all of the non-logging methods.
The first thing you need to decide is what is the category name your going
to use. This should be based on the class name of the component doing
the logging. If there are multiple instances of a component, and it is
associated with another meaningful name, this name will be
added as a subcategory to the component class name. For example,
the org.jboss.security.plugins.JaasSecurityManager class uses
a base category name equal to its class name. There can be
multiple JaasSecurityManager instances, and each is associated
with a security domain name. Therefore, the complete log4j
category name used by the JaasSecurityManager is
org.jboss.security.plugins.JaasSecurityManager.securityDomain,
where the securityDomain value is the name of the associated
security domain.
To create a Logger for JaasSecurityManager this is the code snippet:
package org.jboss.security.plugins;
import org.jboss.logging.Logger;
public class JaasSecurityManager ...
{
Logger log;
public JaasSecurityManager (String securityDomain)
{
String name = JaasSecurityManager.class + '.' + securityDomain;
log = Logger.getLogger(name);
}
}
After that just use the log with whatever priority level is approriate.
Activating the TRACE level priority is done by adding a category threshold
statement to the log4j.properties file. To enable tracing for a particular
JaasSecurityManager security domain called other I would add:
log4j.category.org.jboss.security.plugins.JaasSecurityManager.other=TRACE#or
g.jboss.logging.log4j.TracePriority
To enable the TRACE level priority for all JaasSecurityManager instances I
would add:
log4j.category.org.jboss.security.plugins.JaasSecurityManager=TRACE#org.jbos
s.logging.log4j.TracePriority
To enable the TRACE level priority for all components in the security pkg:
log4j.category.org.jboss.security=TRACE#org.jboss.logging.log4j.TracePriorit
y
You can also redirect a given categories message to a seperate log file or
endpoint
by assiging it a different appender. For example, to redirect all security
output to
a security.log file, and set the security package threshold to TRACE use:
### The security.log file appender
log4j.appender.SecurityLog=org.apache.log4j.FileAppender
log4j.appender.SecurityLog.File=../log/security.log
log4j.appender.SecurityLog.layout=org.apache.log4j.PatternLayout
log4j.appender.SecurityLog.layout.ConversionPattern=[%c{1}] %m%n
log4j.appender.SecurityLog.Append=false
log4j.category.org.jboss.security=TRACE#org.jboss.logging.log4j.TracePriorit
y, SecurityLog
- Original Message -
From: Dain Sundstrom [EMAIL PROTECTED]
To: 'Scott M Stark' [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 3:34 PM
Subject: RE: [JBoss-dev] org.jboss.logging.Logger priority usage
recommendations
Can you supply the quick 5 line example on properly creating loggers and
logging a message. I have been having trouble changing the log levels for
cmp. I tried and failed to turn only the CMP channel up to DEFAULT for
the
console appender for my testing, so I end up turning up the entire console
appender to DEFAULT. Do we have docs on this somewhere (not that you need
to
write some, just wondering)?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-471228 ] Exceptions in BMT transaction blocks.
Bugs item #471228, was opened at 2001-10-15 00:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=471228group_id=22866 Category: JBossTX Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Schaefer (schaefera) Summary: Exceptions in BMT transaction blocks. Initial Comment: When an exception is thrown out of a transaction block in a BMT Session Bean (between the begin commit) the only error displayed is: Application error: BMT stateless bean MyBean should complete transactions before returning (ejb1.1 spec, 11.6.1) The original exception is not mentioned at all. Shouldn't an exception being thrown automatically roll-back the transaction? If not, my mistake, though this poses a nasty debug situation as my code was occasionally throwing a NullPointer. My fault of course, but very hard to track down when the only message being displayed relates to a transaction not being completed. Cheers, Dave -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-15 14:07 Message: Logged In: YES user_id=70434 Current JBoss CVS Head and Branch_2_4 does report the exception. Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=471228group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq: persistence implementation questions
Corrupting the files is not exactly what we are looking for. If you have currupted data files, you need will need to restore you data from backup. What we want to test is: (1) that we are correctly flushing out our output to disk when we commit a transaction. All message are FULLY written to disk by the time the commit is issued. (2) that we do not attempt to recover messages from transaction that did not commit. (3) that we can deal with garbage at the end of out transaction logs. So would adding garbage at the end of a message log files or adding garbage message files simulate(2,3)?? Would HARD Killing the server after a commit test (2)??? How would we implement the HARD kill (JNI)?? Any other tests/ideas?? Regards, Hiram From: Jason Dillon [EMAIL PROTECTED] To: Loren Rosen [EMAIL PROTECTED] CC: Hiram Chirino [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jbossmq: persistence implementation questions Date: Thu, 15 Nov 2001 15:07:23 -0800 (PST) I'll look through the code more closely. But recovery is testable. What you have to do is create some corrupt data files (probably by using a byte-level editor to munge some existing data files). Then you need some scripts to start up the server with those files -- which doesn't fit so well with a pure-Java Junit-based test suite. (You could also create the files by making versions of the server which quit at various awkward places.) What this won't test so easily is recovery from failures during recovery. How about using JUnit to corrupt some files, then startup the component which reads those files and test that is throws the proper exceptions? --jason _ 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] jbossmq: persistence implementation questions
In jboss 3, you __should__ be able to start and stop jbossmq dynamically while the rest of the server is running. We are not very far from being able to run several JBossMQService mbeans at once-- this could allow you to test one pm at a time without messing up the standard jbossmq setup. I think stopping works less well than starting at the moment. You should be able to do this by deploying/undeploying a file like jbossmq-service.xml. There are lots of examples in the testsuite using the JBossTestCase and JBossTestSetup classes: especially the jmx tests. (these don't all pass at the moment, but do show how to deploy/undeploy service files). david jencks On 2001.11.15 17:27:44 -0500 Loren Rosen wrote: Hiram Chirino wrote: Hi Loren! From: Loren Rosen [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: [JBoss-dev] jbossmq: persistance implementation questions Date: Mon, 12 Nov 2001 20:22:27 -0800 * Performance tuning/scalability: has any work been done to address potential bottlenecks for high message throughput, large numbers of queues or topics, etc.? Work has gone into making reading/writing from storage more efficient. I don't think we have profiled the system enough yet to find out where the bottle necks are. A good first step would be to measure the single producer/consumer latency, and tune that. Low latency is a important goal in its own right, and moreover if the CPU overhead is too high you won't even be able to keep the disk busy writing messages. I can go ahead and do this. * recovery robustness: recovery is a tricky thing since there's so many possible ways things can fail. What's been done to think about/test-for/defend-against all the possibilities? Basic recovery test have been succeeding. It's hard to automate failure testing. More code review would be good in this area to see if we are missing anything. I'll look through the code more closely. But recovery is testable. What you have to do is create some corrupt data files (probably by using a byte-level editor to munge some existing data files). Then you need some scripts to start up the server with those files -- which doesn't fit so well with a pure-Java Junit-based test suite. (You could also create the files by making versions of the server which quit at various awkward places.) What this won't test so easily is recovery from failures during recovery. 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] suggest changing log4j layout patterns
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main] () - Shutdown hook
added
2001-11-13 11:35:36,576 6762 WARN org.jboss.configuration.ConfigurationService
[main] () - Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount of
useful information on the console in a terse format and dumps all usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by default
and I suggest that we update the log4j.properties (or use log4j.xml) with
these layout formats.
Any objections?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
My current opinion is --jbosspool may be very good for some things, but has way too much speculative functionality for a comprehensible jca ConnectionManager. It is also too complicated to find bugs in (and there are serious bugs) --Both jbosspool and the ConnectionManagers are under X license. Aaron doesn't seem interested in changing the license on the files he wrote. My goal is to write a simpler, better working pool implementation with exactly what is needed for ConnectionManagers, and replace all the X code. At least one person has expressed interest in the jbosspool stuff for other purposes, so I'm really not sure what to do with it. david jencks On 2001.11.15 18:26:50 -0500 Jason Dillon wrote: Out of curiousity, where does connector (jbosscx) fit into your packaging scheme? For 3.0 you might consider putting the contents of pool and connector into one package (if they aren't already) as pool is now small and only used by jbosscx. Why not move the pool stuff into jboss/connector (jbosscx) and drop pool? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
On 2001.11.15 18:06:11 -0500 Jason Dillon wrote: Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Fine. Lets not upload a source package. Fine, as long as you make for sure that there are packages available that contains the *exact* version of these libraries (version appropriately so that things don't break when they are updated). Are the things in thirdparty and tools the latest available? Or are they somewhat old, as making jboss work with newer versions would be too much work right now(right now not precluding it will work later on)? Depends. They are the latest version that works with JBoss, or that has been tested to work with JBoss. In most cases they are the latest, but in some cases they are not. I am interested in the creation of .deb's to make it easier for people to get/install/use JBoss. I am very concerned that what you are doing will cause support and maintenece problems. I would rather like to avoid having differing instructions for debian and non-debian users. I would also like to avoid help me emails about users who have the wrong version of thirdparty .deb packages installed... especially when I don't really know who makes and maintains them. Well, for things that exist in thirdparty, there are already existing debs in debian. I will make jboss depend on those debs, and modify build.xml to use the system install versions, instead of the local versions. Are you SURE there is a package for the correct version of EACH ? However, there are users more advanced than this, who may, for whatever reasons they have, not want the full JBoss environment, and only install a smaller set of features. This will not be supported, why waste time trying to rig up a package system to handle it? Advanced users will either make there own packages or abandon packages in this situation and trim down the release themselves. The way this is accomplished, is with dependencies between debs. You have mentioned that there is a '_configure-modules' target in the build.xmls, that shows the dependencies. This information would be 'ported' to the Debian dependency system, and would allow for micro installation of services. Again, the cvs module seperation is not meant as a functional or component seperation tool to generate these types of packages. These dependencies show which modules are required to build the given module... they don't show which modules you would need to do something usefull with it. I've seen talk about 3.0 mbeans supporting 'dependencies' by using mbean-refs(and lists). This information could be put into the .deb as well. What happens when an mbean depends on another mbean, but isn't distributed along side it? How is it installed onto the system? Does JBoss throw an error when a mbean-ref doesn't exist? No, the point is to make sure mbeans aren't started before their dependencies are satisified. There's no time limit on when someone might come along and deploy the needed mbean. I am not sure, but this would be more along the lines from which you would want to seperate packages. I think it would be really cool if a debian user could 'apt-get jboss' and in a few minutes/seconds have a functional server which they could start working with right away. That's my goal. However, I do want to support the advanced users that know more about JBoss, and want to fine tune the installation set. Ok. I consider myself an advanced user. I basically want the entire release. I suppose that I could live with out the cluster jars and such... but it seems like to cost involved with making those split ups is not worth it. If you are going to setup a .deb release system you need to think about the other users which may have to maintain your work. Lets not make things overly complicated if the pay off is not worth it. I do not think it is worth it here... unless you can keep it really simple. I also think that there are huge maintenece issues envolved with making this happen. Thus I would lean twords a .deb building system that took worked off our existing release and made use of the support files which are contained there. It will, except for most things in thirdparty and tools. Ok. How do you plan on solving this? This is a BIG issue. Debian packages are designed so that when upgrading from one version to another, the configuration is carried over. If, for some reason, the new version of a package has a subtle change to the configuration, then generally a script is written that facilitates this change. Ok, so now we have a script maintenence issue... perhaps one for each of the packages that have been
LONG: RE: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, Adam Heath wrote: Is everything in thirdparty exact copies of external libraries, that get built, or just checked in pre-compiled version, or a mixture of the two? Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Please see my forthcoming mail, explaining this(I didn't want to include it in this mail, because it would make it too cluttered). Please go read the Debian Social Contract(#1), and the Debian Free Software Guidelines(DFSG, #2), before continuing on with the rest of this email. It has some bearing on general nature of what follows. The reason I have been pushing so much for a release of JBoss that will not have the precompiled sources, is that these sources, while some being non-free(I'll explain more about this in a bit), are not under the control of JBoss. JBoss should not be concerned with the issues that occur with these external entities, except when they affect JBoss. In Debian, these packages will not just affect JBoss, but affect all software that uses them. This means that each external entity should handle its own issues, and they should not be all lumped together with another. As far are Debian is concerned, JBoss can do whatever they want, and can distribute whatever JBoss wants. However, to actually have JBoss become included with Debian, all license issues have to be resolved(either by using free versions of software, or by placing a package into contrib, and having broken dependencies). Inclusion in Debian is a very worthwhile goal, as Debian is arguably the second largest linux distribution. In addition to that, Debian is built on the distributed free software development, on steroids. Everything is done online, in email, irc, and thru web. Inclusion into Debian main states something about the software so included. It states that the software is free, and only uses free software to do what it sets out to do. This is a very important statement to make. Inclusion into contrib is allowed for packages that themselves are free, but for whatever reason, depend on/use software that is not free. It is understood, that if a free version of a non-free package was available, then the package in contrib would use that instead. Non-free precompiled/bundled code: There are several bundles items in thirdparty and tools, that have restrictive license, that forbid redistribution. For instance, lets consider jaxp(#3): 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively Software), by the number of users and the class of computer hardware for which the corresponding fee has been paid. Having this available in cvs, for download by end users, and as part of the precompiled tarball, in addition to the source download, goes against internal use only. However, in section 1 of the supplemental agreement, there is more discussion about this point. See below. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. This section states that .. you may not make copies .. other than .. for archival purposes. Also, decompile is not defined, and could be implied to mean unjaring of the embedded jaxp.jar. 7. Export Regulations. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. This could have ramifications if someone in an export controlled regulated country downloads JBoss, and, by extension, jaxp. In the supplemental license for jaxp, there are additional items to be concerned about. 1. Software Internal Use and Development
Re: [JBoss-dev] jbossmq: persistence implementation questions
Use mock objects. www.mockobjects.com To use the automated mock object creator may require modifying the code a little (creating some more interfaces), but you can simply use the concept. It is the only great way to test complicated failure cases, especially when there is a complicated state that has to be established. The idea is to have an object that you can tell it what state to be in - for instance, to fail whenever you call a certain routine, etc, and what kind of failure. It implements the same interface as the real object, so that you can use it interchangeably. There are some other concepts with mockobjects also, such as input or call validation - the object can keep track of how it was called and with what parameters and in what order. This can all be validated against your expectations. the mock objects people call it endotesting because you are testing from the inside, but without tainting your actual code with any knowledge of the testing framework. (Besides the need to create an interface based on the object, which is a sometimes a good thing anyway, though it does add one more file to maintain). Pretty good stuff... Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net services software. Loren Rosen [EMAIL PROTECTED] 11/15/01 3:27:44 PM Hiram Chirino wrote: Hi Loren! From: Loren Rosen [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: [JBoss-dev] jbossmq: persistance implementation questions Date: Mon, 12 Nov 2001 20:22:27 -0800 * Performance tuning/scalability: has any work been done to address potential bottlenecks for high message throughput, large numbers of queues or topics, etc.? Work has gone into making reading/writing from storage more efficient. I don't think we have profiled the system enough yet to find out where the bottle necks are. A good first step would be to measure the single producer/consumer latency, and tune that. Low latency is a important goal in its own right, and moreover if the CPU overhead is too high you won't even be able to keep the disk busy writing messages. I can go ahead and do this. * recovery robustness: recovery is a tricky thing since there's so many possible ways things can fail. What's been done to think about/test-for/defend-against all the possibilities? Basic recovery test have been succeeding. It's hard to automate failure testing. More code review would be good in this area to see if we are missing anything. I'll look through the code more closely. But recovery is testable. What you have to do is create some corrupt data files (probably by using a byte-level editor to munge some existing data files). Then you need some scripts to start up the server with those files -- which doesn't fit so well with a pure-Java Junit-based test suite. (You could also create the files by making versions of the server which quit at various awkward places.) What this won't test so easily is recovery from failures during recovery. 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Destroy not called
Destroy is not called on my persistence store anymore. Is destroy no longer supported? I don't use stop so I could move my code back into stop, but I can't speak for any other code. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq: persistence implementation questions
I was only really suggesting that rather than test the entire JBoss server instance with a JBoss service, to focus on the individual component which performs this functionality. Assuming that the component can be started up from inside JUnit, then we can setup any given environment and given it a whirl. The same could be done by testing the entire server, but it would be more complicated and would not tell you that the given component will pass or fail the test (another component could be causing the component to fail... which is useful to know too). In this case, you could setup a log which might have 3 valid and then invalid garbage. JUnit could setup a log file which looked like this, then startup the component with that generated file and see if it performs as desired. Todo the same would mean knowing more about how the server starts up, its config and such to doctor up the environment to make the test work. Anyways, I am no QA/Unit Test expert... though work has kinda given me that hat to put on now (those bastards), so this is mostly specilation on my part. From last I played with jboss/testsuite (a while ago), most tests were run from JUnit by deploying something into a running server, pounding on it and then undeploying the app. I think this is good for many tests, there are some tests where we might want to avoid the deploy/rmi-exec/undeploy bits and simply execute the code directly. This would test the functionality of that code with out any additional factorys from the deploy/rmi/undeploy. In the case of JMS internals I think this is a great place to start. Could be that is what you are doing already... I would have to look at the testsuite again to become more familar with it. (1) that we are correctly flushing out our output to disk when we commit a transaction. All message are FULLY written to disk by the time the commit is issued. Probably the only way to ensure this would be to sync the FileDescriptor, then re-read the log. Assuming that FileDescriptor.sync() will actually sync correctly or throw an exception, once you pass this method you are assured that the data written has actually flushed... more or less. Could be that the fs was really a ramdrive, or a raid-cache with no battery backup, but there is nothing you can do about that. Once you write one, sync. You can re-read the log and expect to have exactly one log, which will have the expected attributes and such. Anything else is a problem. (2) that we do not attempt to recover messages from transaction that did not commit. If the tx did not commit would it have been sync'd to disk? Not really sure how all that XA fluff works, so I have no clue how to test that. (3) that we can deal with garbage at the end of out transaction logs. Re-reading the tx log after a set of pre-descripted events should provide coverage of most of the problems. Would HARD Killing the server after a commit test (2)??? How would we implement the HARD kill (JNI)?? I have no clue as to the best way to test a total VM failure. Sure a JNI could call exit(), but then you would have to have some external process monitoring the test, and then some way to start up a new vm and communicate with it. Perhaps we need a bit of JUnit framework to do this? This could be used to do the end-to-end testing, where the testing vm would start up the JBoss vm (or more than one for distributed tests) and the could kill them as needed. Then you could setup any given environemnt, perhaps it was a standalone JBoss, or perhaps it was a specialed TestCase or TestSuite, which is rather volitle. Does such a JUnit modification/integration suite exist? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: LONG: RE: [JBoss-dev] can't build jboss from cvs
No wonder people bitch about Debian. I vote we forget the DEB and just build an RMP, which Debian can install. -dain -Original Message- From: Adam Heath [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 6:20 PM To: Jason Dillon Cc: David Maplesden; JBoss Development Subject: LONG: RE: [JBoss-dev] can't build jboss from cvs On Thu, 15 Nov 2001, Adam Heath wrote: Is everything in thirdparty exact copies of external libraries, that get built, or just checked in pre-compiled version, or a mixture of the two? Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Please see my forthcoming mail, explaining this(I didn't want to include it in this mail, because it would make it too cluttered). Please go read the Debian Social Contract(#1), and the Debian Free Software Guidelines(DFSG, #2), before continuing on with the rest of this email. It has some bearing on general nature of what follows. The reason I have been pushing so much for a release of JBoss that will not have the precompiled sources, is that these sources, while some being non-free(I'll explain more about this in a bit), are not under the control of JBoss. JBoss should not be concerned with the issues that occur with these external entities, except when they affect JBoss. In Debian, these packages will not just affect JBoss, but affect all software that uses them. This means that each external entity should handle its own issues, and they should not be all lumped together with another. As far are Debian is concerned, JBoss can do whatever they want, and can distribute whatever JBoss wants. However, to actually have JBoss become included with Debian, all license issues have to be resolved(either by using free versions of software, or by placing a package into contrib, and having broken dependencies). Inclusion in Debian is a very worthwhile goal, as Debian is arguably the second largest linux distribution. In addition to that, Debian is built on the distributed free software development, on steroids. Everything is done online, in email, irc, and thru web. Inclusion into Debian main states something about the software so included. It states that the software is free, and only uses free software to do what it sets out to do. This is a very important statement to make. Inclusion into contrib is allowed for packages that themselves are free, but for whatever reason, depend on/use software that is not free. It is understood, that if a free version of a non-free package was available, then the package in contrib would use that instead. Non-free precompiled/bundled code: There are several bundles items in thirdparty and tools, that have restrictive license, that forbid redistribution. For instance, lets consider jaxp(#3): 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively Software), by the number of users and the class of computer hardware for which the corresponding fee has been paid. Having this available in cvs, for download by end users, and as part of the precompiled tarball, in addition to the source download, goes against internal use only. However, in section 1 of the supplemental agreement, there is more discussion about this point. See below. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. This section states that .. you may not make copies .. other than .. for archival purposes. Also, decompile is not defined, and could be implied to mean unjaring of the embedded jaxp.jar. 7. Export Regulations. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or
RE: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, Jason Dillon wrote: What changes need to be make to make things fit into FHS? configuration in /etc/jboss. log files in /var/log/jboss cache data(extracted ears, wars, etc) in /var/cache/jboss Deployment done by the local admin should be done in /var/lib/jboss All files in jboss are architecture indepenant, so they go in /usr/share. Documention in /usr/share/doc/jboss. java jars(not ejbs) go in /usr/share/java. jboss files in /usr/share/jboss. JBOSS_HOME is set to /usr/share/jboss. There are symlinks in this dir, to the various other locations, to make sure the system runs as it is supposed to. What do you mean external source? Source that was download from someplace on the web, and is used by jboss, but not incorporated into jboss. Can you be more specific about what parts of the current 3.0 dist are not allowed? Give me some time to look up the upstream location of all those things. The build system probably won't work with broken anything. What non-free code and external code are you talking about? Give me some time to do this. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq: persistence implementation questions
Right, deep testing of service internals does not really belong in the current jbosstest unit tests. Those are for testing client oriented interaction with the server. Each module should have its own unit tests for internal testing. Transaction failure semantics and recovery is getting to in between ground. You could do as Jeff suggested and make use of mock objects to deploy different version of the mq and other JBoss services to isolate the testing in either unit testsuite. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Hiram Chirino [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 4:29 PM Subject: Re: [JBoss-dev] jbossmq: persistence implementation questions I was only really suggesting that rather than test the entire JBoss server instance with a JBoss service, to focus on the individual component which performs this functionality. Assuming that the component can be started up from inside JUnit, then we can setup any given environment and given it a whirl. The same could be done by testing the entire server, but it would be more complicated and would not tell you that the given component will pass or fail the test (another component could be causing the component to fail... which is useful to know too). In this case, you could setup a log which might have 3 valid and then invalid garbage. JUnit could setup a log file which looked like this, then startup the component with that generated file and see if it performs as desired. Todo the same would mean knowing more about how the server starts up, its config and such to doctor up the environment to make the test work. Anyways, I am no QA/Unit Test expert... though work has kinda given me that hat to put on now (those bastards), so this is mostly specilation on my part. From last I played with jboss/testsuite (a while ago), most tests were run from JUnit by deploying something into a running server, pounding on it and then undeploying the app. I think this is good for many tests, there are some tests where we might want to avoid the deploy/rmi-exec/undeploy bits and simply execute the code directly. This would test the functionality of that code with out any additional factorys from the deploy/rmi/undeploy. In the case of JMS internals I think this is a great place to start. Could be that is what you are doing already... I would have to look at the testsuite again to become more familar with it. (1) that we are correctly flushing out our output to disk when we commit a transaction. All message are FULLY written to disk by the time the commit is issued. Probably the only way to ensure this would be to sync the FileDescriptor, then re-read the log. Assuming that FileDescriptor.sync() will actually sync correctly or throw an exception, once you pass this method you are assured that the data written has actually flushed... more or less. Could be that the fs was really a ramdrive, or a raid-cache with no battery backup, but there is nothing you can do about that. Once you write one, sync. You can re-read the log and expect to have exactly one log, which will have the expected attributes and such. Anything else is a problem. (2) that we do not attempt to recover messages from transaction that did not commit. If the tx did not commit would it have been sync'd to disk? Not really sure how all that XA fluff works, so I have no clue how to test that. (3) that we can deal with garbage at the end of out transaction logs. Re-reading the tx log after a set of pre-descripted events should provide coverage of most of the problems. Would HARD Killing the server after a commit test (2)??? How would we implement the HARD kill (JNI)?? I have no clue as to the best way to test a total VM failure. Sure a JNI could call exit(), but then you would have to have some external process monitoring the test, and then some way to start up a new vm and communicate with it. Perhaps we need a bit of JUnit framework to do this? This could be used to do the end-to-end testing, where the testing vm would start up the JBoss vm (or more than one for distributed tests) and the could kill them as needed. Then you could setup any given environemnt, perhaps it was a standalone JBoss, or perhaps it was a specialed TestCase or TestSuite, which is rather volitle. Does such a JUnit modification/integration suite exist? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
Woah... this is a bit much for me to troll over at the moment... but here are some comments based on a brief look. First, I don't really care about the details of debian stuff. If you do that is greate. Sounds like we need to split up these non-free bits from the free bits. I am all for that. How do we do that and still allow the build system to work with little to no user or bs/lib maintainer overhead? It looks like there is no way jboss could be put directly into 'main', since it depends on non-free software to do what it sets out to do. So I would guess it would go into contrib, honestly I don't really care which module it goes into. It would be nice if evey debian os came with JBoss by default if the user wants J2EE, JMX or advanced java server support, but why not simply provide our own packages, and provide docs on the lines to add to the apt-get config file? Why do we need to provide a source package which contains all 'free' only sources? If you need to do that, simply take a release from 'jboss-all/build/build.sh release', strip out the bits you deem non-free, hook those non-free bits up into the dependencies, then turn what is left over into a package. If you really need a untouched release from JBoss with out these, then we need to think about how that would be possible, if that would be possible. I think that JBoss will eventually have to worry about these distribution licensing issues, which may lead us to forcing a physical seperation from free and non-free bits which are required to run the server. I don't have time to even figure out what to bits are, but I could make time to take that infomration and devise a plan to augment the build system to handle it, assuming that the distribution mechansim will not have an adverse affect on our users. So, I don't mean to dis you long email, but I don't really have time to get into the debian'ism which you are working with. I am willing to look at the thirdparty seperation, but to make a change like that probably will not be swift... though it might be better to make such a change before any 3.0 is released. I am open to ideas on how to seperate these, though I can tell you that things like 'go download x from x.com, y from y.com' and so on will not fly. I would expect that if this worked at all it would be, here is the jboss-xxx.zip with LGPL and here is jboss-thirdparty-xxx.zip with (long list of varing licenses which allow us to distribute it). A user would then unzip each at the same level and have a happy release to start using. --jason On Thu, 15 Nov 2001, Adam Heath wrote: On Thu, 15 Nov 2001, Adam Heath wrote: Is everything in thirdparty exact copies of external libraries, that get built, or just checked in pre-compiled version, or a mixture of the two? Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Please see my forthcoming mail, explaining this(I didn't want to include it in this mail, because it would make it too cluttered). Please go read the Debian Social Contract(#1), and the Debian Free Software Guidelines(DFSG, #2), before continuing on with the rest of this email. It has some bearing on general nature of what follows. The reason I have been pushing so much for a release of JBoss that will not have the precompiled sources, is that these sources, while some being non-free(I'll explain more about this in a bit), are not under the control of JBoss. JBoss should not be concerned with the issues that occur with these external entities, except when they affect JBoss. In Debian, these packages will not just affect JBoss, but affect all software that uses them. This means that each external entity should handle its own issues, and they should not be all lumped together with another. As far are Debian is concerned, JBoss can do whatever they want, and can distribute whatever JBoss wants. However, to actually have JBoss become included with Debian, all license issues have to be resolved(either by using free versions of software, or by placing a package into contrib, and having broken dependencies). Inclusion in Debian is a very worthwhile goal, as Debian is arguably the second largest linux distribution. In addition to that, Debian is built on the distributed free software development, on steroids. Everything is done online, in email, irc, and thru web. Inclusion into Debian main states something about the software so included. It states that the software is free, and only uses free software to do what it sets out to do. This is a very important statement to make. Inclusion into contrib is allowed for packages that themselves are free, but for whatever reason, depend on/use software that is not free. It is understood, that if a free version of a non-free
RE: SHORT: RE: [JBoss-dev] can't build jboss from cvs
No wonder people bitch about Debian. =) I vote we forget the DEB and just build an RMP, which Debian can install. We can probably build both. I think the licensing bits need to be sorted out eventually. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
I don't have a strong feeling either way. Less modules would be simplier and probably a bit faster, so unless there are compelling reasons to have them seperate I would say move the pool stuff into connector (assuming that only connector is every expected to depend on this stuff). --jason On Thu, 15 Nov 2001, David Jencks wrote: My current opinion is --jbosspool may be very good for some things, but has way too much speculative functionality for a comprehensible jca ConnectionManager. It is also too complicated to find bugs in (and there are serious bugs) --Both jbosspool and the ConnectionManagers are under X license. Aaron doesn't seem interested in changing the license on the files he wrote. My goal is to write a simpler, better working pool implementation with exactly what is needed for ConnectionManagers, and replace all the X code. At least one person has expressed interest in the jbosspool stuff for other purposes, so I'm really not sure what to do with it. david jencks On 2001.11.15 18:26:50 -0500 Jason Dillon wrote: Out of curiousity, where does connector (jbosscx) fit into your packaging scheme? For 3.0 you might consider putting the contents of pool and connector into one package (if they aren't already) as pool is now small and only used by jbosscx. Why not move the pool stuff into jboss/connector (jbosscx) and drop pool? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCStopCommand.java JDBCDestroyCommand.java
User: dsundstrom
Date: 01/11/15 16:47:50
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCStopCommand.java
JDBCDestroyCommand.java
Log:
Move all code from destroy to stop.
Revision ChangesPath
1.3 +71 -10
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStopCommand.java
Index: JDBCStopCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStopCommand.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JDBCStopCommand.java 2001/08/03 17:15:46 1.2
+++ JDBCStopCommand.java 2001/11/16 00:47:50 1.3
@@ -7,26 +7,87 @@
package org.jboss.ejb.plugins.cmp.jdbc;
+import java.sql.Connection;
+import java.sql.DatabaseMetaData;
+import java.sql.ResultSet;
+import java.sql.SQLException;
import org.jboss.ejb.plugins.cmp.StopCommand;
+import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge;
/**
- * JDBCStopCommand does nothing.
+ * JDBCStopCommand drops the table for this entity if specified in the xml.
*
+ * @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
-public class JDBCStopCommand implements StopCommand
-{
- // Constructors --
+public class JDBCStopCommand extends JDBCUpdateCommand implements StopCommand {
+
+ public JDBCStopCommand(JDBCStoreManager manager) {
+ super(manager, Stop);
+ }
- public JDBCStopCommand(JDBCStoreManager manager)
- {
+ public void execute() {
+ if(entityMetaData.getRemoveTable()) {
+ log.debug(Droping tables for entity + entity.getEntityName());
+ dropTable(entityMetaData.getTableName());
+
+ // drop relation tables
+ JDBCCMRFieldBridge[] cmrFields = entity.getJDBCCMRFields();
+ for(int i=0; icmrFields.length; i++) {
+// if it uses a relation-table drop it
+if(!cmrFields[i].hasForeignKey()
+ !cmrFields[i].getRelatedCMRField().hasForeignKey()) {
+
+ dropTable(cmrFields[i].getRelationTableName());
+}
+ }
+ }
}
- // StopCommand implementation -
+ public void dropTable(String tableName) {
+ Connection con = null;
+ ResultSet rs = null;
+ try {
+ con = manager.getConnection();
+ DatabaseMetaData dmd = con.getMetaData();
+ rs = dmd.getTables(con.getCatalog(), null, tableName, null);
+ if(!rs.next()) {
+// table already deleted
+return;
+ }
+ } catch(SQLException e) {
+ // ignore - bad driver
+ return;
+ } finally {
+ JDBCUtil.safeClose(rs);
+ JDBCUtil.safeClose(con);
+ }
+
+ try {
+ // since we use the pools, we have to do this within a transaction
+ manager.getContainer().getTransactionManager().begin();
+ jdbcExecute(DROP TABLE + tableName);
+ manager.getContainer().getTransactionManager().commit();
+ log.info(Dropped table ' + tableName + ' successfully.);
+ } catch (Exception e) {
+ log.debug(Could not drop table + tableName + : + e.getMessage());
+ try {
+manager.getContainer().getTransactionManager().rollback ();
+ } catch (Exception _e) {
+log.error(Could not roll back transaction: + _e.getMessage());
+ }
+ }
+ }
- public void execute()
- {
+ protected String getSQL(Object sql) throws Exception {
+ return (String) sql;
+ }
+
+ protected Object handleResult(int rowsAffected, Object argOrArgs)
+ throws Exception
+ {
+ return null;
}
}
1.7 +3 -72
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDestroyCommand.java
Index: JDBCDestroyCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDestroyCommand.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCDestroyCommand.java 2001/09/11 18:35:00 1.6
+++ JDBCDestroyCommand.java 2001/11/16 00:47:50 1.7
@@ -7,91 +7,22 @@
package org.jboss.ejb.plugins.cmp.jdbc;
-import java.sql.Connection;
-import java.sql.DatabaseMetaData;
-import java.sql.ResultSet;
-import java.sql.SQLException;
import org.jboss.ejb.plugins.cmp.DestroyCommand;
-import
Re: [JBoss-dev] jbossmq: persistence implementation questions
Can mockobjects be integrated with JUnit? --jason On Thu, 15 Nov 2001, Jeff Tulley wrote: Use mock objects. www.mockobjects.com To use the automated mock object creator may require modifying the code a little (creating some more interfaces), but you can simply use the concept. It is the only great way to test complicated failure cases, especially when there is a complicated state that has to be established. The idea is to have an object that you can tell it what state to be in - for instance, to fail whenever you call a certain routine, etc, and what kind of failure. It implements the same interface as the real object, so that you can use it interchangeably. There are some other concepts with mockobjects also, such as input or call validation - the object can keep track of how it was called and with what parameters and in what order. This can all be validated against your expectations. the mock objects people call it endotesting because you are testing from the inside, but without tainting your actual code with any knowledge of the testing framework. (Besides the need to create an interface based on the object, which is a sometimes a good thing anyway, though it does add one more file to maintain). Pretty good stuff... Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net services software. Loren Rosen [EMAIL PROTECTED] 11/15/01 3:27:44 PM Hiram Chirino wrote: Hi Loren! From: Loren Rosen [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: [JBoss-dev] jbossmq: persistance implementation questions Date: Mon, 12 Nov 2001 20:22:27 -0800 * Performance tuning/scalability: has any work been done to address potential bottlenecks for high message throughput, large numbers of queues or topics, etc.? Work has gone into making reading/writing from storage more efficient. I don't think we have profiled the system enough yet to find out where the bottle necks are. A good first step would be to measure the single producer/consumer latency, and tune that. Low latency is a important goal in its own right, and moreover if the CPU overhead is too high you won't even be able to keep the disk busy writing messages. I can go ahead and do this. * recovery robustness: recovery is a tricky thing since there's so many possible ways things can fail. What's been done to think about/test-for/defend-against all the possibilities? Basic recovery test have been succeeding. It's hard to automate failure testing. More code review would be good in this area to see if we are missing anything. I'll look through the code more closely. But recovery is testable. What you have to do is create some corrupt data files (probably by using a byte-level editor to munge some existing data files). Then you need some scripts to start up the server with those files -- which doesn't fit so well with a pure-Java Junit-based test suite. (You could also create the files by making versions of the server which quit at various awkward places.) What this won't test so easily is recovery from failures during recovery. 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
Sorry to bud in here, but I think this statement is a little harsh. I think these licensing issues that Adam raises are very relevant to all of the JBoss project! JBoss is licensed under LGPL, right? So does JBoss include JAXP? If not, then it certainly shouldn't be part of the source distribution. If it is, then there are some licensing issues that need to be worked out. (You can't just arbitrarily call someone elses code licensed under LGPL!) I assume you meant 'rpm' (Redhat Package Manager). How do these issues that Adam raises *not* affect any other sort of distribution, including a windows installer or something like that? BTW, isn't voting about whether a debian package is allowed against the LGPL? (Or at least the spirit of LGPL?) I am no licensing expert but this seems like a weird solution to me and sound to me like you are trying to ignore these serious licensing issues. Dain Sundstrom wrote: No wonder people bitch about Debian. I vote we forget the DEB and just build an RMP, which Debian can install. -dain -Original Message- From: Adam Heath [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 6:20 PM To: Jason Dillon Cc: David Maplesden; JBoss Development Subject: LONG: RE: [JBoss-dev] can't build jboss from cvs On Thu, 15 Nov 2001, Adam Heath wrote: Is everything in thirdparty exact copies of external libraries, that get built, or just checked in pre-compiled version, or a mixture of the two? Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Please see my forthcoming mail, explaining this(I didn't want to include it in this mail, because it would make it too cluttered). Please go read the Debian Social Contract(#1), and the Debian Free Software Guidelines(DFSG, #2), before continuing on with the rest of this email. It has some bearing on general nature of what follows. The reason I have been pushing so much for a release of JBoss that will not have the precompiled sources, is that these sources, while some being non-free(I'll explain more about this in a bit), are not under the control of JBoss. JBoss should not be concerned with the issues that occur with these external entities, except when they affect JBoss. In Debian, these packages will not just affect JBoss, but affect all software that uses them. This means that each external entity should handle its own issues, and they should not be all lumped together with another. As far are Debian is concerned, JBoss can do whatever they want, and can distribute whatever JBoss wants. However, to actually have JBoss become included with Debian, all license issues have to be resolved(either by using free versions of software, or by placing a package into contrib, and having broken dependencies). Inclusion in Debian is a very worthwhile goal, as Debian is arguably the second largest linux distribution. In addition to that, Debian is built on the distributed free software development, on steroids. Everything is done online, in email, irc, and thru web. Inclusion into Debian main states something about the software so included. It states that the software is free, and only uses free software to do what it sets out to do. This is a very important statement to make. Inclusion into contrib is allowed for packages that themselves are free, but for whatever reason, depend on/use software that is not free. It is understood, that if a free version of a non-free package was available, then the package in contrib would use that instead. Non-free precompiled/bundled code: There are several bundles items in thirdparty and tools, that have restrictive license, that forbid redistribution. For instance, lets consider jaxp(#3): 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively Software), by the number of users and the class of computer hardware for which the corresponding fee has been paid. Having this available in cvs, for download by end users, and as part of the precompiled tarball, in addition to the source download, goes against internal use only. However, in section 1 of the supplemental agreement, there is more discussion about this point. See below. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse
Re: [JBoss-dev] can't build jboss from cvs
I didn't want to move stuff I planned to replace. If and when I get new pools written they will be in connector. I think no other parts of jboss are using the jbosspool, I don't know about other people. david On 2001.11.15 19:52:14 -0500 Jason Dillon wrote: I don't have a strong feeling either way. Less modules would be simplier and probably a bit faster, so unless there are compelling reasons to have them seperate I would say move the pool stuff into connector (assuming that only connector is every expected to depend on this stuff). --jason On Thu, 15 Nov 2001, David Jencks wrote: My current opinion is --jbosspool may be very good for some things, but has way too much speculative functionality for a comprehensible jca ConnectionManager. It is also too complicated to find bugs in (and there are serious bugs) --Both jbosspool and the ConnectionManagers are under X license. Aaron doesn't seem interested in changing the license on the files he wrote. My goal is to write a simpler, better working pool implementation with exactly what is needed for ConnectionManagers, and replace all the X code. At least one person has expressed interest in the jbosspool stuff for other purposes, so I'm really not sure what to do with it. david jencks On 2001.11.15 18:26:50 -0500 Jason Dillon wrote: Out of curiousity, where does connector (jbosscx) fit into your packaging scheme? For 3.0 you might consider putting the contents of pool and connector into one package (if they aren't already) as pool is now small and only used by jbosscx. Why not move the pool stuff into jboss/connector (jbosscx) and drop pool? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: LONG: RE: [JBoss-dev] can't build jboss from cvs
I don't think my statement was harsh. I run Debian on some of my servers, and always wondered why people bitched about Debian. Now I know. Also, just because people bitch doesn't make it bad. I was voting to not build a DEB, because it appears to take a lot of work to remove all the dependencies. Instead we build an RPM (not RMP) and include everything as it is. The point is an easy install for Unix right? Or are we trying to please the Debian folks? As a final not, just because our code is LPGL, has no bearing on the binary distribution. You can take the code and do what ever you want. -dain -Original Message- From: Andrew Scherpbier [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 6:59 PM To: JBoss Development Subject: Re: LONG: RE: [JBoss-dev] can't build jboss from cvs Sorry to bud in here, but I think this statement is a little harsh. I think these licensing issues that Adam raises are very relevant to all of the JBoss project! JBoss is licensed under LGPL, right? So does JBoss include JAXP? If not, then it certainly shouldn't be part of the source distribution. If it is, then there are some licensing issues that need to be worked out. (You can't just arbitrarily call someone elses code licensed under LGPL!) I assume you meant 'rpm' (Redhat Package Manager). How do these issues that Adam raises *not* affect any other sort of distribution, including a windows installer or something like that? BTW, isn't voting about whether a debian package is allowed against the LGPL? (Or at least the spirit of LGPL?) I am no licensing expert but this seems like a weird solution to me and sound to me like you are trying to ignore these serious licensing issues. Dain Sundstrom wrote: No wonder people bitch about Debian. I vote we forget the DEB and just build an RMP, which Debian can install. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Application.java
User: d_jencks
Date: 01/11/15 17:33:50
Modified:src/main/org/jboss/ejb Application.java
Log:
Reenabled calling destroy on containers: now from stop
Revision ChangesPath
1.21 +11 -4 jboss/src/main/org/jboss/ejb/Application.java
Index: Application.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Application.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- Application.java 2001/11/15 05:30:54 1.20
+++ Application.java 2001/11/16 01:33:50 1.21
@@ -28,7 +28,7 @@
* @see ContainerFactory
*
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
- * @version $Revision: 1.20 $
+ * @version $Revision: 1.21 $
*/
public class Application
implements Service
@@ -185,11 +185,13 @@
// Service implementation
public void init() throws Exception {throw new Exception(don't call init);}
public void destroy(){}
-
/**
-* Starts all the containers of this application.
+* The mbean Service interface codestart/code method calls
+* the start method on each contatiner, then the init method on each
+* container. Conversion to a different registration system with one-phase
+* startup is conceivable.
*
-* @exception Exception
+* @exception Exception if an error occurs
*/
public void start() throws Exception
{
@@ -214,6 +216,11 @@
{
Container con = (Container)i.next();
con.stop();
+ }
+ for (Iterator i = containers.values().iterator(); i.hasNext();)
+ {
+ Container con = (Container)i.next();
+ con.destroy();
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
Ease up. I at least am relying on Marc's assurances that his (or JBoss Group's) lawyer checked out the licensing issues and we are ok. Issues with debian licensing policies are, well, periferal. It's pretty easy to get jboss as is, a debian packaging would be kind of nice but I don't see it as crucial. I don't know how debian is normally distributed but if its on cd it will only be distributing obsolet versions. Keeping up to date even online will be hard unless there is an automated update system. I don't understand the advantages of multiple distribution locations or mechanisms. We are not jakarta-ant, where the committers appear to spend an appreciable fraction of their time vetoing each others proposals. Here, vote generally means Lets do this, what do you think?. thanks david jencks On 2001.11.15 19:58:52 -0500 Andrew Scherpbier wrote: Sorry to bud in here, but I think this statement is a little harsh. I think these licensing issues that Adam raises are very relevant to all of the JBoss project! JBoss is licensed under LGPL, right? So does JBoss include JAXP? If not, then it certainly shouldn't be part of the source distribution. If it is, then there are some licensing issues that need to be worked out. (You can't just arbitrarily call someone elses code licensed under LGPL!) I assume you meant 'rpm' (Redhat Package Manager). How do these issues that Adam raises *not* affect any other sort of distribution, including a windows installer or something like that? BTW, isn't voting about whether a debian package is allowed against the LGPL? (Or at least the spirit of LGPL?) I am no licensing expert but this seems like a weird solution to me and sound to me like you are trying to ignore these serious licensing issues. Dain Sundstrom wrote: No wonder people bitch about Debian. I vote we forget the DEB and just build an RMP, which Debian can install. -dain -Original Message- From: Adam Heath [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 15, 2001 6:20 PM To: Jason Dillon Cc: David Maplesden; JBoss Development Subject: LONG: RE: [JBoss-dev] can't build jboss from cvs On Thu, 15 Nov 2001, Adam Heath wrote: Is everything in thirdparty exact copies of external libraries, that get built, or just checked in pre-compiled version, or a mixture of the two? Everything from thirdparty and tools are pre-compiled. This is bad. If these were to be in the tarball that was used for building of Debian packages, then the source package could not be uploaded to Debian. Please see my forthcoming mail, explaining this(I didn't want to include it in this mail, because it would make it too cluttered). Please go read the Debian Social Contract(#1), and the Debian Free Software Guidelines(DFSG, #2), before continuing on with the rest of this email. It has some bearing on general nature of what follows. The reason I have been pushing so much for a release of JBoss that will not have the precompiled sources, is that these sources, while some being non-free(I'll explain more about this in a bit), are not under the control of JBoss. JBoss should not be concerned with the issues that occur with these external entities, except when they affect JBoss. In Debian, these packages will not just affect JBoss, but affect all software that uses them. This means that each external entity should handle its own issues, and they should not be all lumped together with another. As far are Debian is concerned, JBoss can do whatever they want, and can distribute whatever JBoss wants. However, to actually have JBoss become included with Debian, all license issues have to be resolved(either by using free versions of software, or by placing a package into contrib, and having broken dependencies). Inclusion in Debian is a very worthwhile goal, as Debian is arguably the second largest linux distribution. In addition to that, Debian is built on the distributed free software development, on steroids. Everything is done online, in email, irc, and thru web. Inclusion into Debian main states something about the software so included. It states that the software is free, and only uses free software to do what it sets out to do. This is a very important statement to make. Inclusion into contrib is allowed for packages that themselves are free, but for whatever reason, depend on/use software that is not free. It is understood, that if a free version of a non-free package was available, then the package in contrib would use that instead. Non-free precompiled/bundled code: There are several bundles items in thirdparty and tools, that have restrictive license, that forbid redistribution. For instance, lets consider jaxp(#3): 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of
Re: [JBoss-dev] Destroy not called
I'm trying to remove destroy from mbean services. If you dont need 2phase shutdown then moving to stop would be best (IMHO). I see you moved the code already, however I will re-enable calling destroy after stop in Application anyway in case there are other places it is needed. thanks david jencks On 2001.11.15 19:21:35 -0500 Dain Sundstrom wrote: Destroy is not called on my persistence store anymore. Is destroy no longer supported? I don't use stop so I could move my code back into stop, but I can't speak for any other code. -dain ___ 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: LONG: RE: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, Jason Dillon wrote: Woah... this is a bit much for me to troll over at the moment... but here are some comments based on a brief look. Yeah, it took quite a bit to write as well. I've spent quite a bit of time today in email, not getting much real coding work done. :( First, I don't really care about the details of debian stuff. If you do that is greate. Sure. There's no need for you to know how to create a deb. Let me do that. Once it is done, then it is easy to understand. But the creation can be a bitch. Sounds like we need to split up these non-free bits from the free bits. I am all for that. How do we do that and still allow the build system to work with little to no user or bs/lib maintainer overhead? Your suggestion below of 2 separate zips/tars is fine by me. It looks like there is no way jboss could be put directly into 'main', since it depends on non-free software to do what it sets out to do. So I would guess it would go into contrib, honestly I don't really care which module it goes into. This is correct. It would be nice if evey debian os came with JBoss by default if the user wants J2EE, JMX or advanced java server support, but why not simply provide our own packages, and provide docs on the lines to add to the apt-get config file? My goal is to have it in Debian. It will get a wider audience that way. However, there is nothing precluding JBoss from having debs hosted on jboss.org. Why do we need to provide a source package which contains all 'free' only sources? If you need to do that, simply take a release from 'jboss-all/build/build.sh release', strip out the bits you deem non-free, hook those non-free bits up into the dependencies, then turn what is left over into a package. Because then it is really free? If anything inside a bundle is not free, it taints the entire bundle. I want the 'free' zip/tar to be available for download from jboss.org, so that I can reference an md5sum for it, to show that I haven't modified the code. If you really need a untouched release from JBoss with out these, then we need to think about how that would be possible, if that would be possible. Yes, I really would like this. I am open to ideas on how to seperate these, though I can tell you that things like 'go download x from x.com, y from y.com' and so on will not fly. I would expect that if this worked at all it would be, here is the jboss-xxx.zip with LGPL and here is jboss-thirdparty-xxx.zip with (long list of varing licenses which allow us to distribute it). A user would then unzip each at the same level and have a happy release to start using. cvs co jboss-all cd jboss-all # this gives jboss*, plus tools and thirdparty. ant build free-dist # This creates zips/tars of everything BUT tools/thirdparty. ant build nonfree-dist # This creates zips/tars of tools/thirdparty. ant build dist # This creates zips/tars of everything. Doing simple exlusions like above seems easy to do. I don't care how jboss is stored in cvs. I'm just interested in the final files that get downloaded. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: LONG: RE: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, Dain Sundstrom wrote: No wonder people bitch about Debian. People don't need licensing issues to bitch about debian. Hell, even the developers bitch about the inane problems that occur. Alot of this hardship stems from the fact that, in reality, Debian is a political organization. This leads to people getting all worked up emotionally, and that leads to clouding of facts and other figures. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs navigation.jsp
User: user57 Date: 01/11/15 18:12:24 Modified:src/docs navigation.jsp Log: o added hr to the top of each navigation.jsp, so the nav buttons do not get confused with the page content. o changed ul elements in team.jsp to be of class text so they get the better looking font. Really need to fix up the stylesheet so that we don't have to set the class of each p, ol and ul to the default of text, but only for the rare cases. o removed Ant bits from cvs.jsp, added link to buildsystem.jsp Revision ChangesPath 1.13 +5 -1 newsite/src/docs/navigation.jsp Index: navigation.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/navigation.jsp,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- navigation.jsp2001/11/08 19:06:21 1.12 +++ navigation.jsp2001/11/16 02:12:24 1.13 @@ -1,4 +1,8 @@ - p class=textfont size=-1ba class=link href=/index.jspHOME/a/b/font + p class=text + hr + font size=-1 + ba class=link href=/index.jspHOME/a/b + /font /div/tdtdimg src=/pictures/t.gif width=15 height=1/td ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
I want the 'free' zip/tar to be available for download from jboss.org, so that I can reference an md5sum for it, to show that I haven't modified the code. If we seperate the thirdparty, then this will be the case... though you MUST have the required thirdparty versions at the correct version for things to work. Let me think about how I might make this easy to do. I am open to ideas on how to seperate these, though I can tell you that things like 'go download x from x.com, y from y.com' and so on will not fly. I would expect that if this worked at all it would be, here is the jboss-xxx.zip with LGPL and here is jboss-thirdparty-xxx.zip with (long list of varing licenses which allow us to distribute it). A user would then unzip each at the same level and have a happy release to start using. cvs co jboss-all cd jboss-all # this gives jboss*, plus tools and thirdparty. ant build free-dist # This creates zips/tars of everything BUT tools/thirdparty. ant build nonfree-dist # This creates zips/tars of tools/thirdparty. ant build dist # This creates zips/tars of everything. You will still need to use 'build.sh', 'ant' won't work. Can you continue based on the current build, simply pretent that the non-free stuff isn't there and will be required. Todo this simply 'build/build.sh', then remove the non-free stuff (and document that for me) and go about your biz. Once I have time and can figure out a way to elegantly build seperate archives I will change this so you don't have to scrap out the non-free stuff. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/common team.jsp
User: user57 Date: 01/11/15 18:12:24 Modified:src/docs/common team.jsp Log: o added hr to the top of each navigation.jsp, so the nav buttons do not get confused with the page content. o changed ul elements in team.jsp to be of class text so they get the better looking font. Really need to fix up the stylesheet so that we don't have to set the class of each p, ol and ul to the default of text, but only for the rare cases. o removed Ant bits from cvs.jsp, added link to buildsystem.jsp Revision ChangesPath 1.14 +28 -37newsite/src/docs/common/team.jsp Index: team.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/common/team.jsp,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- team.jsp 2001/11/09 03:43:10 1.13 +++ team.jsp 2001/11/16 02:12:24 1.14 @@ -537,19 +537,17 @@ table tr - - td width=50% - ul - liAnatoly Akkerman - liToby Allsop + ul class=text + liAnatoly Akkerman + liToby Allsop liPaul Austin liRichard Backhouse liAhmed Bakayoko liHolger Baxmann liVladimir Blagojevic - liEdward Bridges + liEdward Bridges liSimone Bordet liJoel Boehland liIngo Bruel @@ -562,35 +560,31 @@ liTom Cook liMarkus Cozowicz liStacy Curl - liClint Dalton + liClint Dalton liDarius Davidavicius liEdwin DeSouza liJason Dillon - liAdrian Durkin - liPeter Fagerlund + liAdrian Durkin + liPeter Fagerlund liTobias Frech liMichel Groot liHeitzso liVincent Harcq - liTommy Helstrom + liTommy Helstrom liGabor Herr liLars Hoflansl - liDavid Jencks - liKen Jenks + liDavid Jencks + liKen Jenks liMichael J - - - /ul /td + td width=50% - - ul - - liJeremiah Johnson + ul class=text + liJeremiah Johnson liEdward Kenworthy liChris Kimpton - liOlaf Klischat + liOlaf Klischat liAlexander Kogan liRoberto Leong liAdi Lev @@ -601,20 +595,20 @@ liBrett McLaughlin liDewayne McNair liJoel Memes - liVinay Menon - liRichard Monson-Haefel - liPedro Mota + liVinay Menon + liRichard Monson-Haefel + liPedro Mota liMichael Mullis liFulco Muriglio liKeith Musser liMariusz Novostawski liLuan OCarrol liKunle Odutola - liFarrid Oudjaneff + liFarrid Oudjaneff liLennart Petersson - liGreg Pierce + liGreg Pierce liHugo Jose Pinto - liLuke Taylor + liLuke Taylor liVadim Tkachenko liSebastien Sahuc liSandeep @@ -623,23 +617,21 @@ liKesha Sibilev liTrevor Squires liJon Stevens - liMichael Stephens + liMichael Stephens liDain Sundstrom /ul /td + td width=50% - - ul - - - liMike Swainston-Rainford - liLuke Taylor - liPierrick Vaudour + ul class=text + liMike Swainston-Rainford + liLuke Taylor + liPierrick Vaudour liJason Vasquez
[JBoss-dev] CVS update: newsite/src/docs/developers cvs.jsp navigation.jsp
User: user57
Date: 01/11/15 18:12:24
Modified:src/docs/developers cvs.jsp navigation.jsp
Log:
o added hr to the top of each navigation.jsp, so the nav buttons do not
get confused with the page content.
o changed ul elements in team.jsp to be of class text so they get the
better looking font. Really need to fix up the stylesheet so that we
don't have to set the class of each p, ol and ul to the default
of text, but only for the rare cases.
o removed Ant bits from cvs.jsp, added link to buildsystem.jsp
Revision ChangesPath
1.8 +7 -26 newsite/src/docs/developers/cvs.jsp
Index: cvs.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/cvs.jsp,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- cvs.jsp 2001/11/15 18:24:58 1.7
+++ cvs.jsp 2001/11/16 02:12:24 1.8
@@ -85,37 +85,18 @@
libplugins/b: jboss-plugins
/ul
+ p class=headBuilding Guide and Instructions/p
+
+ p class=text
+ For information on building the sources please see our
+ a href=/developers/buildsystem.jspBuild System Guide/a
+ for further instructions.
+
p class=headCVS Administration Polcies/p
p class=text
For our policies on CVS versioning and branching see:
a class=link href=CVSAdmin.jspCVS Admin/a.
-
- p class=headMore information on Build and Source/p
-
- p class=text
- What is Ant? Ant is a Java based build tool. In theory it is kind
- of like make without makes wrinkles.
-
- p class=text
- Why? Why another build tool when there is already make, gnumake,
- nmake, jam, and others? Because, they are limited to the OS, or at
- least the OS type such as Unix, that you are working on. Makefiles
- are inherently evil as well.
-
- p class=text
- Ant is different. Instead a model where it is extended with shell
- based commands, it is extended using Java classes. Instead of
- writing shell commands, the configuration files are XML based
- calling out a target tree where various tasks get executed. Each
- task is run by an object which implements a particular Task
- interface. Granted, this removes some of the expressive power that
- is inherent by being able to construct a shell command such as
- `find . -name foo -exec rm {}` but it gives you the ability to be
- cross platform. To work anywhere and everywhere. And hey, if you
- really need to execute a shell command, Ant has an exec rule that
- allows different commands to be executed based on the OS that it is
- executing on.
p class=text
ul
1.9 +7 -3 newsite/src/docs/developers/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/navigation.jsp,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- navigation.jsp2001/11/08 19:06:21 1.8
+++ navigation.jsp2001/11/16 02:12:24 1.9
@@ -1,7 +1,11 @@
- p class=textfont size=-1ba style=class
href=/developers/index.jspHOME/a/b/font
+ p class=text
+ hr
+ font size=-1
+ ba style=class href=/developers/index.jspHOME/a/b
+ /font
- /div/td
- tdimg src=/pictures/t.gif width=15 height=1/td
+ /div/td
+ tdimg src=/pictures/t.gif width=15 height=1/td
/tr
/table
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, Jason Dillon wrote: cvs co jboss-all cd jboss-all # this gives jboss*, plus tools and thirdparty. ant build free-dist # This creates zips/tars of everything BUT tools/thirdparty. ant build nonfree-dist # This creates zips/tars of tools/thirdparty. ant build dist # This creates zips/tars of everything. You will still need to use 'build.sh', 'ant' won't work. s/ant/build.sh/, my bad. Can you continue based on the current build, simply pretent that the non-free stuff isn't there and will be required. Todo this simply 'build/build.sh', then remove the non-free stuff (and document that for me) and go about your biz. Once I have time and can figure out a way to elegantly build seperate archives I will change this so you don't have to scrap out the non-free stuff. I can continue with the bundled software as is. I will just not package the non-free stuff for now, waiting for you to think about how to do this. Once that is done, I will then also make debs for the non-free stuff, so that jboss.org can have everything online. However, the non-free stuff just won't get uploaded to Debian. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: LONG: RE: [JBoss-dev] can't build jboss from cvs
yOn Thu, 15 Nov 2001, Dain Sundstrom wrote: I don't think my statement was harsh. I run Debian on some of my servers, and always wondered why people bitched about Debian. Now I know. People run redhat. People bitch. People switch to Debian. People bitch. People join Debian. Debian maintainers bitch. I was voting to not build a DEB, because it appears to take a lot of work to remove all the dependencies. Instead we build an RPM (not RMP) and include everything as it is. The point is an easy install for Unix right? Or are we trying to please the Debian folks? You are confusing .deb with Debian. You can put whatever you want into a .deb. The same with an .rpm. However, to go into Debian, there is some policy that has to be followed. JBoss could be installed into /usr/local(or /opt), be in .deb and .rpm form, and everyone would be happy. It's only when being uploaded to Debian that there are rules that must be followed. As a final not, just because our code is LPGL, has no bearing on the binary distribution. You can take the code and do what ever you want. But you distribute non-lgpl code(in binary form) alongside your lgpl code. Has someone gone thru every single piece of external software, reading the license, to see if this is allowed? (my mail showed it was allowed for jaxp, but only for the initial downloader. If someone else were to redistribute what jboss makes available for download, then it is not allowed). ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 187 Successful tests: 146 Errors:26 Failures: 15 [time of test: 16 November 2001 3:12 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 187 Successful tests: 148 Errors:25 Failures: 14 [time of test: 16 November 2001 3:59 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 172 Successful tests: 135 Errors:23 Failures: 14 [time of test: 16 November 2001 5:24 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 187 Successful tests: 148 Errors:25 Failures: 14 [time of test: 16 November 2001 6:23 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
Can you continue based on the current build, simply pretent that the non-free stuff isn't there and will be required. Todo this simply 'build/build.sh', then remove the non-free stuff (and document that for me) and go about your biz. Once I have time and can figure out a way to elegantly build seperate archives I will change this so you don't have to scrap out the non-free stuff. I can continue with the bundled software as is. I will just not package the non-free stuff for now, waiting for you to think about how to do this. Once that is done, I will then also make debs for the non-free stuff, so that jboss.org can have everything online. However, the non-free stuff just won't get uploaded to Debian. I thought you said that there were .debs available for the thirdparty stuff already. Perhaps I misunderstood. Is it possible to upload non-free stuff to debian at all? If not, then this is wasted effort as JBoss will not run without these componets. If there is, then lets package up each one from its current locatation and make is a seperate package and have jboss depend on it. Call them jboss-thirdparty-package or something. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: LONG: RE: [JBoss-dev] can't build jboss from cvs
On Thu, 15 Nov 2001, Jason Dillon wrote: I thought you said that there were .debs available for the thirdparty stuff already. Perhaps I misunderstood. For some stuff, but not all. Is it possible to upload non-free stuff to debian at all? If not, then this is wasted effort as JBoss will not run without these componets. Some non-free stuff, yes. It is ok for a package in contrib to depend on something that is not available for installation in Debian. If there is, then lets package up each one from its current locatation and make is a seperate package and have jboss depend on it. Call them jboss-thirdparty-package or something. For JBoss.org, this is perfectly acceptable. However, for the real upload to Debian, this won't work, as I have said previously. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
