Re: [JBoss-dev] jboss-boot.jar log4j
I have this working and I'll check it in tomorrow after some more testing. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 9:24 PM Subject: Re: [JBoss-dev] jboss-boot.jar log4j That would be good assuming that we get as far as loading the Log4j service, if we don't then we don't have any logging information about the problem. Plus todo that we still need the log4j core classes... and well, we would also need our proxy generator since the log4j bits are not interfaces and thus we can't make use of the java.lang.reflect.Proxy bits. I think that we might want to create a buffered appender, have the default configuration log to System.out, then once the service is up, flush the buffer to the users configured appenders and remove it. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
David, 100% agree with you! Our architecture consists of independent services having their own build and runtime configuration. However we also do a master build that dynamically composes the services into one deployment configuration. In 3.0 it just means copying specified archives (with *-service.xml inside) to the deploy directory. Clean and straightforward! In 2.x we had to create an additional ANT's task that was merging the configuration of each service into one master jboss.jcml file. Messy! On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. Jiri. On Thu, 6 Dec 2001 15:04:48 -0500, you wrote: Marc, don't throw the baby out with the bath water. I agree the current situation is too confusing. However, IMHO, one of the main benefits of the multi-sar/service.xml packaging is exactly the control you get from so many files. It divides pieces of the server up into chunks you don't need to understand in order to select or use. For instance, to add or remove jbossmq, you just add/remove ONE FILE. You don't need to know anything about whats in it. To add or remove jetty, it's ONE FILE. To switch dbs you switch one file. If you put everything into the master jboss-service.xml you will lose the ability to construct the server you want out of complete pieces, and will have to figure out by hoping the comments are still accurate which mbeans go with which chunk of functionality. I've noticed that virtually noone seems to have noticed that you can force jboss to use the db of your choosing simply by replacing the hypersonic db config with one for your favorite database, and eliminating the hsqldb mbean. So, I don't think asking users to configure a large jboss-service.xml file for the particular pieces they want is realistic. With regard to adding stuff to the base jboss-service.xml, I don't recommend it, unless your mbeans really only depend on the beans in that file. I think in the long run it will be way more confusing. I think the best solution is to include a jboss-service.xml file in the ear for your application. (I'm not sure if this is working at the moment - there's some code for it in j2eedeployer, but I haven't tried it). Just my opinions. david jencks On 2001.12.06 13:52:36 -0500 marc fleury wrote: I AM WORKING ON IT RIGHT NOW Could somone possibly supply a v. brief summary of the current situation and what the final plan is? Some things it would be useful to know: The current situation is that simple jboss.jcml like deployment which was in the first Rabbit-hole release I did was removed to force the more advanced sar/dependency framework. for example: 1. I take it jboss-service.xml is loaded first - would it work if I put other (independent) services in here, even though it says not to ? See my previous mail, I am removing the comment, you are of course invited to put your mbeans in here. 2. Is the boot-server configuration only used for booting over the network - can we try this out just now, and how do you decide what configuration it obtains/supplies?? That I really don't know what it is doing there, see my previous mail on jetty here http://www.jboss.org/forums/thread.jsp?forum=66=4975 It's gone unless I hear from Jules in the next 30 seconds. 3. Why does the jetty mbean in the jboss-service.xml (in boot-server) refer to two files which don't exist (at least not in the current build): see above, 4. Do all my other services go in the deploy directory rather than conf/blah? This seems to make it a bit harder to set up several different static configurations (as you would do previously by just creating new dirs in jboss/conf). I guess the hot-deploy of services makes this less of an issue. this is where a feature made the default went haywire... the feature is can I hotdeploy parts of my server, example scenario (real life): a large fortune 1000 user is developing custom MBeans and they use it in their server, they want to hot-deploy the stuff to be able to DEVELOP FAST with JBoss as the infrastructure. In JBoss 2.x this is statically linked at boot time, we are building the modular kernel Linux2.0 style and that is good. SHOULD ALL THE CONFIGURATION GO THIS WAY ? hell no! can it? yes! should it? no! that is what imnsho david was missing. The work is done and is top class (REALLY) but it shouldn't be the default way to configure. About the only real criticism I have is that the support for adding base directory without specifying anything was removed, that was a mistake. 5. Should they be sars, or plain xml files, or does it matter. Are the sars only necessary if I want to supply additonal jar files without putting them in lib/ext? Good question that is something I am still thinking about here is my current understanding (disclaimer: research).
Re: [JBoss-dev] current mbean structure confusing
I definitely prefer the SAR kind of way to deploy services, even that i understand the maintenance problem. Would it be possible to have a 'global' service.xml file to be updated with new properties when a SAR is deployed with initial properties fetched from SAR xml. Then this 'global' service.xml file can be maintained easily during runtime (maybe changes in it can in some way be copied to the SAR xml also?). And then if a SAR is removed then it disappears from the 'global' service.xml file or put in an undeployed state. Hmmm, this sounds like the old jboss-auto.xml file... with all its problems... :-/ In our app we have an mbean acting as a Service Loader that is watching a directory where we dynamically can deploy/undeploy mbeans packed in jar files using m-let loading service. And it is s nice to add/remove services when everything is running. We can even extend our clients user interface with new dialogs linked to these new services without having to restart the client. Really cool :) More on that later... /Lennart ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
Lennart, I agree. I want as many services as possible in SARs. That way fixes can be hot deployed without bringing down the server, just a temporary unavailablity of the service and its dependents. Why can't the JBoss distribution have two configurations? Default, everything in one file for compatiblity with 2.4 Advanced?, everthing in deploy/*-service.xml or deploy/lib/*.sar Users migrating from 2.4 only need to know jboss.jcml is now jboss-service.xml Users who want the easier hot deploy can start the server with the advanced configuration. Regards, Adrian From: Lennart Petersson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] current mbean structure confusing Date: Fri, 7 Dec 2001 11:22:07 +0100 I definitely prefer the SAR kind of way to deploy services, even that i understand the maintenance problem. Would it be possible to have a 'global' service.xml file to be updated with new properties when a SAR is deployed with initial properties fetched from SAR xml. Then this 'global' service.xml file can be maintained easily during runtime (maybe changes in it can in some way be copied to the SAR xml also?). And then if a SAR is removed then it disappears from the 'global' service.xml file or put in an undeployed state. Hmmm, this sounds like the old jboss-auto.xml file... with all its problems... :-/ In our app we have an mbean acting as a Service Loader that is watching a directory where we dynamically can deploy/undeploy mbeans packed in jar files using m-let loading service. And it is s nice to add/remove services when everything is running. We can even extend our clients user interface with new dialogs linked to these new services without having to restart the client. Really cool :) More on that later... /Lennart ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ 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
[JBoss-dev] [ jboss-Bugs-490156 ] Can't persist ArrayList field using BLOB
Bugs item #490156, was opened at 2001-12-07 00:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=490156group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Rune Hamnvik (runeh) Assigned to: Nobody/Anonymous (nobody) Summary: Can't persist ArrayList field using BLOB Initial Comment: I'am using JBoss 3.0.0alpha and the new CMP 2.0 implementation, and I have problem persisting an ArrayList cmr field using BLOB in MySQL. I have done this often with previous versions of JBoss and it has been working fine all the time. When I am creating a bean with a ArrayList cmr field all seem to work fine. The values seems to be stored and the size is correct. But when I later fetches the bean using either findAll or findByPrimaryKey, all fields in the bean are correct except for the ArrayList. It has now the size of zero. Test case is attached. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=490156group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
Jiri, do not overquote please David, 100% agree with you! Our architecture consists of independent services having their own build and runtime configuration. However we also do a master build that dynamically composes the services into one deployment configuration. In 3.0 it just means copying specified archives (with *-service.xml inside) to the deploy directory. Clean and straightforward! In 2.x we had to create an additional ANT's task that was merging the configuration of each service into one master jboss.jcml file. Messy! Having 10 configuration files for newbies is a clear mistake. It is that simple. We are not saying that we will prevent you from shipping many xml services, as they are very useful. The microkernel is there to allow hotdeploy of independent services. On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-472072 ] INSERTING AN ALREADY EXISTING BEAN, ID =
Bugs item #472072, was opened at 2001-10-17 07:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=472072group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: INSERTING AN ALREADY EXISTING BEAN, ID = Initial Comment: Using CMP 2.0 when calling a entity remote home's create I get the following: [Default] java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = 111; nested exception is: java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = 111 [Default] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = 111 [Default] at org.jboss.ejb.plugins.AbstractInstanceCache.insert(AbstractInstanceCache.java:249) [Default] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:166) [Default] at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:104) [Default] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:100) [Default] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:156) [Default] at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:56) [Default] at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:106) [Default] at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109) [Default] at org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:441) [Default] at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(JRMPContainerInvoker.java:421) [Default] at org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invokeHome(HomeProxy.java:237) [Default] at org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:182) [Default] at $Proxy16.create(Unknown Source) [Default] at _0002feditCustomer_0002ejspeditCustomer_jsp_0._jspService(_0002feditCustomer_0002ejspeditCustomer_jsp_0.java:141) [Default] at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) [Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [Default] at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:176) [Default] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:307) [Default] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380) [Default] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [Default] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:488) [Default] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387) [Default] at org.mortbay.http.HandlerContext.handle(HandlerContext.java:1040) [Default] at org.mortbay.http.HandlerContext.handle(HandlerContext.java:995) [Default] at org.mortbay.http.HttpServer.service(HttpServer.java:683) [Default] at org.mortbay.http.HttpConnection.service(HttpConnection.java:732) [Default] at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:889) [Default] at org.mortbay.http.HttpConnection.handle(HttpConnection.java:746) [Default] at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:146) [Default] at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) [Default] at org.mortbay.util.ThreadPool$PoolThreadRunnable.run(ThreadPool.java:609) [Default] at java.lang.Thread.run(Thread.java:484) The key used is manualy specified and is 100% unique (not used before) in any bean. This happens for a bean that is on the Many side of a one-to-many relation with a foreign key. The ejbCreate() method of that bean just sets it's primary key and some attributes and ejbPostCreate() adds itself to the -to-many side of the related bean's Collection... This does not happen for a related bean which uses similar ejbCreate() and empty ejbPostCreate() methods. I tried to use Commit option A and B. The result is the same. -- Comment By: stan pinte (stanpinte) Date: 2001-12-07 02:15 Message: Logged In: YES user_id=154693 hello, I will try to reproduce the bug. More on this soon. -- Comment By: Ole Husgaard (sparre) Date: 2001-10-18 08:13 Message: Logged In: YES user_id=175257 Looks like the cache somehow got out of sync. This may be related to bug #463548 -- Comment By: Peter Levart (plevart) Date: 2001-10-18 06:59 Message: Logged In: YES user_id=346981 Investigating further I found that this exception is thrown after the bean's ejbCreate
RE: [JBoss-dev] current mbean structure confusing
On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
|So, in the initializer bean, I have to put a MBean ref for every EJB I use? |What a pain! Why can't MBean deployment be held up until the AutoDeployer |finishes? So that you could have an MBean with a dependency on the |AutoDeployer, and that would be that? I agree, write it, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Friday, December 07, 2001 9:48 AM To: marc fleury; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] current mbean structure confusing On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? One more thing. As a user, you're going to have to figure out what the hell the MBean name is for the EJB as well. Maybe I'm just being lazy ___ 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/jrmp12/interfaces EntityProxy.java HomeProxy.java ListEntityProxy.java StatefulSessionProxy.java StatelessSessionProxy.java
User: mnf999 Date: 01/12/07 07:42:45 Removed: src/main/org/jboss/ejb/plugins/jrmp12/interfaces EntityProxy.java HomeProxy.java ListEntityProxy.java StatefulSessionProxy.java StatelessSessionProxy.java Log: Deprecating 1.2 support and moving proxy generation to its own package ___ 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/jrmp/server JRMPContainerInvoker.java
User: mnf999
Date: 01/12/07 07:48:07
Modified:src/main/org/jboss/ejb/plugins/jrmp/server
JRMPContainerInvoker.java
Log:
TEMPORARY: so that you guys can compile for today but the whole JRMP package here is
going away, replaced with new proxies, this is just so that it compiles and it should
be replaced soon (in fact removed)
Revision ChangesPath
1.47 +3 -2
jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java
Index: JRMPContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- JRMPContainerInvoker.java 2001/11/26 03:12:28 1.46
+++ JRMPContainerInvoker.java 2001/12/07 15:48:07 1.47
@@ -65,7 +65,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
-* @version $Revision: 1.46 $
+* @version $Revision: 1.47 $
*/
public class JRMPContainerInvoker
extends RemoteServer
@@ -603,7 +603,8 @@
// Create delegate depending on JDK version
if (jdk122)
{
- ciDelegate = new
org.jboss.ejb.plugins.jrmp12.server.JRMPContainerInvoker(this);
+ throw new Error(You need a 1.3 JVM (Proxy package) to run JBoss, you are
running a 1.2.2 or earlier version);
+ //ciDelegate = new
org.jboss.ejb.plugins.jrmp12.server.JRMPContainerInvoker(this);
} else
{
ciDelegate = new
org.jboss.ejb.plugins.jrmp13.server.JRMPContainerInvoker(this);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss build failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/JMSNotificationListenerMBean.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/ListenerMBean.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/ListenerRegistration.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/ManagementBean.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/PollingClientNotificationListener.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/PollingNotificationListener.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/PollingNotificationListenerMBean.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/RMIClientNotificationListener.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/RMIClientNotificationListenerInterface.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/RMINotificationListener.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/RMINotificationListenerMBean.java... [xdoclet] Loading source file /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/management/mejb/SearchClientNotificationListener.java... [xdoclet] Constructing Javadoc information... [xdoclet] javadoc: warning - Cannot find class org.jboss.management.mejb.MEJB [xdoclet] javadoc: warning - Import not found: org.jboss.management.mejb.MEJB - ignoring! [xdoclet] Create Remote Interface for: org.jboss.management.mejb.ManagementBean [xdoclet] Create Session Class for: org.jboss.management.mejb.ManagementBean [xdoclet] Create ejb-jar.xml [xdoclet] Create jboss.xml [xdoclet] Create jaws.xml [xdoclet] 2 warnings compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/server/output/classes [javac] Compiling 605 source files to /disk/orig/home/lubega/jbossro/jboss-all/server/output/classes /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:10: warning: java.security.Identity in java.security has been deprecated import java.security.Identity; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:214: warning: java.security.Identity in java.security has been deprecated public Identity getCallerIdentity() ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:340: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:340: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java:606: cannot resolve symbol symbol : class JRMPContainerInvoker location: package server ciDelegate = new org.jboss.ejb.plugins.jrmp12.server.JRMPContainerInvoker(this); ^ 1 error 4 warnings BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:376: Compile failed, messages should have been provided. Total time: 1 minute 10 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-490187 ] ejbSelect problem
Bugs item #490187, was opened at 2001-12-07 04:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=490187group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Julien Viet (cooperfbi) Assigned to: Nobody/Anonymous (nobody) Summary: ejbSelect problem Initial Comment: 2 beans A and B B is tied to A with a 1-n relation : .A ownes several instance of B .B ownes an instance of A there is an ejbSelect in A that should return instances of B that are in relation with an instance of A : ejbSelectSomeBeans(A a) - SELECT OBJECT(b) FROM B AS b WHERE b.a = ?1 problem : ejbSelect return instances of local A instead of local B. I have included a complete test case. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=490187group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/jdo/castor CastorJDOImpl.java
User: mnf999 Date: 01/12/07 07:50:56 Modified:varia/src/main/org/jboss/jdo/castor CastorJDOImpl.java Log: The proxy generation is in its own package Revision ChangesPath 1.8 +4 -4 contrib/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java Index: CastorJDOImpl.java === RCS file: /cvsroot/jboss/contrib/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- CastorJDOImpl.java2001/11/26 03:24:54 1.7 +++ CastorJDOImpl.java2001/12/07 15:50:55 1.8 @@ -39,16 +39,16 @@ import org.jboss.logging.log4j.CategoryWriter; import org.jboss.system.ServiceMBeanSupport; -import org.jboss.proxy.Proxy; -import org.jboss.proxy.Proxies; -import org.jboss.proxy.InvocationHandler; +import org.jboss.proxy.compiler.Proxy; +import org.jboss.proxy.compiler.Proxies; +import org.jboss.proxy.compiler.InvocationHandler; /** * Castor JDO support * * @author Oleg Nitz ([EMAIL PROTECTED]) - * @version $Revision: 1.7 $ + * @version $Revision: 1.8 $ */ public class CastorJDOImpl extends ServiceMBeanSupport implements DataObjects, ObjectFactory, Referenceable, Serializable, ___ 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/jrmp12/server JRMPContainerInvoker.java
User: mnf999 Date: 01/12/07 07:44:12 Removed: src/main/org/jboss/ejb/plugins/jrmp12/server JRMPContainerInvoker.java Log: Deprecting 1.2 support moving proxy generation to compiler package ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss build failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
_buildmagic:init:buildlog:
configure:
_buildmagic:init:show-environment:
[echo]
project.root:/disk/orig/home/lubega/jbossro/jboss-all
module.root: /disk/orig/home/lubega/jbossro/jboss-all/plugins/varia
user.home: /home/lubega
build.compiler: ${build.compiler}
java.home: /opt/jdk1.3_ibm_20010723/jre
java.class.path:
/home/lubega/jbossro/jboss-all/tools/lib/xerces.jar:/home/lubega/jbossro/jboss-all/tools/lib/xdoclet.jar:/home/lubega/jbossro/jboss-all/tools/lib/xalan.jar:/home/lubega/jbossro/jboss-all/tools/lib/stylebook.jar:/home/lubega/jbossro/jboss-all/tools/lib/saxon.jar:/home/lubega/jbossro/jboss-all/tools/lib/pretty.jar:/home/lubega/jbossro/jboss-all/tools/lib/optional.jar:/home/lubega/jbossro/jboss-all/tools/lib/log4j-core.jar:/home/lubega/jbossro/jboss-all/tools/lib/junit.jar:/home/lubega/jbossro/jboss-all/tools/lib/jaxp.jar:/home/lubega/jbossro/jboss-all/tools/lib/JavaStyle.jar:/home/lubega/jbossro/jboss-all/tools/lib/fop.jar:/home/lubega/jbossro/jboss-all/tools/lib/crimson.jar:/home/lubega/jbossro/jboss-all/tools/lib/buildmagic-tasks.jar:/home/lubega/jbossro/jboss-all/tools/lib/bsf.jar:/home/lubega/jbossro/jboss-all/tools/lib/batik.jar:/home/lubega/jbossro/jboss-all/tools/lib/ant.jar:/opt/jdk1.3_ibm_20010723/lib/tools.jar
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
init:
compile-classes:
[mkdir] Created dir:
/disk/orig/home/lubega/jbossro/jboss-all/plugins/varia/output/classes
[javac] Compiling 6 source files to
/disk/orig/home/lubega/jbossro/jboss-all/plugins/varia/output/classes
/disk/orig/home/lubega/jbossro/jboss-all/plugins/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java:42:
cannot resolve symbol
symbol : class Proxy
location: package compiler
import org.jboss.proxy.compiler.Proxy;
^
/disk/orig/home/lubega/jbossro/jboss-all/plugins/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java:43:
cannot resolve symbol
symbol : class Proxies
location: package compiler
import org.jboss.proxy.compiler.Proxies;
^
/disk/orig/home/lubega/jbossro/jboss-all/plugins/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java:44:
cannot resolve symbol
symbol : class InvocationHandler
location: package compiler
import org.jboss.proxy.compiler.InvocationHandler;
^
3 errors
BUILD FAILED
/disk/orig/home/lubega/jbossro/jboss-all/plugins/varia/build.xml:311: Compile failed,
messages should have been provided.
Total time: 2 minutes 35 seconds
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-482875 ] OutOfMemory after many Deploy cycles
Bugs item #482875, was opened at 2001-11-17 12:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=482875group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: Works For Me
Priority: 7
Submitted By: Joel Boehland (jolby)
Assigned to: Scott M Stark (starksm)
Summary: OutOfMemory after many Deploy cycles
Initial Comment:
I have been seeing OutOfMemoryErrors in my server after
doing several deploy/redeploy cycles of my application
.ear file (which is around 3 megs in size)
Basic info:
*Hardware: AMD-K2-400MHz, 196MB RAM
*OS: linux 2.2.14
*jdk: Blackdown-1.3.0-FCS, mixed mode
*Server: JBoss-2.4.3_Jetty-3.1.3-1
*ServerTrace: I don't have one now, but I can provide
one later if needed.
*Steps to reproduce: Deploy/Redeploy .ear file many
times. My .ear is around 3 megs, so it may be necessary
to use a large one to trigger this effect.
Other info
*I have had this happen using native threads mode, and
green threads mode.
*Jozsa Kristof [EMAIL PROTECTED] has also reported
this error on the jboss-user list. He was using IBM jdk
1.3.0 on linux, so this doesn't appear to be tied to
any particular version of the jdk.
--Joel
--
Comment By: Adrian Brock (ejort)
Date: 2001-12-07 04:33
Message:
Logged In: YES
user_id=9459
The RemoteMethodInvocation leak also applies to EJB remote
calls.
Regards,
Adrian
--
Comment By: Adrian Brock (ejort)
Date: 2001-11-30 15:53
Message:
Logged In: YES
user_id=9459
Me again,
I figured out what the copy and add means the cache
doesn't have to be synchronized.
Adds can get lost, but that doesn't matter.
I've never seen this idiom before, nice!
It doesn't scale very well for large deployments, but all
the hit is at deployment time.
Noticed the ENCFactory fix has been committed.
Regards
Adrian
--
Comment By: Adrian Brock (ejort)
Date: 2001-11-28 02:32
Message:
Logged In: YES
user_id=9459
Apologies,
My post yesterday was based on a wrong assumption, although
the fix works.
I got it into my head that the cache in
RemoteMethodInvocation was keyed by className, it is
actually keyed by class. The class on a redeploy is
different (it comes from a different class loader) so there
is no chance of reusing old hash values from a previous
deployment.
I think my brain needs a Garbage Collector;-)
The only fix required is to remove the Method object from
the values side of the WeakHashMap.
The easiest way to do this is to key the HashMap created in
getInterfaces(Class) by the method signature string
returned by Method.toString().
So ignore the code in my previous post and use the
following changes in RemoteMethodInvocation.java
In getInterfaces(Class)
-map.put(method, new Long(hash));
+map.put(method.toString(), new Long(hash));
In calculateHash(Method)
-return ((Long)methodHashes.get(method)).longValue();
+return ((Long)methodHashes.get(method.toString
())).longValue();
The downside is that Method.toString() uses more memory
than the pointer Method.this, so the cache will be larger
than before when no redeploys are performed.
On a related point, what is the point of the code marked
// Copy and add
I think this should just be
hashMap.put(method.getDeclaringClass(), methodHashes);
but after my woolly thinking yesterday I wouldn't trust
myself to make toast at the moment.
Regards,
Adrian
--
Comment By: Adrian Brock (ejort)
Date: 2001-11-27 02:48
Message:
Logged In: YES
user_id=9459
You can let go now;-), I found the rest of the problem!
There is another a hard link cache in
org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation
This one is harder to spot.
I think the code in method calculateHash is wrong for two
reasons.
1) The cache (hashMap) is a WeakHashMap, but its values
contain HashMaps that have hard links to the application's
classes.
The garbage collector can't remove these, the weak
behaviour is in the keys.
2) You can't rely on the garbage collector to remove old
entries BEFORE the application is redeployed.
The old calculated hash values may still be in the cache
when JRMPContainerInvoke.init is run over the new bean.
This means it uses the (wrong? not sure how important this
is?) old hash values.
NOTE: ejb.plugins.local.BaseLocalContainerInvoker almost
certainly has the same problem.
My solution is make the cache a normal HashMap and get
JRMPContainerInvoker.destroy to remove its cached values,
ensuring the new bean has to recalculate them.
I think the changes should be: (I have no CVS access)
In RemoteInvocation.java
-static Map hashMap = new WeakHashMap();
+static Map hashMap = new HashMap();
public static long calculateHash(Method method)
{
Map methodHashes =
[JBoss-dev] [ jboss-Bugs-473842 ] Reconnecting a disconnected subscriber
Bugs item #473842, was opened at 2001-10-22 17:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=473842group_id=22866 Category: JBossMQ Group: v2.2.2 (stable) Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Reconnecting a disconnected subscriber Initial Comment: When a subscriber process to a topic is terminated, as a result of a crash or similar error type condition where normal disconnection from the server cannot be performed, The subscriber connection cannot be resurrected as the server still thinks that the subscriber is already connected. The work around is to restart the JMS server to clear the connections that it thinks exist. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=473842group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy InvocationHandler.java Proxies.java Proxy.java ProxyAssembler.java ProxyCompiler.java ProxyProxy.java Replaceable.java
User: mnf999 Date: 01/12/07 09:31:53 Removed: src/main/org/jboss/proxy InvocationHandler.java Proxies.java Proxy.java ProxyAssembler.java ProxyCompiler.java ProxyProxy.java Replaceable.java Log: Making room for the proxy ejb, separating the generation in its own compiler package ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy/compiler - New directory
User: mnf999 Date: 01/12/07 09:32:08 jboss/src/main/org/jboss/proxy/compiler - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss build failed
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |[EMAIL PROTECTED] |Sent: Friday, December 07, 2001 11:49 AM |To: [EMAIL PROTECTED] |Cc: [EMAIL PROTECTED] |Subject: [JBoss-dev] jboss build failed I will say this of your stuff Chris: It's right on top of the ball :) commiting the rest of it in cvs marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss build failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
if(instance instanceof Proxies.ProxyTarget) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:434:
cannot resolve symbol
symbol : class InvocationHandler
location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge
InvocationHandler handler =
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:435:
cannot resolve symbol
symbol : class ProxyTarget
location: package Proxies
((Proxies.ProxyTarget)instance).getInvocationHandler();
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:50:
cannot resolve symbol
symbol : variable Proxy
location: class org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
Object o = Proxy.newProxyInstance(classLoader, classes, handler);
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:54:
cannot resolve symbol
symbol : class InvocationHandler
location: class org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
o.getClass().getConstructor(new Class[]{InvocationHandler.class});
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/util/MBeanProxy.java:59:
cannot resolve symbol
symbol : variable Proxy
location: class org.jboss.util.MBeanProxy
return Proxy.newProxyInstance(intf.getClassLoader(),
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/util/MBeanProxy.java:80:
cannot resolve symbol
symbol : variable Proxy
location: class org.jboss.util.MBeanProxy
return Proxy.newProxyInstance
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/util/MBeanProxy.java:95:
cannot resolve symbol
symbol : variable Proxy
location: class org.jboss.util.MBeanProxy
return Proxy.newProxyInstance(intf.getClassLoader(),
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/util/MBeanProxy.java:112:
cannot resolve symbol
symbol : variable Proxy
location: class org.jboss.util.MBeanProxy
return Proxy.newProxyInstance(intf.getClassLoader(),
^
21 errors
4 warnings
BUILD FAILED
/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:376: Compile failed,
messages should have been provided.
Total time: 1 minute 3 seconds
___
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/bridge EntityBridgeInvocationHandler.java
User: mnf999
Date: 01/12/07 09:51:28
Modified:src/main/org/jboss/ejb/plugins/cmp/bridge
EntityBridgeInvocationHandler.java
Log:
fixed import statements
Revision ChangesPath
1.9 +2 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/EntityBridgeInvocationHandler.java
Index: EntityBridgeInvocationHandler.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/EntityBridgeInvocationHandler.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- EntityBridgeInvocationHandler.java2001/11/26 03:12:26 1.8
+++ EntityBridgeInvocationHandler.java2001/12/07 17:51:28 1.9
@@ -18,7 +18,7 @@
import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.EntityContainer;
import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.proxy.InvocationHandler;
+import org.jboss.proxy.compiler.InvocationHandler;
/**
* EntityBridgeInvocationHandler is the invocation hander used by the CMP 2.x
@@ -33,7 +33,7 @@
* One per cmp entity bean instance, including beans in pool.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class EntityBridgeInvocationHandler implements InvocationHandler {
protected EntityContainer container;
___
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/bridge JDBCEntityBridge.java
User: mnf999
Date: 01/12/07 09:50:21
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
JDBCEntityBridge.java
Log:
Import statements for proxy compilation
Revision ChangesPath
1.17 +3 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java
Index: JDBCEntityBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- JDBCEntityBridge.java 2001/12/02 01:41:46 1.16
+++ JDBCEntityBridge.java 2001/12/07 17:50:21 1.17
@@ -36,8 +36,8 @@
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCCMPFieldMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCRelationshipRoleMetaData;
-import org.jboss.proxy.Proxies;
-import org.jboss.proxy.InvocationHandler;
+import org.jboss.proxy.compiler.Proxies;
+import org.jboss.proxy.compiler.InvocationHandler;
/**
@@ -51,7 +51,7 @@
* One per cmp entity bean type.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
*/
public class JDBCEntityBridge implements EntityBridge {
protected JDBCEntityMetaData metadata;
___
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 JDBCCreateBeanClassInstanceCommand.java
User: mnf999
Date: 01/12/07 09:52:29
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCCreateBeanClassInstanceCommand.java
Log:
import statements
Revision ChangesPath
1.2 +3 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java
Index: JDBCCreateBeanClassInstanceCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JDBCCreateBeanClassInstanceCommand.java 2001/12/04 06:30:53 1.1
+++ JDBCCreateBeanClassInstanceCommand.java 2001/12/07 17:52:29 1.2
@@ -12,8 +12,8 @@
import org.jboss.ejb.EntityContainer;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge;
import org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler;
-import org.jboss.proxy.Proxy;
-import org.jboss.proxy.InvocationHandler;
+import org.jboss.proxy.compiler.Proxy;
+import org.jboss.proxy.compiler.InvocationHandler;
/**
* JDBCBeanClassInstanceCommand creates instance of the bean class. For
@@ -23,7 +23,7 @@
* FIX-MEshould not generat a subclass for ejb 1.1/FIX-ME
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class JDBCCreateBeanClassInstanceCommand {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util MBeanProxy.java
User: mnf999 Date: 01/12/07 09:53:39 Modified:src/main/org/jboss/util MBeanProxy.java Log: import statements Revision ChangesPath 1.8 +3 -3 jboss/src/main/org/jboss/util/MBeanProxy.java Index: MBeanProxy.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/MBeanProxy.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- MBeanProxy.java 2001/08/03 17:15:57 1.7 +++ MBeanProxy.java 2001/12/07 17:53:39 1.8 @@ -18,15 +18,15 @@ import javax.management.RuntimeMBeanException; import javax.management.RuntimeErrorException; -import org.jboss.proxy.Proxy; -import org.jboss.proxy.InvocationHandler; +import org.jboss.proxy.compiler.Proxy; +import org.jboss.proxy.compiler.InvocationHandler; /** * A factory for producing MBean proxies. * * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a. * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a - * @version $Revision: 1.7 $ + * @version $Revision: 1.8 $ */ public class MBeanProxy implements InvocationHandler ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss build failed
Dude,
I just fiinshed commiting the directory changes I had for the compiler proxy
stuff so I just did a clean co and it compiles, in the meantime you have
seen 3 times that it didn't :)
good for you but this should be the last of these messages,
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Friday, December 07, 2001 12:48 PM
|To: [EMAIL PROTECTED]
|Cc: [EMAIL PROTECTED]
|Subject: [JBoss-dev] jboss build failed
|
|
|
|=
|==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
|=
|
|HERE ARE THE LAST 50 LINES OF THE LOG FILE
|
| if(instance instanceof Proxies.ProxyTarget) {
|^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:434: cannot resolve symbol
|symbol : class InvocationHandler
|location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge
| InvocationHandler handler =
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:435: cannot resolve symbol
|symbol : class ProxyTarget
|location: package Proxies
| ((Proxies.ProxyTarget)instance).getInvocationHandler();
|^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:50: cannot
resolve symbol
|symbol : variable Proxy
|location: class
|org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
| Object o = Proxy.newProxyInstance(classLoader, classes, handler);
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:54: cannot
resolve symbol
|symbol : class InvocationHandler
|location: class
|org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
|o.getClass().getConstructor(new
|Class[]{InvocationHandler.class});
|^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:59: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance(intf.getClassLoader(),
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:80: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:95: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance(intf.getClassLoader(),
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:112: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance(intf.getClassLoader(),
| ^
|21 errors
|4 warnings
|
|BUILD FAILED
|
|/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:376:
|Compile failed, messages should have been provided.
|
|Total time: 1 minute 3 seconds
|
|___
|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] current mbean structure confusing
On 2001.12.07 09:47:31 -0500 Bill Burke wrote: On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? Having a dependency on the autodeployer won't do you much good, will it? The autodeploy being present doesn't mean any particular package is deployed. All the *service.xml and sars are deployed by the autodeployer at present, except for the one in conf/default I think we need mbeans for each package (application, ejb module, etc) that you can depend on. The deployment stuff I'm working on is based on this, but I am finding it slow going. david jencks ___ 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] jboss build failed
Dude,
Way to tell that script. :)
You forgot to add the classes to the new org.jboss.proxy.compiler package.
By the way, are you just moving the classes, or did you rewrite them?
-dain
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 07, 2001 12:01 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] jboss build failed
Dude,
I just fiinshed commiting the directory changes I had for the
compiler proxy
stuff so I just did a clean co and it compiles, in the
meantime you have
seen 3 times that it didn't :)
good for you but this should be the last of these messages,
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Friday, December 07, 2001 12:48 PM
|To: [EMAIL PROTECTED]
|Cc: [EMAIL PROTECTED]
|Subject: [JBoss-dev] jboss build failed
|
|
|
|=
|==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
|=
|
|HERE ARE THE LAST 50 LINES OF THE LOG FILE
|
| if(instance instanceof Proxies.ProxyTarget) {
|^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:434: cannot
resolve symbol
|symbol : class InvocationHandler
|location: class
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge
| InvocationHandler handler =
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:435: cannot
resolve symbol
|symbol : class ProxyTarget
|location: package Proxies
|
((Proxies.ProxyTarget)instance).getInvocationHandler();
|^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:5
0: cannot
resolve symbol
|symbol : variable Proxy
|location: class
|org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
| Object o = Proxy.newProxyInstance(classLoader,
classes, handler);
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:5
4: cannot
resolve symbol
|symbol : class InvocationHandler
|location: class
|org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
|o.getClass().getConstructor(new
|Class[]{InvocationHandler.class});
|^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:59: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance(intf.getClassLoader(),
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:80: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:95: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance(intf.getClassLoader(),
| ^
|/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
|util/MBeanProxy.java:112: cannot resolve symbol
|symbol : variable Proxy
|location: class org.jboss.util.MBeanProxy
| return Proxy.newProxyInstance(intf.getClassLoader(),
| ^
|21 errors
|4 warnings
|
|BUILD FAILED
|
|/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:376:
|Compile failed, messages should have been provided.
|
|Total time: 1 minute 3 seconds
|
|___
|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] jboss build failed
this is just a move, and it should be there, it is to make way for the
org.jboss.proxy.ejb package which is the proxy stuff independently of the
invokers type. the proxy generation was hogging the org.jboss.proxy package
so got moved to org.jboss.proxy.compiler.
I have updated all the classes that depended on it (including yours) and did
a clean co bla bla bla
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
|Sundstrom
|Sent: Friday, December 07, 2001 1:30 PM
|To: 'marc fleury'; [EMAIL PROTECTED];
|[EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] jboss build failed
|
|
|Dude,
|
|Way to tell that script. :)
|
|You forgot to add the classes to the new org.jboss.proxy.compiler package.
|By the way, are you just moving the classes, or did you rewrite them?
|
|-dain
|
| -Original Message-
| From: marc fleury [mailto:[EMAIL PROTECTED]]
| Sent: Friday, December 07, 2001 12:01 PM
| To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Subject: RE: [JBoss-dev] jboss build failed
|
|
| Dude,
|
| I just fiinshed commiting the directory changes I had for the
| compiler proxy
| stuff so I just did a clean co and it compiles, in the
| meantime you have
| seen 3 times that it didn't :)
|
| good for you but this should be the last of these messages,
|
| marcf
|
|
| |-Original Message-
| |From: [EMAIL PROTECTED]
| |[mailto:[EMAIL PROTECTED]]On Behalf Of
| |[EMAIL PROTECTED]
| |Sent: Friday, December 07, 2001 12:48 PM
| |To: [EMAIL PROTECTED]
| |Cc: [EMAIL PROTECTED]
| |Subject: [JBoss-dev] jboss build failed
| |
| |
| |
| |=
| |==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
| |=
| |
| |HERE ARE THE LAST 50 LINES OF THE LOG FILE
| |
| | if(instance instanceof Proxies.ProxyTarget) {
| |^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:434: cannot
| resolve symbol
| |symbol : class InvocationHandler
| |location: class
| org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge
| | InvocationHandler handler =
| | ^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java:435: cannot
| resolve symbol
| |symbol : class ProxyTarget
| |location: package Proxies
| |
| ((Proxies.ProxyTarget)instance).getInvocationHandler();
| |^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:5
| 0: cannot
| resolve symbol
| |symbol : variable Proxy
| |location: class
| |org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
| | Object o = Proxy.newProxyInstance(classLoader,
| classes, handler);
| | ^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| ejb/plugins/cmp/jdbc/JDBCCreateBeanClassInstanceCommand.java:5
| 4: cannot
| resolve symbol
| |symbol : class InvocationHandler
| |location: class
| |org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateBeanClassInstanceCommand
| |o.getClass().getConstructor(new
| |Class[]{InvocationHandler.class});
| |^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| |util/MBeanProxy.java:59: cannot resolve symbol
| |symbol : variable Proxy
| |location: class org.jboss.util.MBeanProxy
| | return Proxy.newProxyInstance(intf.getClassLoader(),
| | ^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| |util/MBeanProxy.java:80: cannot resolve symbol
| |symbol : variable Proxy
| |location: class org.jboss.util.MBeanProxy
| | return Proxy.newProxyInstance
| | ^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| |util/MBeanProxy.java:95: cannot resolve symbol
| |symbol : variable Proxy
| |location: class org.jboss.util.MBeanProxy
| | return Proxy.newProxyInstance(intf.getClassLoader(),
| | ^
| |/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/
| |util/MBeanProxy.java:112: cannot resolve symbol
| |symbol : variable Proxy
| |location: class org.jboss.util.MBeanProxy
| | return Proxy.newProxyInstance(intf.getClassLoader(),
| | ^
| |21 errors
| |4 warnings
| |
| |BUILD FAILED
| |
| |/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:376:
| |Compile failed, messages should have been provided.
| |
| |Total time: 1 minute 3 seconds
| |
| |___
| |Jboss-development mailing list
| |[EMAIL PROTECTED]
| |https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
|
Re: [JBoss-dev] jboss build failed
on 1-12-07 19.01, marc fleury at [EMAIL PROTECTED] wrote: good for you but this should be the last of these messages, I did a clean co and halts at MBeanProxy:112 ... On a related topic... What happend with the decentrialised build/run-testsuite/uppload results to lubega from different OS's ? ... Then We would get around that all are updating when CVS is in a transitional state ... and also ofcource then be able to track different OS behaviors ... together ... /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss build failed
Hi, I will say this of your stuff Chris: It's right on top of the ball :) commiting the rest of it in cvs About time too ;-) The hourly compile happens at 45mins past each hour - you have been warned... Chris _ 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
[JBoss-dev] test, ignore
from forums __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5145 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-489465 ] cannot turn jboss.xml dtd validation off
Bugs item #489465, was opened at 2001-12-05 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=489465group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Emmanuel Sciara (sciara) Assigned to: Nobody/Anonymous (nobody) Summary: cannot turn jboss.xml dtd validation off Initial Comment: I am using xdoclet to generate my entity beans, which adds automatically the dtd declaration http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd to jboss.xml . When i try to deploy my beans, the following deployment exception is throw: [12:30:54,351,ContainerFactory] Deploying:file:/C:/Data/Download/Extracted/jboss- 3.0.0alpha/deploy/Default/newmove-deploy.jar/ [12:30:54,731,Default] External entity not found: http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd.:- 1:2 [12:30:54,731,Default] java.io.FileNotFoundException: http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.fatal (Parser2.java:3108) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.externalParameterEnti ty(Parser2.java:2796) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.maybeDoctypeDecl (Parser2.java:1155) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.parseInternal (Parser2.java:489) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.parse (Parser2.java:305) [12:30:54,731,Default] at org.apache.crimson.parser.XMLReaderImpl.parse (XMLReaderImpl.java:433) [12:30:54,731,Default] at org.apache.crimson.jaxp.DocumentBuilderImpl.parse (DocumentBuilderImpl.java:185) [12:30:54,731,Default] at javax.xml.parsers.DocumentBuilder.parse (DocumentBuilder.java:86) [12:30:54,731,Default] at org.jboss.metadata.XmlFileLoader.getDocument (XmlFileLoader.java:247) [12:30:54,731,Default] at org.jboss.metadata.XmlFileLoader.getDocumentFromURL (XmlFileLoader.java:219) [12:30:54,731,Default] at org.jboss.metadata.XmlFileLoader.load (XmlFileLoader.java:176) [12:30:54,731,Default] at org.jboss.ejb.ContainerFactory.deploy (ContainerFactory.java:436) [12:30:54,731,Default] at org.jboss.ejb.ContainerFactory.deploy (ContainerFactory.java:377) [12:30:54,731,Default] at org.jboss.ejb.ContainerFactory.deploy (ContainerFactory.java:308) [12:30:54,731,Default] at java.lang.reflect.Method.invoke(Native Method) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) [12:30:54,741,Default] at org.jboss.deployment.J2eeDeployer.startModules (J2eeDeployer.java:467) [12:30:54,741,Default] at org.jboss.deployment.J2eeDeployer.startApplication (J2eeDeployer.java:444) [12:30:54,741,Default] at org.jboss.deployment.J2eeDeployer.deploy (J2eeDeployer.java:215) [12:30:54,741,Default] at java.lang.reflect.Method.invoke(Native Method) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) [12:30:54,741,Default] at org.jboss.deployment.AutoDeployer.deploy (AutoDeployer.java:654) [12:30:54,741,Default] at org.jboss.deployment.AutoDeployer.run (AutoDeployer.java:327) [12:30:54,741,Default] at java.lang.Thread.run (Thread.java:484) The dtd file does not exist at the location indicated And it is difficult to get rid of it(need to recompile and repackage the whole of xdoclet). I checked the the JarDeployer MBean in the J2ee deployer service and the ValidateDTDs attribute is set to false but, if I interpret the error message correctly, the deployer still tries to validate it. Could you confirm this is a bug? Is there a way around itf on the JBoss side? -- Comment By: Emmanuel Sciara (sciara) Date: 2001-12-07 09:29 Message: Logged In: YES user_id=91163 I looked there and in the whole JBoss source. There is no trace of any jboss_3_0.dtd! So does that mean that this dtd actually does not exist? Does that mean that the dtd has not changed between 2.4 and 3.0? -- Comment By: Guillaume Coté (gcote) Date: 2001-12-06 10:03 Message: Logged In: YES user_id=15328 First, the page http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd is a 404, which shouldn't be the case. Second, the dtd are distributed with the source, in the directory jboss\src\resources\org\jboss\metadata\. You could find it there and replace the url with a URL on local file or local webserver pointing on the corresponding file. Third, there are a class call org.jboss.metadata.XmlFileLoader.LocalResolver that I think should allow you to check the dtd without needing a extenal web access. There are the javadoc comments of the class : Local entity resolver to handle J2EE DTDs.
Re: [JBoss-dev] current mbean structure confusing
Bill, First I want to agree with you that the current deployment system has problems in getting the deployment order right for more than toy examples. It is (or may be) possible to force the correct deployment order by liberal use of anonymous mbean references, but I think that is a bad idea and not maintainable. I think mbean-refs are really good when one mbean needs to use the services of another, such as those in ConnectionFactoryLoader: using them simplified the code considerably while introducing better dependency management. But if there is no natural use of one mbean by another, I think mbean-refs are artificial. What would you think of a deployment script facility, where you listed the packages in the order you wanted them deployed? At most the script would be autodeployed. Also... why are you using autodeployment on a production system? You can write a little program to deploy the packages you want in the order you want, the testsuite has lots of examples of this, see esp. the JBossTestServices class. I think there's a way to do this through a servlet or jsp also, I think Andreas wrote an ejb adaptor or connector for the mbean server. I have been thinking along the lines of large projects being divided up into medium sized chunks: the deployment then involves deploying these chunks in the correct order. I would think this would be easier to understand and maintain than one giant dd at the lowest level of detail. Does this make sense? Finally: I don't think any logic in AutoDeployer changed. If you put the mbeans you want to start last at the end of the main jboss-service file are they deployed before autodeployer goes through and deploys everything it can find? If so, this may be an accident of the ordering of deployers and deploy directories in the autodeployer configuration, and you might be able to reorder these to get the results you want. I would be hesitant to rely on this for a production system. Thanks david jencks On 2001.12.07 14:07:59 -0500 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, December 07, 2001 1:34 PM To: [EMAIL PROTECTED] Cc: marc fleury; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] current mbean structure confusing On 2001.12.07 09:47:31 -0500 Bill Burke wrote: On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? Having a dependency on the autodeployer won't do you much good, will it? Maybe I'm just really braindead here, but in 2.4.x, MBeans listed after the AutoDeployer(implicit dependency) did not start until the AutoDeployer finished deploying everything. Why was this behavior changed in 3.0? This is very very useful. Otherwise, mbeans depending on EJBs and services deployed by the AutoDeployer will have to list long lists of MBean refs (is this correct?) which are hard to maintain. An even better reason for this behavior is the following scenario we had at Mercantec: Mercantec's application receives HTTP requests many times per second by hundreds/thousands of different clients. Jetty should not be able to accept HTTP requests until JBoss has completely booted up, and this means all AutoDeployed components. Otherwise, UI sessions could come up with errors in this time interval (2-3 minutes to load all our beans), or our batched XML-RPC requests could fail. The way you guys are talking, I'm going to have to list MBean refs for all 80 of our EJBS and other datasouces and MBean components!!! That's a nightmare to maintain and just plain ridiculous. Do you get what I'm saying here? Other than that, IMHO, it is plain ridiculous to have to explicitly type in dependencies for all MBeans. It is just too much work and too hard to maintain for a large application. Having implicit dependencies by MBean ordering in a file is simple and elegant and easy to understand. Yes, specifying dependencies explicitly is very useful, but I'm guessing is not needed for 80% of applications. Bill Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] test, ignore
from mailing list ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-boot.jar log4j
Using fancy reflection, buffered appender or some other magically logging fluff? Does this mean we will add log4j-core.jar to the main lib/ directory too? --jason On Fri, 7 Dec 2001, Scott M Stark wrote: I have this working and I'll check it in tomorrow after some more testing. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 9:24 PM Subject: Re: [JBoss-dev] jboss-boot.jar log4j That would be good assuming that we get as far as loading the Log4j service, if we don't then we don't have any logging information about the problem. Plus todo that we still need the log4j core classes... and well, we would also need our proxy generator since the log4j bits are not interfaces and thus we can't make use of the java.lang.reflect.Proxy bits. I think that we might want to create a buffered appender, have the default configuration log to System.out, then once the service is up, flush the buffer to the users configured appenders and remove it. --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: build/website build.xml
User: user57 Date: 01/12/07 11:52:49 Modified:website build.xml Log: o removed forums from standard group (so it won't be part of the nightly update) Revision ChangesPath 1.18 +2 -2 build/website/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/website/build.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- build.xml 2001/12/06 03:25:26 1.17 +++ build.xml 2001/12/07 19:52:49 1.18 @@ -12,7 +12,7 @@ !---- !-- == -- -!-- $Id: build.xml,v 1.17 2001/12/06 03:25:26 user57 Exp $ -- +!-- $Id: build.xml,v 1.18 2001/12/07 19:52:49 user57 Exp $ -- project default=main name=JBoss Website/Build @@ -102,7 +102,7 @@ !-- Module groups -- group name=standard -include modules=website, manual, forums, survey, snapshots/ +include modules=website, manual, survey, snapshots/ /group group name=quick ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
Maybe I'm just really braindead here, but in 2.4.x, well, it's the tone that bother me, you sound like me ]:) MBeans listed after the AutoDeployer(implicit dependency) did not start until the AutoDeployer finished deploying everything. Why was this behavior changed in 3.0? As far as I know David M was talking about making the mbeans in one file deploy and start together, I think this behavior is still useful, if it has been removed, why don't you put it back? ask david M that was a valid feature. This is very very useful. Otherwise, mbeans depending on EJBs and services deployed by the AutoDeployer will have to list long lists of MBean refs (is this correct?) which are hard to maintain. yeah yeah we got it Mercantec's application receives HTTP requests many times per second by hundreds/thousands of different clients. Jetty should not be able to accept HTTP requests until JBoss has completely booted up, and this means all AutoDeployed components. Otherwise, UI sessions could come up with errors in this time interval (2-3 minutes to load all our beans), or our batched XML-RPC requests could fail. Then code it biotch :) the fact is that being able to deploy independent services means that you almost must install/conf/start in one batch. Holding the steps in the scope of the PAGE XML being deployed is useful, Code it back, I think it took DavidM one day to code it, You supah man, go Do you get what I'm saying here? YES, go ahead. David J, please make sure this behavior is still there when he puts it, don't remove that, even for the benefit of your dependency stuff. FUCK a little arbitrage never hurt anyone, aaarg this thread is just getting too long, too tense (although I guess I set the tone) and it is time we finish it. maintain for a large application. Having implicit dependencies by MBean ordering in a file is simple and elegant and easy to understand. Yes, yes, we agree, it is, if it was removed then bad, if it is then code it again, and flag it as touch this and I burn your beard david and basta. David J did relevant work, so stop bitching and fix it. David M you got 30 minutes? specifying dependencies explicitly is very useful, but I'm guessing is not needed for 80% of applications. I wouldn't put down the feature, you have seen enough support here on the list for it, they are largely orthogonal (meaning there was no reason to remove it afaict) and we should really kill this thread once and for all. marcf Bill Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
First I want to agree with you that the current deployment system has problems in getting the deployment order right for more than toy examples. all he is asking for is the page ordering which should be trivial to do. another, I think mbean-refs are artificial. hm there might still be a place. the fact is that even if I automate teh SCL tracking I don't know that I can track non-typed calls, Unless we hack the MBeanServer, but in any case, it is ahead of us. What would you think of a deployment script facility, where you listed the packages in the order you wanted them deployed? At most the script would be autodeployed. similar to one page and basta, more complex... look keep it simple (I think the real problem you have is an incapacity to keep it simple ;-) Also... why are you using autodeployment on a production system? You can write a little program to deploy the packages you want in the order you want, the testsuite has lots of examples of this, see esp. it's a point but the feature is so trivial that I would drop this discussion. I have been thinking along the lines of large projects being divided up into medium sized chunks: the deployment then involves deploying these chunks in the correct order. I would think this would be easier to understand and maintain than one giant dd at the lowest level of detail. Does this make sense? yes Finally: I don't think any logic in AutoDeployer changed. If you put the It is not AD logic it is in service controller do we group the mbeans to init/start, of course the smaller granularity we need to support is the mbean (we do, 2.4 doesn't so that is a very clear improvement) they are saying page scope was useful we agree, let's not let a trivial feature grow out of hand. would be hesitant to rely on this for a production system. bullshit... he does, it works, He loves it, he wants it in 3.0 let him code it, or DavidM, all I ask you is drop it and don't remove it or I come kick your ass on my way down to Miami. oka? good work btw, really, I have calmed down, and I realize that between you and hiram we got some solid coders under the SUN B-) marcf __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-489465 ] cannot turn jboss.xml dtd validation off
Bugs item #489465, was opened at 2001-12-05 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=489465group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Emmanuel Sciara (sciara) Assigned to: Nobody/Anonymous (nobody) Summary: cannot turn jboss.xml dtd validation off Initial Comment: I am using xdoclet to generate my entity beans, which adds automatically the dtd declaration http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd to jboss.xml . When i try to deploy my beans, the following deployment exception is throw: [12:30:54,351,ContainerFactory] Deploying:file:/C:/Data/Download/Extracted/jboss- 3.0.0alpha/deploy/Default/newmove-deploy.jar/ [12:30:54,731,Default] External entity not found: http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd.:- 1:2 [12:30:54,731,Default] java.io.FileNotFoundException: http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.fatal (Parser2.java:3108) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.externalParameterEnti ty(Parser2.java:2796) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.maybeDoctypeDecl (Parser2.java:1155) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.parseInternal (Parser2.java:489) [12:30:54,731,Default] at org.apache.crimson.parser.Parser2.parse (Parser2.java:305) [12:30:54,731,Default] at org.apache.crimson.parser.XMLReaderImpl.parse (XMLReaderImpl.java:433) [12:30:54,731,Default] at org.apache.crimson.jaxp.DocumentBuilderImpl.parse (DocumentBuilderImpl.java:185) [12:30:54,731,Default] at javax.xml.parsers.DocumentBuilder.parse (DocumentBuilder.java:86) [12:30:54,731,Default] at org.jboss.metadata.XmlFileLoader.getDocument (XmlFileLoader.java:247) [12:30:54,731,Default] at org.jboss.metadata.XmlFileLoader.getDocumentFromURL (XmlFileLoader.java:219) [12:30:54,731,Default] at org.jboss.metadata.XmlFileLoader.load (XmlFileLoader.java:176) [12:30:54,731,Default] at org.jboss.ejb.ContainerFactory.deploy (ContainerFactory.java:436) [12:30:54,731,Default] at org.jboss.ejb.ContainerFactory.deploy (ContainerFactory.java:377) [12:30:54,731,Default] at org.jboss.ejb.ContainerFactory.deploy (ContainerFactory.java:308) [12:30:54,731,Default] at java.lang.reflect.Method.invoke(Native Method) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) [12:30:54,741,Default] at org.jboss.deployment.J2eeDeployer.startModules (J2eeDeployer.java:467) [12:30:54,741,Default] at org.jboss.deployment.J2eeDeployer.startApplication (J2eeDeployer.java:444) [12:30:54,741,Default] at org.jboss.deployment.J2eeDeployer.deploy (J2eeDeployer.java:215) [12:30:54,741,Default] at java.lang.reflect.Method.invoke(Native Method) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) [12:30:54,741,Default] at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) [12:30:54,741,Default] at org.jboss.deployment.AutoDeployer.deploy (AutoDeployer.java:654) [12:30:54,741,Default] at org.jboss.deployment.AutoDeployer.run (AutoDeployer.java:327) [12:30:54,741,Default] at java.lang.Thread.run (Thread.java:484) The dtd file does not exist at the location indicated And it is difficult to get rid of it(need to recompile and repackage the whole of xdoclet). I checked the the JarDeployer MBean in the J2ee deployer service and the ValidateDTDs attribute is set to false but, if I interpret the error message correctly, the deployer still tries to validate it. Could you confirm this is a bug? Is there a way around itf on the JBoss side? -- Comment By: Emmanuel Sciara (sciara) Date: 2001-12-07 09:35 Message: Logged In: YES user_id=91163 BTW, is it a normmal behaviour that the deployer will try to validate the xml file even if the ValidateDTDs attribute is false? -- Comment By: Emmanuel Sciara (sciara) Date: 2001-12-07 09:29 Message: Logged In: YES user_id=91163 I looked there and in the whole JBoss source. There is no trace of any jboss_3_0.dtd! So does that mean that this dtd actually does not exist? Does that mean that the dtd has not changed between 2.4 and 3.0? -- Comment By: Guillaume Coté (gcote) Date: 2001-12-06 10:03 Message: Logged In: YES user_id=15328 First, the page http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd is a 404, which shouldn't be the case. Second, the dtd are distributed with the source, in the directory jboss\src\resources\org\jboss\metadata\. You could find it there and replace the url with a URL on local file or
[JBoss-dev] CVS update: newsite/src/docs/developers lists.jsp
User: user57 Date: 01/12/07 13:16:35 Modified:src/docs/developers lists.jsp Log: o removed nntp reference o cleaned up formatting based on the current stylesheet. Revision ChangesPath 1.4 +128 -63 newsite/src/docs/developers/lists.jsp Index: lists.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/lists.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- lists.jsp 2001/11/07 19:55:37 1.3 +++ lists.jsp 2001/12/07 21:16:35 1.4 @@ -1,70 +1,135 @@ jsp:include page=head.jsp flush=true / jsp:include page=slogan.jsp flush=true - jsp:param name=SLOGAN value=MAIN MAILING LISTS/ + jsp:param name=SLOGAN value=MAILING LISTS/ /jsp:include +!-- $Id: lists.jsp,v 1.4 2001/12/07 21:16:35 user57 Exp $ -- - !-- CONTENT -- - p class=headNETIQUETTE, - p class=textjsp:include page=/common/picateam.jsp flush=true / -We have users and developers from all over the world on the forums and mailing - lists. People there are not there under any contractual obligation to answer questions. - If you want help from someone make sure you take the time to format your question so that an - advanced user can spot your problem quickly, this is usually the surest way to get an answer. - p class=text bDO/b: take the time to read the archives, many answers are there and many questions are a repeat. - Take the time to read the manual, 80% questions are answered by the manual and the manual features a search engine. -p class=text bDON'T/b: give 10,000ft descriptions and say doesn't work, or on the other hand - dump your stack trace without editing it. Don't expect an answer if your questions is not well - formatted. If your question isn't answered - try improving your report, it probably is a waste of time to address it as is... remember this is free time. - Don't post a question without searching the manual entries, 80% questions are usually RTFM so start by RTFM. - - p class=text In the open source world, knowledge is king. On the lists you will find free-men, - advanced technologists, middleware afficionados, CORBA old timers, savvy consultancies, startup kamikazees, - a few aliens, PH.D students, IT dilletantes, IT professionals, -IT consultants but mostly well... normal folks. Remember when you ask - a question that you are asking for these people to give you their knowledge. Show respect, - earn respect, and you will find that the level of support you get from us matches and most times - exceeds what you won't get from our closed source competitors. - - p class=headONLINE FORUMS - p class=text a class=link href=/forums/index.jspClick here for the forums/a - p class=textAll JBoss products are now supported online directly from this website. No need to subscribe to a voluminous email list. We feature an advanced forum with sub-topics and email/NNTP notifications. If you are just starting to use our product suite you can get first level help from our large user base on these free forums. - - p class=headOLD JBOSS-USER ARCHIVE - p class=texta class=link href=http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/;Archive/a - p class=texta class=link href=http://www.mail-archive.com/jboss-user@list.working-dogs.com/;bOld Archive/b/a (working-dogs old archive) - p class=headJBOSS-DEV - p class=textbFor development only/b, do not post user questions here, they will not be answered. All the architecture discussion are taken on this list. The future of the webOS is decided in this forum. It also notifies you of updates in the cvs tree, all active developers must follow the updates. Register here if you are interested in following and participating in the building of our future source tree. -p class=textbTo subscribe/b please follow the instructions on a class=link href=http://lists.sourceforge.net/lists/listinfo/jboss-development;sourceforge/a. -p class=texta class=link href=http://www.mail-archive.com/jboss-development%40lists.sourceforge.net/;Archive/a - p class=texta class=link href=http://www.mail-archive.com/jboss-dev@list.working-dogs.com/;bOld Archive/b/a (working-dogs old archive) - -p class=head JBossMQ -p class=textJBossMQ user is now online in the forums. JBossMQ dev is merged with jboss-dev. -p class=texta class=link href=http://www.egroups.com/group/spyderMQ;bArchive/b/a -p class=headJBossCMP -p class=textJBossCMP offers all the functionality of a powerful O-gt;R tool. It is designed to be very lightweight and adapted to the needs of an EJBnbsp;container. -p class=textTo subscribe just click a class =link
[JBoss-dev] CVS update: newsite/src/docs/developers lists.jsp
User: user57 Date: 01/12/07 13:18:52 Modified:src/docs/developers lists.jsp Log: o picateam was in the wrong place... Revision ChangesPath 1.5 +3 -2 newsite/src/docs/developers/lists.jsp Index: lists.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/lists.jsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- lists.jsp 2001/12/07 21:16:35 1.4 +++ lists.jsp 2001/12/07 21:18:52 1.5 @@ -3,7 +3,7 @@ jsp:param name=SLOGAN value=MAILING LISTS/ /jsp:include -!-- $Id: lists.jsp,v 1.4 2001/12/07 21:16:35 user57 Exp $ -- +!-- $Id: lists.jsp,v 1.5 2001/12/07 21:18:52 user57 Exp $ -- h2NETIQUETTE/h2 @@ -119,9 +119,10 @@ pa href=http://www.egroups.com/messages/jbosslicense;bArchive/b/a /blockquote +h2IRC:#jboss.org/h2 + jsp:include page=/common/picateam.jsp flush=true/ -h2IRC:#jboss.org/h2 pJBoss now has a dedicated IRC channel thanks to Markus from Austria. To use it download an IRC client (mIRC on windows) connect to an IRCNet server (NY for US) and /join #jboss.org. You will find us there. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Read-only and time-out
I _thought_ that read-only and timeout were added to implement entities that were 'read-mostly' - things that might be updated outside of the EJB container occasionially (like a product catalog, say), while keeping the caching advantage of commit option A. If I'm remembering this correctly, this would mean that the timeout would extend accross transactions - maybe overriding commit option B to some extent? However, if I am remembering correctly, then the timeout should be more like 300 seconds than 300 milliseconds. -danch Dain Sundstrom wrote: Does anyone remember who originally wrote the time-out code or know the original goal? I am working on adding read-only to relationships, and have some questions on how time-out is supposed to work. Once a read-only field is loaded in a transaction, is it supposed to be valid for the length of the transaction, or only for the amount of time in time-out (300 ms by default)? If we are in commit option A, should the time-out extend across transactions? If we have a locking-strategy enabled (select-for-update is currently the only strategy), should the time-out be ignored within a transaction (i.e., the row is locked so why reload)? Any help would be greatly appreciated. I'm just guessing right now. -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
[JBoss-dev] CVS update: newsite/src/docs/developers lists.jsp
User: user57 Date: 01/12/07 13:20:02 Modified:src/docs/developers lists.jsp Log: o and a final br clear to finish things up Revision ChangesPath 1.6 +3 -1 newsite/src/docs/developers/lists.jsp Index: lists.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/lists.jsp,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- lists.jsp 2001/12/07 21:18:52 1.5 +++ lists.jsp 2001/12/07 21:20:02 1.6 @@ -3,7 +3,7 @@ jsp:param name=SLOGAN value=MAILING LISTS/ /jsp:include -!-- $Id: lists.jsp,v 1.5 2001/12/07 21:18:52 user57 Exp $ -- +!-- $Id: lists.jsp,v 1.6 2001/12/07 21:20:02 user57 Exp $ -- h2NETIQUETTE/h2 @@ -129,6 +129,8 @@ For a list of all servers participating in IRCnet go to a href=http://www.irchelp.org/irchelp/networks/servers/ircnet.html;http://www.irchelp.org/irchelp/networks/servers/ircnet.html/a please. + +br clear=all pWe want to thank a href=http://sourceforge.net;img src=http://sourceforge.net/sflogo.php?group_id=22866; width=88 height=31 border=0 alt=SourceForge Logo/a for hosting some of our mailing lists. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jbossmq startup... do we really need ALL these queues by default?
yo, Half the log is with the mq stuff doing queues from A-Z do we *really* need all of these, just cosmetics but still... __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5182 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-boot.jar log4j
Using reflection. We don't need the log4j-core.jar in lib for this change. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, December 07, 2001 12:07 PM Subject: Re: [JBoss-dev] jboss-boot.jar log4j Using fancy reflection, buffered appender or some other magically logging fluff? Does this mean we will add log4j-core.jar to the main lib/ directory too? --jason On Fri, 7 Dec 2001, Scott M Stark wrote: I have this working and I'll check it in tomorrow after some more testing. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 9:24 PM Subject: Re: [JBoss-dev] jboss-boot.jar log4j That would be good assuming that we get as far as loading the Log4j service, if we don't then we don't have any logging information about the problem. Plus todo that we still need the log4j core classes... and well, we would also need our proxy generator since the log4j bits are not interfaces and thus we can't make use of the java.lang.reflect.Proxy bits. I think that we might want to create a buffered appender, have the default configuration log to System.out, then once the service is up, flush the buffer to the users configured appenders and remove it. --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: [JBoss-dev] jbossmq startup... do we really need ALL these queuesby default?
Probably not for the default config... some are used for the testsuite, but I think we should probably setup a 'testsuite' config, which is used to run the testsuite against. Downside to this is we may miss configuration errors in the 'default' config. Does the remote queue/topic install work? Could use that to setup the queues/topics required for the tests. --jason Half the log is with the mq stuff doing queues from A-Z do we *really* need all of these, just cosmetics but still... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/web/survey SurveyController.jsp
User: schaefera
Date: 01/12/07 14:48:10
Modified:src/web/survey SurveyController.jsp
Log:
Removed System.out.println() from the JBoss Survey.
Revision ChangesPath
1.3 +3 -7 website-survey/src/web/survey/SurveyController.jsp
Index: SurveyController.jsp
===
RCS file: /cvsroot/jboss/website-survey/src/web/survey/SurveyController.jsp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SurveyController.jsp 2001/10/12 04:23:17 1.2
+++ SurveyController.jsp 2001/12/07 22:48:10 1.3
@@ -4,8 +4,8 @@
Controls the retrieval and display of the Survey.
Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
-Version: $Revision: 1.2 $
-Last Checked In: $Date: 2001/10/12 04:23:17 $
+Version: $Revision: 1.3 $
+Last Checked In: $Date: 2001/12/07 22:48:10 $
Last Checked In By: $Author: schaefera $
--%
@@ -88,10 +88,6 @@
}
} else
if( lPage.equals( JBossPage ) ) {
- System.out.println( First Time: +
- Helper.getBooleanParameter( request, jbossFirstTime, false
- )
- );
%
jsp:setProperty name=Survey property=*/
%
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/ejb/entity SurveyBean.java
User: schaefera
Date: 01/12/07 14:48:09
Modified:src/main/org/jboss/survey/ejb/entity SurveyBean.java
Log:
Removed System.out.println() from the JBoss Survey.
Revision ChangesPath
1.5 +1 -4
website-survey/src/main/org/jboss/survey/ejb/entity/SurveyBean.java
Index: SurveyBean.java
===
RCS file:
/cvsroot/jboss/website-survey/src/main/org/jboss/survey/ejb/entity/SurveyBean.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SurveyBean.java 2001/11/02 22:38:58 1.4
+++ SurveyBean.java 2001/12/07 22:48:09 1.5
@@ -9,7 +9,6 @@
import org.jboss.survey.ejb.Debug;
import org.jboss.survey.ejb.EJBUtils;
import org.jboss.survey.ejb.session.SequenceGenerator;
-// Only necessary because of a limitation by the EJBDoclet
import org.jboss.survey.ejb.session.SequenceGeneratorBean;
import org.jboss.survey.ejb.session.SequenceGeneratorHome;
@@ -36,7 +35,7 @@
* The Entity bean represents a Survey.
*
* @author Andreas Schaefer
-* @version $Revision: 1.4 $
+* @version $Revision: 1.5 $
*
* @ejb:bean name=jboss/survey/Survey
* display-name=JBoss Survey Informations
@@ -132,7 +131,6 @@
public SurveyData getValueObject() {
SurveyData aReturn = new SurveyData();
- System.out.println( SurveyBean.getValueObject(), first time: +
getJbossFirstTime() );
aReturn.setId( getId() );
aReturn.setUserId( getUserId() );
aReturn.setJbossVersion( getJbossVersion() );
@@ -727,7 +725,6 @@
SurveyData aSurvey = (SurveyData) pSurvey.clone();
// each title must have a unique id to identify itself within the DB
aSurvey.setId( generateUniqueId() );
- System.out.println( Got new id: + aSurvey.getId() );
// Save the new Survey
setValueObject( aSurvey );
// This is only possible in CMPs. Otherwise return a valid PK.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/main/org/jboss/survey/util Helper.java
User: schaefera
Date: 01/12/07 14:48:10
Modified:src/main/org/jboss/survey/util Helper.java
Log:
Removed System.out.println() from the JBoss Survey.
Revision ChangesPath
1.2 +2 -6 website-survey/src/main/org/jboss/survey/util/Helper.java
Index: Helper.java
===
RCS file: /cvsroot/jboss/website-survey/src/main/org/jboss/survey/util/Helper.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Helper.java 2001/10/02 21:34:57 1.1
+++ Helper.java 2001/12/07 22:48:10 1.2
@@ -1,9 +1,9 @@
//
// File: Helper.java
// Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
-// Version: $Revision: 1.1 $
-// Last Checked In: $Date: 2001/10/02 21:34:57 $
-// Last Checked In By: $Author: user57 $
+// Version: $Revision: 1.2 $
+// Last Checked In: $Date: 2001/12/07 22:48:10 $
+// Last Checked In By: $Author: schaefera $
package org.jboss.survey.util;
@@ -22,7 +22,7 @@
* Contains some static helper methods
*
* @author Andreas Schaefer
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
**/
public class Helper
{
@@ -156,17 +156,14 @@
if ( aMonth == BOGUS_NUMBER || aMonth 12 || aMonth 1 )
{
-System.out.println(Bogus month: + aMonth);
return false;
}
if ( aDate == BOGUS_NUMBER || aDate 31 || aDate 1 )
{
-System.out.println(Bogus date: + aDate);
return false;
}
if ( aYear == null || aYear.length() 4 )
{
-System.out.println(Bogus year: + aYear);
return false;
}
@@ -176,7 +173,6 @@
}
catch ( ParseException pPE )
{
-System.out.println( Exception checking date: + pPE.getMessage() );
return false;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-boot.jar log4j
Ok... well I look forward to seeing this magic. __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5058 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-survey/src/web/survey-helper Statistics.Controller.jsp
User: schaefera
Date: 01/12/07 14:48:10
Modified:src/web/survey-helper Statistics.Controller.jsp
Log:
Removed System.out.println() from the JBoss Survey.
Revision ChangesPath
1.3 +3 -7 website-survey/src/web/survey-helper/Statistics.Controller.jsp
Index: Statistics.Controller.jsp
===
RCS file:
/cvsroot/jboss/website-survey/src/web/survey-helper/Statistics.Controller.jsp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Statistics.Controller.jsp 2001/10/15 19:35:53 1.2
+++ Statistics.Controller.jsp 2001/12/07 22:48:10 1.3
@@ -4,8 +4,8 @@
Controls the retrieval and display of the Statistics Evaluation
Copyright ( c ) 2001 eBuilt, Inc. All rights reserved.
-Version: $Revision: 1.2 $
-Last Checked In: $Date: 2001/10/15 19:35:53 $
+Version: $Revision: 1.3 $
+Last Checked In: $Date: 2001/12/07 22:48:10 $
Last Checked In By: $Author: schaefera $
--%
@@ -156,10 +156,6 @@
if( lSurvey.getJbossUsage().equals( Packaged ) ) {
jbu5++;
}
- System.out.println( Statistics.Controller.jsp, survey id: +
lSurvey.getId() +
- , first time: + lSurvey.getJbossFirstTime() +
- , own mbeans: + lSurvey.getOwnMBeans()
- );
if( lSurvey.getJbossFirstTime() ) {
ftu++;
} else {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss build faied
What are the problems? --jason __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5188 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss build faied
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Andreas Schaefer |Sent: Friday, December 07, 2001 5:50 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] JBoss build faied | | |Any idea when this is going to be fixed ? | |Problems in Connector as well as Testsuite module. do a clean checkout, they build on my machine marcf | |x |Andreas Schaefer |Senior Consultant |JBoss Group, LLC |x | | | |___ |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] org.jboss.proxy org.jboss.proxy.compiler
now that org.jboss.proxy.* has been moved to org.jboss.proxy.compiler.* what is going to live in org.jboss.proxy? I heard some mention of EJB proxy stuff, but shouldn't that be in an org.jboss.ejb.* package? Just curious... --jason __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5191 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
Also... why are you using autodeployment on a production system? You can write a little program to deploy the packages you want in the order you want, the testsuite has lots of examples of this, see esp. the JBossTestServices class. I think there's a way to do this through a servlet or jsp also, I think Andreas wrote an ejb adaptor or connector for the mbean server. We used it in production because its fast and easy to maintain. No need to keep/maintain a list of bean dependencies. Remember, I don't want Jetty to startup until everything is done, that's the real problem and I bet many other apps will have the same problem. You shouldn't serve HTTP requests until JBoss is ready. Finally: I don't think any logic in AutoDeployer changed. If you put the mbeans you want to start last at the end of the main jboss-service file are they deployed before autodeployer goes through and deploys everything it can find? If so, this may be an accident of the ordering of deployers and deploy directories in the autodeployer configuration, and you might be able Nope, AutoDeployer behavior definately changed. I put an mbean right after the autodeployer declaration in jboss-service.xml and that mbean gets executed at the same time as the autodeployer is deploying things. That mbean does not wait until the AutoDeployer has finished deploying everything. My instincts tell me that you will piss off a lot of people with this behaviour. I've answered many questions on the User list about How can write initializer classes like Weblogic? initializer classes meaning classes that get run after the app server has booted. I always tell them, write an MBean. Since MBeans declared after the AutoDeployer will start before the AutoDeployer finishes, Im betting you'll break a lot of applications.(Mercantec's is definately one of them since they have both an initializer mbean and the dependency of Jetty not starting up until everything is deployed.) to reorder these to get the results you want. I would be hesitant to rely on this for a production system. Doesn't AutoDeploy = HotDeploy. You can't hot deploy unless you autodeploy it? Is this true? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
Doesn't AutoDeploy = HotDeploy. You can't hot deploy unless you autodeploy it? Is this true? No, but I still agree with your other points, that scoping the create/configuration/init/start should follow page as a simple way to group them. marcf (No you can hot-deploy a service by undeploying the URL and redeploying, hot-deploy means the capacity to deal with new class versions dynamically) __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: org.jboss.proxy org.jboss.proxy.compiler
I heard some mention of EJB proxy stuff, but shouldn't that be in an org.jboss.ejb.* package? no Just curious... cktc --jason __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5191 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss build faied
clean co works for you? doing better? let us know if it is still broken, last I saw it was ok, marcf __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5188 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: org.jboss.proxy org.jboss.proxy.compiler
| cktc | |wtfdtm? curiosity killed the cat marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: org.jboss.proxy org.jboss.proxy.compiler
cktc wtfdtm? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss build faied
Timestamp by above gives me error on build ... let Me guess nobody elsehasthe BALLS to to say so - hehehehehehe /Uknowwho on 1-12-08 00.30, marc fleury at [EMAIL PROTECTED] wrote: clean co works for you? doing better? let us know if it is still broken, last I saw it was ok, marcf __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5188 ___ 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] JBoss build faied
I hate W2K, really. Or at least the implementation of JDK on W2K. I am not able to run two different JDKs on the same W2K box, long live Unix. I removed JDK1.4 and not compilation worked fine. The reason why I installed JDK1.4 is that someone reported strange runtime errors with JMX on JSR-77. Andy - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, December 07, 2001 5:45 PM Subject: Re: [JBoss-dev] JBoss build faied ConnectionInPool.java and StatementInPool.java has some commented lines which metion to uncomment them for 1.4. What is 1.4 requires these? Any reason why they need to be commented? Will this break uncommented for 1.3? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: ServiceMBeanSupport init and destroy commented out
Revision 1.5 / (download) / (as text) - annotate - [select for diffs] , Mon Nov 12 06:52:17 2001 UTC (3 weeks, 4 days ago) by d_jencks Branch: MAIN CVS Tags: Rel_2_4_4_15 Changes since 1.4: +15 -15 lines Diff to previous 1.4 Changes to move toward eliminating init and destroy from Service interface, and make J2eeDeployer use mbean-refs. (2nd try at committing - is cvs acting weird? ?:|, David, I am not up for a 50 mail thread on that one but I think it was an oversight, I will uncomment, write if you want to discuss so we have something to fight over during the weekend __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5197 ___ 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: 169 Successful tests: 164 Errors:2 Failures: 3 [time of test: 8 December 2001 3:22 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] Re: ServiceMBeanSupport init and destroy commented out
huh. in fact removing these means that if you don't define it in the extension then Scott's Proxy wont' call the init and destroy and if you give them then they get called. Since you define start/stop you still get the state variable of JSR77 set properly... interesting. I am almost tempted to leave it out of MBeanSupport as if you need it you will implement it and if you don't need it then it at least doesn't get called. __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5197 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: ServiceMBeanSupport init and destroy commented out
Marc, init/destroy are never called on a ServiceMBean. (At least they aren't called on mine) So uncommenting them does nothing. I assume they were commented out when David J made the change from two stage init/destroy to 1 stage. (Which, BTW, broke every serivce I had written previously since I used start/stop to pause/unpause, and init/destroy to create/destroy expensive resources. But, that's a different thread) On Fri, 07 Dec 2001, marc fleury wrote: Revision 1.5 / (download) / (as text) - annotate - [select for diffs] , Mon Nov 12 06:52:17 2001 UTC (3 weeks, 4 days ago) by d_jencks Branch: MAIN CVS Tags: Rel_2_4_4_15 Changes since 1.4: +15 -15 lines Diff to previous 1.4 Changes to move toward eliminating init and destroy from Service interface, and make J2eeDeployer use mbean-refs. (2nd try at committing - is cvs acting weird? ?:|, David, I am not up for a 50 mail thread on that one but I think it was an oversight, I will uncomment, write if you want to discuss so we have something to fight over during the weekend __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5197 ___ 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: manual/src/xdocs/howto howtonetbeansdebug.xml
User: jwalters Date: 01/12/07 19:54:47 Modified:src/xdocs/howto howtonetbeansdebug.xml Log: Updated email address Revision ChangesPath 3.1 +1 -1 manual/src/xdocs/howto/howtonetbeansdebug.xml Index: howtonetbeansdebug.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtonetbeansdebug.xml,v retrieving revision 3.0 retrieving revision 3.1 diff -u -r3.0 -r3.1 --- howtonetbeansdebug.xml2001/11/18 20:10:58 3.0 +++ howtonetbeansdebug.xml2001/12/08 03:54:46 3.1 @@ -6,7 +6,7 @@ firstnameJay/firstname surnameWalters/surname /author - email[EMAIL PROTECTED]/email + email[EMAIL PROTECTED]/email /para section titlePurpose/title ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: ServiceMBeanSupport init and destroy commented out
huh I really like the create/destroy as opposed to init/destroy, words sometimes are powerful, I mean the first one clearly says what it needs to say, I will use that instead. huh. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Budworth |Sent: Friday, December 07, 2001 10:35 PM |To: marc fleury |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Re: ServiceMBeanSupport init and destroy |commented out | | |Marc, init/destroy are never called on a ServiceMBean. (At least they |aren't called on mine) | |So uncommenting them does nothing. | |I assume they were commented out when David J made the change from two |stage init/destroy to 1 stage. (Which, BTW, broke every serivce I |had written |previously since I used start/stop to pause/unpause, and init/destroy to |create/destroy expensive resources. But, that's a different thread) | | | |On Fri, 07 Dec 2001, marc fleury wrote: | | Revision 1.5 / (download) / (as text) - annotate - [select for |diffs] , Mon Nov 12 06:52:17 2001 UTC (3 weeks, 4 days ago) by d_jencks | Branch: MAIN | CVS Tags: Rel_2_4_4_15 | Changes since 1.4: +15 -15 lines | Diff to previous 1.4 | | Changes to move toward eliminating init and destroy from Service |interface, and make J2eeDeployer use mbean-refs. (2nd try at |committing - is cvs acting weird? | | ?:|, David, I am not up for a 50 mail thread on that one but I |think it was an oversight, I will uncomment, write if you want to |discuss so we have something to fight over during the weekend | | __ | View: http://jboss.org/forums/thread.jsp?forum=66thread=5197 | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs/howto howtonetbeansdebug.xml
User: jwalters Date: 01/12/07 20:02:52 Modified:src/xdocs/howto Tag: Branch_2_4 howtonetbeansdebug.xml Log: Updated email address Revision ChangesPath No revision No revision 2.0.4.1 +1 -1 manual/src/xdocs/howto/howtonetbeansdebug.xml Index: howtonetbeansdebug.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtonetbeansdebug.xml,v retrieving revision 2.0 retrieving revision 2.0.4.1 diff -u -r2.0 -r2.0.4.1 --- howtonetbeansdebug.xml2001/11/18 19:14:34 2.0 +++ howtonetbeansdebug.xml2001/12/08 04:02:52 2.0.4.1 @@ -6,7 +6,7 @@ firstnameJay/firstname surnameWalters/surname /author - email[EMAIL PROTECTED]/email + email[EMAIL PROTECTED]/email /para section titlePurpose/title ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] init - create simple API change
short and sweet, [b]init/destroy[/b] will become [b]create/destroy[/b] is much clearer: you use this to create your service, set it up, expensive operation done, destroy is explicit start/stop was clear: you use this to start and stop SO IF YOU HAVE MBEANS OUT THERE make sure to port the [b]init to create[/b]. This only applies to your custom MBeans I will of course update the ones in cvs It is going to create a bit or portability problems but I think making this clear once and for all is a good thing (and this one is simple) __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5202 ___ 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: 162 Successful tests: 159 Errors:1 Failures: 2 [time of test: 8 December 2001 4:21 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
Re: [JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 162 Successful tests: 159 Errors:1 Failures: 2 we are almost there it seems PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! dude tell your script to stop biotching X-( I will take a plane to the UK just to kick his binary ass __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4926 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system BootstrapLogger.java MBeanClassLoader.java ServiceLibraries.java Shutdown.java URLClassLoader.java
User: starksm
Date: 01/12/07 20:35:42
Modified:src/main/org/jboss/system MBeanClassLoader.java
ServiceLibraries.java Shutdown.java
URLClassLoader.java
Added: src/main/org/jboss/system BootstrapLogger.java
Log:
Switch from System.out to log4j based logging that is loaded using the
thread context class loader via a reflection based wrapper to avoid explicit
dependencies on the log4j classes. This is required for a minimal bootstrap
footprint.
Revision ChangesPath
1.4 +22 -12jboss/src/main/org/jboss/system/MBeanClassLoader.java
Index: MBeanClassLoader.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/MBeanClassLoader.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MBeanClassLoader.java 2001/11/24 20:54:34 1.3
+++ MBeanClassLoader.java 2001/12/08 04:35:42 1.4
@@ -15,7 +15,7 @@
* The pupose of MBeanCL is to load the classes on behalf of an MBean.
*
* @author a href=[EMAIL PROTECTED]Marc Fleury/a
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
* pb20010830 marc fleury:/b
* ul
@@ -28,7 +28,9 @@
{
/** All SCL are just in orbit around a basic ServiceLibraries */
private static ServiceLibraries libraries;
-
+ /** The bootstrap interface to the log4j system */
+ private static BootstrapLogger log =
BootstrapLogger.getLogger(MBeanClassLoader.class);
+
private ObjectName objectName;
/**
@@ -42,7 +44,8 @@
super();
this.objectName = objectName;
- if (libraries == null) {
+ if (libraries == null)
+ {
libraries = ServiceLibraries.getLibraries();
}
}
@@ -53,7 +56,8 @@
*
* @returnMBean object name.
*/
- public ObjectName getObjectName() {
+ public ObjectName getObjectName()
+ {
return objectName;
}
@@ -64,8 +68,9 @@
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
- if (name.endsWith(CHANGEME)) {
- System.out.println(MCL LOAD + this.hashCode() +
+ if (name.endsWith(CHANGEME))
+ {
+ log.debug(MCL LOAD + this.hashCode() +
in loadClass + name);
}
@@ -79,19 +84,24 @@
return loadClass(name, true);
}
- public URL getResource(String name) {
+ public URL getResource(String name)
+ {
- if (name.endsWith(CHANGEME)) {
- System.out.println(MCL GETRESOURCE + name +
+ if (name.endsWith(CHANGEME))
+ {
+ log.debug(MCL GETRESOURCE + name +
in SCL + this.hashCode());
}
return libraries.getResource(name, this);
}
- public InputStream getResourceAsStream(String name) {
- try {
+ public InputStream getResourceAsStream(String name)
+ {
+ try
+ {
URL url = getResource(name);
- if (url != null) {
+ if (url != null)
+ {
return url.openStream();
}
}
1.10 +77 -42jboss/src/main/org/jboss/system/ServiceLibraries.java
Index: ServiceLibraries.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceLibraries.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ServiceLibraries.java 2001/12/07 02:31:05 1.9
+++ ServiceLibraries.java 2001/12/08 04:35:42 1.10
@@ -27,7 +27,7 @@
* @see related
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
- * @version $Revision: 1.9 $ p
+ * @version $Revision: 1.10 $ p
*
* b20010830 marc fleury:/b
* ulinitial import
@@ -44,13 +44,11 @@
* /ul
*
*/
-
public class ServiceLibraries
implements ServiceLibrariesMBean, MBeanRegistration
{
-
- // JBoss logger version move to log4j if needed
- //Log log = Log.createLog(VM-ClassLoader);
+ /** The bootstrap interface to the log4j system */
+ private static BootstrapLogger log =
BootstrapLogger.getLogger(ServiceLibraries.class);
// Static
private static ServiceLibraries libraries;
@@ -149,7 +147,8 @@
Set classLoaders2;
long clToResourceSetMapVersion2;
- synchronized (this) {
+ synchronized (this)
+ {
// Is it in the global map?
if (resources.containsKey(name))
return (URL)resources.get(name);
@@
Re: [JBoss-dev] init - create simple API change
What is wrong with init? I mean why does the working seem unclear? --jason On Fri, 7 Dec 2001, marc fleury wrote: short and sweet, [b]init/destroy[/b] will become [b]create/destroy[/b] is much clearer: you use this to create your service, set it up, expensive operation done, destroy is explicit start/stop was clear: you use this to start and stop SO IF YOU HAVE MBEANS OUT THERE make sure to port the [b]init to create[/b]. This only applies to your custom MBeans I will of course update the ones in cvs It is going to create a bit or portability problems but I think making this clear once and for all is a good thing (and this one is simple) __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5202 ___ 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 build.xml
User: starksm
Date: 01/12/07 20:40:46
Modified:.build.xml
Log:
Include org/jboss/system/BootstrapLogger.class in the jboss-boot.jar
Revision ChangesPath
1.43 +2 -1 jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/build.xml,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- build.xml 2001/12/06 02:16:10 1.42
+++ build.xml 2001/12/08 04:40:46 1.43
@@ -12,7 +12,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.42 2001/12/06 02:16:10 user57 Exp $ --
+!-- $Id: build.xml,v 1.43 2001/12/08 04:40:46 starksm Exp $ --
project default=main name=JBoss/Server
@@ -493,6 +493,7 @@
!-- Build jboss-boot.jar --
jar jarfile=${build.lib}/jboss-boot.jar
fileset dir=${build.classes}
+include name=org/jboss/system/BootstrapLogger.class/
include name=org/jboss/system/URLClassLoader.class/
include name=org/jboss/system/URLClassLoaderMBean.class/
include name=org/jboss/system/MBeanClassLoader.class/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] init - create simple API change
|SO IF YOU HAVE MBEANS OUT THERE make sure to port the [b]init to |create[/b]. | |This only applies to your custom MBeans I will of course update |the ones in cvs Well it is done, move done in (my local cvs) for all the init-create, man I better finish the proxy debugging tomorrow otherwise by the end of the weekend I won't be able to commit all the classes this changed since you guys will probably commit in parralel in the meantime, but since this is one-liners in all classes it shouldnt throw diff off (bad surprises this morning after 3 weeks in cvs isolation) Jason what part of the following sentences: 1- the word create is more explicit than the word init 2- create/destroy makes more sense to me than init/destroy can you not parse, that is what is wrong with init any questions, talk to my horse, I am signing off, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] init - create simple API change
Jason what part of the following sentences: 1- the word create is more explicit than the word init 2- create/destroy makes more sense to me than init/destroy can you not parse, that is what is wrong with init any questions, talk to my horse, I am signing off Perhaps it is just my interpretation of the words init create. I think that init would perforce post construction initialization. Create is more of a factory method, which might return an instance of something.Whatever, if you like create over init, then create it is... it just seems a little strange to me. Mai pen rai. --jason __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5202 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 162 Successful tests: 159 Errors:1 Failures: 2 we are almost there it seems Yes - out of 162 We have a 100% success rate - the above test stat is missing that XA is not a valid test *now* (Error) therefore it should be removed - and if javac is in the classpath the other 2 is cleared as well ... ___ 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: 162 Successful tests: 159 Errors:1 Failures: 2 [time of test: 8 December 2001 5:38 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: 162 Successful tests: 159 Errors:1 Failures: 2 [time of test: 8 December 2001 6:55 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
