[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java DLQHandler.java
User: pra
Date: 01/12/11 01:45:55
Modified:src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
DLQHandler.java
Log:
Added configurability of exception reconnect interval and if DQL should be used;
also some doc and toString function
Revision ChangesPath
1.34 +81 -24
jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
Index: JMSContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- JMSContainerInvoker.java 2001/11/26 03:12:28 1.33
+++ JMSContainerInvoker.java 2001/12/11 09:45:54 1.34
@@ -47,7 +47,7 @@
import org.jboss.metadata.XmlLoadable;
import org.w3c.dom.Element;
-
+import org.w3c.dom.Node;
/**
* ContainerInvoker for JMS MessageDrivenBeans, based on JRMPContainerInvoker.
*
@@ -57,7 +57,7 @@
* /a
* @authora href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @authora href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @version $Revision: 1.33 $
+ * @version $Revision: 1.34 $
*/
public class JMSContainerInvoker
implements ContainerInvoker, XmlLoadable
@@ -87,27 +87,37 @@
protected boolean optimize;
// = false;
/**
-* Description of the Field
+* Maximu number provider is allowed to stuff into a session.
*/
protected int maxMessagesNr = 1;
/**
-* Description of the Field
+* Maximun pool size of server sessions.
*/
protected int maxPoolSize = 15;
/**
-* Description of the Field
+* Time to wait before retrying to reconnect a lost connection.
+*/
+ protected long reconnectInterval = 1;
+ /**
+* If Dead letter queue should be used or not.
+*/
+ protected boolean useDLQ = false;
+ /**
+* JNDI name of the provider adapter.
+* @see org.jboss.jms.jndi.JMSProviderAdapter
*/
protected String providerAdapterJNDI;
/**
-* Description of the Field
+* JNDI name of the server session factory.
+* @see org.jboss.jms.asf.ServerSessionPoolFactory
*/
protected String serverSessionPoolFactoryJNDI;
/**
-* Description of the Field
+* JMS acknowledge mode, used when session is not XA.
*/
protected int acknowledgeMode;
/**
-* Description of the Field
+* escription of the Field
*/
protected boolean isContainerManagedTx;
/**
@@ -115,15 +125,15 @@
*/
protected boolean isNotSupportedTx;
/**
-* Description of the Field
+* The container.
*/
protected Container container;
/**
-* Description of the Field
+* The JMS connection.
*/
protected Connection connection;
/**
-* Description of the Field
+* TH JMS connection consumer.
*/
protected ConnectionConsumer connectionConsumer;
/**
@@ -143,13 +153,13 @@
*/
protected String beanName;
/**
-* Description of the Field
+* Dead letter queue handler.
*/
protected DLQHandler dlqHandler;
/**
-* Description of the Field
+* DLQConfig element from MDBConfig element from jboss.xml.
*/
- protected Element mdbConfig;
+ protected Element dlqConfig;
/**
* Instance logger.
@@ -272,7 +282,9 @@
log.debug(Destroying JMSContainerInvoker for bean + beanName);
// Take down DLQ
- dlqHandler.destroy();
+ if ( dlqHandler != null) {
+ dlqHandler.destroy();
+ }
// close the connection consumer
try
@@ -316,7 +328,10 @@
}
/**
-* XmlLoadable implementation
+* XmlLoadable implementation.
+*
+* FIXME - we ought to move all config into MDBConfig, but I do not
+* do that now due to backward compatibility.
*
* @param element Description of Parameter
* @exception DeploymentException Description of Exception
@@ -332,6 +347,22 @@
String maxSize = MetaData.getElementContent
(MetaData.getUniqueChild(element, MaximumSize));
maxPoolSize = Integer.parseInt(maxSize);
+
+ Element mdbConfig = MetaData.getUniqueChild(element, MDBConfig);
+
+ String reconnect = MetaData.getElementContent
+ (MetaData.getUniqueChild(mdbConfig, ReconnectIntervalSec));
+ reconnectInterval = Long.parseLong(reconnect)*1000;
+
+ // Get Dead letter queue config - and save it for later use
+ Element dlqEl = MetaData.getOptionalChild(mdbConfig, DLQConfig);
+ if (dlqEl != null) {
+ dlqConfig = (Element)((Node)dlqEl).cloneNode(true);
+
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjboss.xml
User: pra Date: 01/12/11 01:47:44 Modified:src/etc/conf/default standardjboss.xml Log: Added config element ReconnectIntervalSec and moved DLQ stuff to DLQConfig element in MDBConfig element Revision ChangesPath 1.26 +7 -4 jboss/src/etc/conf/default/standardjboss.xml Index: standardjboss.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- standardjboss.xml 2001/11/09 23:04:47 1.25 +++ standardjboss.xml 2001/12/11 09:47:44 1.26 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: standardjboss.xml,v 1.25 2001/11/09 23:04:47 slaboure Exp $ -- +!-- $Id: standardjboss.xml,v 1.26 2001/12/11 09:47:44 pra Exp $ -- jboss enforce-ejb-restrictionsfalse/enforce-ejb-restrictions @@ -591,9 +591,12 @@ MaxMessages1/MaxMessages OptimizedTrue/Optimized MDBConfig - DestinationQueuequeue/DLQ/DestinationQueue - MaxTimesRedelivered10/MaxTimesRedelivered - TimeToLive-1/TimeToLive +ReconnectIntervalSec10/ReconnectIntervalSec +DLQConfig + DestinationQueuequeue/DLQ/DestinationQueue + MaxTimesRedelivered10/MaxTimesRedelivered + TimeToLive-1/TimeToLive +/DLQConfig /MDBConfig /container-invoker-conf container-pool-conf ___ 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: 127 Successful tests: 127 Errors:0 Failures: 0 [time of test: 11 December 2001 9: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! 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 org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - kill -9 See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-491490 ] New config elements for MDB
Change Notes item #491490, was opened at 2001-12-11 01:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=491490group_id=22866 Category: JBossServer Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Peter Antman (pra) Assigned to: Nobody/Anonymous (nobody) Summary: New config elements for MDB Initial Comment: Added possibility to configure the interval for retries of reconnect in case of connection failure. The new element is ReconnectIntervalSec in MDBConfig. The Dead letter queue config was moved to a child element of MDBConfig: DLQConfig. This element is also optional. If removed from config no deal letter queue will be used. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=491490group_id=22866 ___ 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-11 02:03 Message: Logged In: YES user_id=91163 Ok, I looked into it. The error message suggests one of the three following: 1) The validateDTD flag is not properly passed on to the xml parser in the JBoss code. I checked it and this is not the case (look at XmlFileLoader.getDocument method) 2) The validateDTD flag is properly passed on to the xml parser but the implementation of the xml parse is faulty and does not take the flag into account. This means there is a bug to be reported to the Crimson folk at Apache. 3) The validateDTD flag is properly passed on and the parser does not validate the XML but still needs to be able to access the DTD. In this case again the question needs to be passed on to the Crimson. Maybe it is a good practice (?). Does that make sens? Also when is the jboss_3_0.dtd going to be available? -- Comment By: Guillaume Coté (gcote) Date: 2001-12-10 01:49 Message: Logged In: YES user_id=15328 For
[JBoss-dev] [ jboss-Patches-491497 ] Third party Deployers and Auto Deployer
Patches item #491497, was opened at 2001-12-11 02:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=491497group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Nobody/Anonymous (nobody) Summary: Third party Deployers and Auto Deployer Initial Comment: SUMMARY A patch to allow a deployer to add and remove itself from the AutoDeployer. This is done automatically when derived from DeployerMBeanSupport during registration. This change is aimed at allowing third-party plugin deployers to use the auto-deployer. Added same processing to J2eeDeployer, I haven't done the scoped deployer. With these changes, only ServiceDeployer needs to be configured in the AutoDeployer Deployers attribute in jboss-service.xml AUTODEPLOYER CHANGES New MBean methods addDeployer(), removeDeployer() and getDeployerNames() addDeployer() performs the same processing as adding the JMX name to the Deployers attribute at start up. In fact the Deployers attribute is now processed through addDeployer removeDeployer() removes the deployer from auto-deployment added code to the run() thread to remove watches for removed deployers the urls are NOT undeployed getDeployerNames() lists all active auto-deployer deployers as opposed to getDeployers which only contains the configuration from jboss-service.xml Changed the deployer arrays to be collections so they can dynamically grow and contract. Added synchornization to avoid concurrency problems between MBean methods and the run() thread. Specifically when undeploying a deployer which also undeploys it's urls at the same time. It works but there's some untidyness and existing problems PROBLEMS The ServiceDeployer is derived from DeployerMBeanSupport. This leads to a warning about the AutoDeployer not being present at start-up. It still auto-deploys because it is listed in the Deployers attribute. The AutoDeployer is undeployed before the RARDeployer this leads to a trapped error reporting a missing AutoDeployer at shutdown. Because the watches are removed when the deployer is removed from the AutoDeployer, re-adding the deployer leads to all the deployer's urls redeploying. The watches are removed because otherwise the urls would still try to auto-deploy, see later. The watches aren't removed until the next cycle of the run() thread. This avoids concurrency problems. addDeployer/removeDeployer might be confusing names from a JMX user point of view since the deployers are only added/removed from the autodeployer not the server. The alternative register/unregister might be confused with JMX registion. link/unlink The Deployers and DeployerNames attributes will be confusing as well! Perhaps these can be combined? Excessive use of the word deploy in this patch about automatically adding/removing deployers to the auto-deployer when they are deployed/undeployed :-) PROBLEMS THAT ALREADY EXISTED The watches not being removed at deregistration of the deployer was a problem. The AutoDeployer reported an InstanceNotFoundException for the deployer when one of the watched urls is modified. - FIXEDish This could still happen when a deployer.sar is removed at the same time as one of its urls and the two requests go through on the same cycle of the run() thread. It's NOT a FATAL though. The next cycle should remove the watched url. Another existing problem is that a stopped deployer will still deploy through the AutoDeployer because the watches aren't removed. - not fixed The default deployer doesn't work as originally intended. I've made what it does explicit but it's not correct. It originally tried to deploy a directory containing META-INF/ejb-jar.xml using the J2eeDeployer. At the moment it actually uses the service deployer. I've commented some of the issues with my initials ARB - not fixed Regards, Adrian NOTE: A lot of the AutoDeployer patch is due realigning code. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=491497group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491536 ] NPE in JDBCCreateEntityCommand.java
Bugs item #491536, was opened at 2001-12-11 04:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491536group_id=22866 Category: JBossCMP Group: v2.4 (stable) Status: Open Resolution: None Priority: 1 Submitted By: Vincent Harcq (vharcq) Assigned to: Vincent Harcq (vharcq) Summary: NPE in JDBCCreateEntityCommand.java Initial Comment: This is an ooold one, that still fuck up a lot of users. It has to do with PK definition in ejb-jar.xml (I think). I will have a look someday. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491536group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: A State of the Machine Running
We just need to rip out all the punctuation keys out of his keyboard. Regards, Hiram From: David Budworth [EMAIL PROTECTED] To: Dain Sundstrom [EMAIL PROTECTED] CC: 'Peter Fagerlund' [EMAIL PROTECTED], Jason Dillon [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Re: A State of the Machine Running Date: Mon, 10 Dec 2001 18:49:36 -0800 Can someone send me the procmail filter that makes Peter's messages readable? -David On Mon, 10 Dec 2001, Dain Sundstrom wrote: huh? Do you every use full sentences? -dain -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 8:40 PM To: Jason Dillon Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] Re: A State of the Machine Running on 1-12-11 03.35, Jason Dillon at [EMAIL PROTECTED] wrote: Ok, one more time... Huh? Two times -heh *** We need a state -spine thing : --to deploy on ---then Auto/level/grade/scope/... deloyer() has a state ... /peter_f --jason On Tue, 11 Dec 2001, Peter Fagerlund wrote: Is it me or U that have the -clockoff ? ... /peter_f on 1-12-11 03.28, Jason Dillon at [EMAIL PROTECTED] wrote: Huh? --jason On Tue, 11 Dec 2001, Peter Fagerlund wrote: Starting Suspended Stopping returning anything else means running ? ... ;-) /peter_f ___ 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 _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
I agree with David. If we wanted to aproach SysV runlevels, our conf directories would have to be the ones that would be called level1,...,level6 I also want to make a quick point on something that has bothered me since the begining. I use multiple conf's in a single JBoss installation. This forces me to also create multiple deploy directories since I don't want the same deployments for all the configurations. My beef is that it seems natural to me to have a different set of deployments for different configurations, but the way the directory structure is right now does not lend itself too well for that type of organization. Am I just smoking crack or something?? Hiram From: David Budworth [EMAIL PROTECTED] To: Jason Dillon [EMAIL PROTECTED] CC: David Jencks [EMAIL PROTECTED], jboss-dev [EMAIL PROTECTED] Subject: Re: [JBoss-dev] (rh) startup levels proposal and questions. Date: Mon, 10 Dec 2001 19:16:43 -0800 I would also like to make sure that any docs, don't refer to this (assuming it gets implemented) as being like SysV runlevels (like Linux,Solaris,etc..) runlevels aren't even remotely working like this. Each runlevel in a SysV init style is a self contained state. Meaning, init 5 does not do init 1,2,3,4,5. Runlevel 5, contains every thing that should/should not be running when at level 5. That's why they have S01xxx S02yyy K01zzz The K??* scripts run first, then all S??* run, in sorted order. I do wonder though, will splitting the directories up make administration more difficult? If you want guaranteed deployment order, you could always name all the items in deploy/* with numbers at the start. ie: 00hsqldb-service.xml 00blah-service.xml 01cluster-service.xml Then just have the deployer always ensure to sort the dir list, and process in order. That way, in Bill's case, he could just call his SAR (or whatever), 99Bill.sar Guaranteed to deploy after the ones that sort first. Having the whole runlevel type thing might just confuse people (especially unix admins, if you don't give them SysV type runlevels) Just a thought, -David On Mon, 10 Dec 2001, Jason Dillon wrote: Everything in level1 will be deployed, then everything in level2, etc. I think this will give enough control over deployment order for almost all circumstances. (I'd like examples of anything it won't work for). I think we might want to use different names, as level1-6 might get a little confusing. Perhaps we could assign these levels meaningful names: bootstrap system user Could also nest the structure for better naming too: system/ bootstrap/ core/ db/ cluster/ jms/ user/ whatever/ samesame/ Now, in Linux you can init 3 or init 6. So far you can't do this here. Is that a valuable feature for jboss? (i.e. being able to say deploy levels 1,2,3. Now deploy 4,5,6. Now undeploy 6, 5, 4, 3) How would it be used? Yikes, I hope there aren't any Linux systems that will init 6 and do anything short of boot... I hope you mean init 5 (X11). Would this be more or less convenient to use than a deployment script facility where each script basically had a list of what is in one of these level directories? I don't think that the actual notion of levels makes sence for the AD, but seperating things for ordering certainly does. --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 _ 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
AW: [JBoss-dev] Question about Scoped Deployer
Hi Anatoly, I just found your e-mail from ages ago in my mailbox ... what a shame :-( The J2eeScopeDeployer is a prototype that worked just at the level of ear´s and should enlighten the concept of alternative classloading. The current RH-sar-ServiceDeployer is derived from that code, but works at another level of classloading (the former Mbean level). If you look at the current efforts, I think that it is now tried to unify the sar classloader stuff with the rest of the deployer code, maybe by having scoped deployment features in DeploymentMBeanSupport ... The tomcat/jetty problem (or better: the f***cked compiler problem) is tried to solve by Jules currently by (re-)collecting the jar locations from the classloaders ... Not very nice, but another stance of work around big company, but small brain output. CGJ -Ursprüngliche Nachricht- Von: Anatoly Akkerman [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 7. November 2001 23:52 An: JBoss-Dev Betreff: [JBoss-dev] Question about Scoped Deployer Hi, First and foremost, thank you, Dr. Jung. I was wondering if scoped deployment is capable of handling the WAR archives as well (stored in an EAR of their own). From my initial tests and without looking at the code (being lazy :) it seems that Tomcat cannot load classes from the common Scope class loader (at least when compiling JSPs ?) Perhaps it has to do with how it compiles the JSPs, i.e. the compiler only looks into its classpath (perhaps setup by Tomcat to include the WEB-INF/classes directory plus the standard jars) and does not use the classloader to obtain the classes. Could this be the culprit? Thank you. Anatoly Akkerman. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
Now I'm getting confused... Thanks to those who pointed out my lack of understanding of SysV runlevels. However it is done, does anyone want something like SysV, where there are different levels of services available at each runlevel, and you can do something like jboss-init 3 to get to having only the level 3 services running? Is it sufficient to have more control over deployment ordering? Who likes the list of directories approach? (either level1, level2,... or system/base system/..., user/base, user/app, user/final or whatever) Who likes the lexicographically ordered list approach? (one deploy directory, files named 0001boot.sar, 011jboss.sar, 012jetty.sar, ..., 990app27.ear, 991userstartup.sar) (one possible problem with this is if you want to insert something between 780app1.ear and 782userservices.sar you have to rename stuff. But it does give you more control over the ordering). Personally I like the list of directories, with no other runlevel ideas. I don't mind sorting the file names, but would rather not force people to rely on it. (I'm happy with list of directories + sorted filenames within a directory). Hiram, I don't understand your problem with deploy dirs and different configurations. Can't you have directories deploy/conf1/lib deploy/conf1 deploy/conf2/lib deploy/conf2 ? Are you suggesting that the default dir setup be like deploy/default/lib deploy/default including the conf name in the path? david jencks On 2001.12.11 09:29:30 -0500 Hiram Chirino wrote: I agree with David. If we wanted to aproach SysV runlevels, our conf directories would have to be the ones that would be called level1,...,level6 I also want to make a quick point on something that has bothered me since the begining. I use multiple conf's in a single JBoss installation. This forces me to also create multiple deploy directories since I don't want the same deployments for all the configurations. My beef is that it seems natural to me to have a different set of deployments for different configurations, but the way the directory structure is right now does not lend itself too well for that type of organization. Am I just smoking crack or something?? Hiram From: David Budworth [EMAIL PROTECTED] To: Jason Dillon [EMAIL PROTECTED] CC: David Jencks [EMAIL PROTECTED], jboss-dev [EMAIL PROTECTED] Subject: Re: [JBoss-dev] (rh) startup levels proposal and questions. Date: Mon, 10 Dec 2001 19:16:43 -0800 I would also like to make sure that any docs, don't refer to this (assuming it gets implemented) as being like SysV runlevels (like Linux,Solaris,etc..) runlevels aren't even remotely working like this. Each runlevel in a SysV init style is a self contained state. Meaning, init 5 does not do init 1,2,3,4,5. Runlevel 5, contains every thing that should/should not be running when at level 5. That's why they have S01xxx S02yyy K01zzz The K??* scripts run first, then all S??* run, in sorted order. I do wonder though, will splitting the directories up make administration more difficult? If you want guaranteed deployment order, you could always name all the items in deploy/* with numbers at the start. ie: 00hsqldb-service.xml 00blah-service.xml 01cluster-service.xml Then just have the deployer always ensure to sort the dir list, and process in order. That way, in Bill's case, he could just call his SAR (or whatever), 99Bill.sar Guaranteed to deploy after the ones that sort first. Having the whole runlevel type thing might just confuse people (especially unix admins, if you don't give them SysV type runlevels) Just a thought, -David On Mon, 10 Dec 2001, Jason Dillon wrote: Everything in level1 will be deployed, then everything in level2, etc. I think this will give enough control over deployment order for almost all circumstances. (I'd like examples of anything it won't work for). I think we might want to use different names, as level1-6 might get a little confusing. Perhaps we could assign these levels meaningful names: bootstrap system user Could also nest the structure for better naming too: system/ bootstrap/ core/ db/ cluster/ jms/ user/ whatever/ samesame/ Now, in Linux you can init 3 or init 6. So far you can't do this here. Is that a valuable feature for jboss? (i.e. being able to say deploy levels 1,2,3. Now deploy 4,5,6. Now undeploy 6, 5, 4, 3) How would it be used? Yikes, I hope there aren't any Linux systems that will init 6 and do anything short of boot... I hope you mean init 5 (X11). Would this be more or less convenient to use than a deployment script facility where each script basically had a list of what is in one of these level directories? I don't think that the actual notion of levels makes
[JBoss-dev] AutoDeployer and Deployers
Hi, I have a question about the AutoDeployer. It monitors for MBean registration of the deployers so that it can ask them for their FilenameFilter. At deregistarion it removes their FilenameFilter. Why isn't this done after service start and stop? If you stop the J2eeDeployer and then touch xxx.jar the AutoDeployer spots it and deploys it through J2eeDeployer. Is it trying to support deployers not derived from ServiceMBeanSupport? Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5470 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
Now I'm getting confused... Is it sufficient to have more control over deployment ordering? Who likes the list of directories approach? Guys from the mine I am rewriting still some stuff in the controller, I reimplemented the depends on the explicit mbean name, did away with some mbean-ref stuff. This is simple for now, Really and I mean it, lately on this list we have a tendency to complicate simple things, I think it is due to developers over-engineering features. And really that is not good, we need to keep our reputation in ease of administration and all this is not going in that direction. Let me commit (I am dying here) and we will take it from there. working low tech is good tech, broken high tech is bad tech. remember this is open source and if *I* have to read a class for 2 days before I understanding what it is trying to do, and then realize what it is trying to do is not really useful, this is really irritating and will kill our codebase in the short run. Open Source is about maintaining codebases in the open, if the SOURCE fails to do that, the rest of the construction fails as well. I know I proposed the run levels myself, and I am not shutting down the proposal, it will probably be a simple way to non-explicitely build dependencies between starting units. (BTW I reimplemented the page scope thing and stepped create/start bill was bitching about) But for now, let's see how the simple depend works. I think we will find it covers most cases and the code went from 500 lines down to about 40... I really try to make as simple as I can... I really try marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5378 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] (rh) startup levels proposal and questions.
non-explicitely build dependencies between starting units. (BTW I reimplemented the page scope thing and stepped create/start bill was bitching about) But for now, let's see how the simple depend What is stepped create/start? Do you mean you put back init() and start() for mbeans? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
Hiram, I don't understand your problem with deploy dirs and different configurations. Can't you have directories deploy/conf1/lib deploy/conf1 deploy/conf2/lib deploy/conf2 ? Are you suggesting that the default dir setup be like deploy/default/lib deploy/default Yes, that would be nice. Since the default layout is setup to support multiple conf dirs, it makes sense to my to have multiple deploy dirs too. Would that be too confusing for a beginer. _ 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] Can xdoclet not do unnecessary work?
Is there a reasonably simple way to make xdoclet only run if one of the files it is processing has changed? Most of the time for my server module builds seems to be taken with xdoclet, and I never change stuff it starts with. Thanks david jencks __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
Actually what if the deploy directory was a subdir of the conf directory? That doesnt seem like it would be too confusing to even a new user. Al [EMAIL PROTECTED] wrote: Hiram, I don't understand your problem with deploy dirs and different configurations. Can't you have directories deploy/conf1/lib deploy/conf1 deploy/conf2/lib deploy/conf2 ? Yes, that would be nice. Since the default layout is setup to support multiple conf dirs, it makes sense to my to have multiple deploy dirs too. Would that be too confusing for a beginer. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] (rh) startup levels proposal and questions.
What is stepped create/start? Do you mean you put back init() and start() for mbeans? Yes Stepped means (nothing really) that I have made the beans that are dependent and the beans that are deployed as part of the same page (service.xml/jboss.jcml start) call their create and start in synchronization. example: service.xml --mbean1 --mbean2 --mbean3 depends mbean4 --mbean4 will yield create() (old init()) on mbean1 mbean2 mbean4 mbean3 THEN start() on mbean1 mbean2 mbean4 mbean3 if mbean 4 is stopped mbean 3 is stopped automatically if an mbean4 is restarted mbean 3 is restarted automatically. marcf I am walking in rythm, moving in sound, humming to the music, trying to move on, I am walking in rythm, singing my song, thinking bout my baby, trying to get home -- The blackbirds walking in rythm -- __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5378 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
I like the idea of site \- default \- conf \- deploy \- logs \- whatever \- cluster \- conf \- deploy \- logs \- whatever Having the named deploy dirs like system/user/etc still doesn't give the user an instant clue as to what runs first. I would guess, making it more simple: 1) for all files in deploy, deploy each one in sorted order 2) for all directories (in sorted order), deploy each file in it (and walk the dir tree for as much depth as you want) so, order of execution deploy/aaa-service.xml deploy/a/aaa-service.xml deploy/b/aaa-service.xml Still maintaining the depends or ejb-ref system for dependancies. But make site/default/deploy be exactly as it is today. So, to the un-initiated, the only real change from 2.4 is the fact that we made the conf/deploy/whatever as a single unit, easily backed up, or CVS controlled. But, when someone needs some kind of I need to deploy after EVERYTHING else is deployed, they just name the file deploy/ZZ-whatver-service.xml And if they want to get more fancy with runlevel type stuff, they can move it all around as much as they want. Then, jboss-init could really just be as simple as a shutdown/restart with new config. ie: run.sh does #make sure to clean up old state in case we crashed when restarting if [ -f newconf.cfg ] ; then rm newconf.cfg; fi if [ -z $1 ]; then CONF=default else CONF=$1 fi while (true); do java -Dconfig=$CONF if [ -f newconf.cfg ]; then CONF=`cat newconf.cfg` rm newconf.cfg continue fi echo JBoss Shutdown exit done This would allow admins to get pseudo uptime of jboss by checking the start time of run.sh, and you'd be ensured no funky leaks when switching configs. And you don't have to worry about KXXX scripts, since the server bounces each runlevel change. Ok, maybe this is overkill. But it allows more control of deployment, while still allowing the current directory layout, and doesn't add a bunch of complexity to the code. Just add to the payfor-docs the description, or maybe even examples of ways you can use this. -David On Sun, 11 Nov 2001, Allen Fogleson wrote: Actually what if the deploy directory was a subdir of the conf directory? That doesnt seem like it would be too confusing to even a new user. Al [EMAIL PROTECTED] wrote: Hiram, I don't understand your problem with deploy dirs and different configurations. Can't you have directories deploy/conf1/lib deploy/conf1 deploy/conf2/lib deploy/conf2 ? Yes, that would be nice. Since the default layout is setup to support multiple conf dirs, it makes sense to my to have multiple deploy dirs too. Would that be too confusing for a beginer. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Can xdoclet not do unnecessary work?
David, here is a useful feature, can we make xdoclet part of JBoss standard? Andreas and Rickard are part of that project. Is there a way to detect automatically on deployment that the file needs doclet processing and have it generate the stuf? it would really stop the buaaah I have to edit my xml files by hand crying that we see so much of these days... let me know __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491613 ] Server stops delivering messages to MDBs
Bugs item #491613, was opened at 2001-12-11 08:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Hiram Chirino (chirino) Summary: Server stops delivering messages to MDBs Initial Comment: hi, we found a very hard to reproduce bug in JBossMQ; it *might* be a race condition. We tracked the problem down to the interaction between org.jboss.mq.server.BasicQueue and org.jboss.mq.SpyConnectionConsumer. Here's what happens: SpyConnectionConsumer.java reaches line 105 (commented unwanted msg) and delivers a NACK. BasicQueue.java receives the NACK and tries to restore the message using the restoreMessage() method. However, from that point of time *NO* receiver is being added to the receivers list in BasicQueue.java, resulting in the internal message queue growing without EVER delivering any messages anymore. This *only* happens when Line 105 in SpyConnectionConsumer.java is invoked -- if my MDB calls setRollbackOnly(), everything continues working. As I said, this is *very* hard to reproduce and my guess is on a race condition. We tried to fix this on our own but got lost in the MQ magic. P.S.: Running JBoss 2.4.4 CVS as of today but this bug has been in before as it seems, we're getting the same behaviour on a vanilla 2.4.3 configuration. I'll try to come up with a testcase if you need it. -- Comment By: Christian Riege (lqd) Date: 2001-12-11 08:19 Message: Logged In: YES user_id=176671 ooops, forgot one maybe important detail: if i have multiple MDB's deployed, the effect will only show up on a per-bean basis. i.e. i have one bean which is b0rked while other MDB's are running along just fine. obviously the effect shows up on the bean with the heaviest traffic first but the other beans get affected after a certain amount of time, too. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] (rh) startup levels proposal and questions.
Maybe you could give a specific example of why the 2 stage startup is useful. Even Rickard said the init step should not refer to anything outside the mbean being inited. I can't see any way the mbeans can distinguish 1,2,3, or 17 stage startup if only the last can refer to other mbeans. Are you using this to hide dependencies between mbeans? __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5378 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] (rh) startup levels proposal and questions.
david, stop wasting my time __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5378 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491613 ] Server stops delivering messages to MDBs
Bugs item #491613, was opened at 2001-12-11 08:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Hiram Chirino (chirino) Summary: Server stops delivering messages to MDBs Initial Comment: hi, we found a very hard to reproduce bug in JBossMQ; it *might* be a race condition. We tracked the problem down to the interaction between org.jboss.mq.server.BasicQueue and org.jboss.mq.SpyConnectionConsumer. Here's what happens: SpyConnectionConsumer.java reaches line 105 (commented unwanted msg) and delivers a NACK. BasicQueue.java receives the NACK and tries to restore the message using the restoreMessage() method. However, from that point of time *NO* receiver is being added to the receivers list in BasicQueue.java, resulting in the internal message queue growing without EVER delivering any messages anymore. This *only* happens when Line 105 in SpyConnectionConsumer.java is invoked -- if my MDB calls setRollbackOnly(), everything continues working. As I said, this is *very* hard to reproduce and my guess is on a race condition. We tried to fix this on our own but got lost in the MQ magic. P.S.: Running JBoss 2.4.4 CVS as of today but this bug has been in before as it seems, we're getting the same behaviour on a vanilla 2.4.3 configuration. I'll try to come up with a testcase if you need it. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Can xdoclet not do unnecessary work?
(about automatically running xdoclet as part of deployment process) I'll see if I can find a few minutes to think about it. It would mean deployment now includes code generation, compilation, and packaging. So far I haven't thought of a way to do this in autodeploy mode without explicitly invoking ant. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Can xdoclet not do unnecessary work?
explicitely invoking ant is good :) __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] (rh) startup levels proposal and questions.
Hi David The best example I have right now is JSR-77. Because the JSR-77 management components are shadow MBeans of offer JBoss components they have to be created when the JBoss MBean is created and destroyed when its master get destroyed. But as you know JBoss components are not finally set until there attributes are set (otherwise we would have to use the unnamed constructor arguments). Therefore JSR-77 creation cannot rely on the creation of the MBean component but must rely when the MBean is finally set. Therefore I need the init() method to have a point where the MBean is set and I can create the JSR-77 component. You may ask why not create in the start() method but JSR-77 components allows the administrator to start AND stop the component behind it. If now the creation of the JSR-77 component is in start() and the destruction in stop() I am not able to restart the JSR-77 component (and then as well as the JBoss component). Andy - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 10:14 AM Subject: Re: RE: [JBoss-dev] (rh) startup levels proposal and questions. Maybe you could give a specific example of why the 2 stage startup is useful. Even Rickard said the init step should not refer to anything outside the mbean being inited. I can't see any way the mbeans can distinguish 1,2,3, or 17 stage startup if only the last can refer to other mbeans. Are you using this to hide dependencies between mbeans? __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5378 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] (rh) startup levels proposal and questions.
david, stop wasting my time David I apologies, I feel bad and I will explain the way I see it now. 2 steps: there is a creation of the service step and a start of the service state. We could in fact say postRegister() should be used for that, but then andreas pointed out that he needed configuration to be done and that is done after registration. I think I think of it as a 2 phase commit protocol. Any time you have distributed objects that are dependent between each other (the 2phi being a dependency on everyone else committing). linear dependency (tree) allows for one step, I think that that much you have established. I believe that you could in fact *prove* it. but the 2phi allows set of dependent services as opposed to linear structures. The mathematicians in us will appreciate that Set Linear Graphs I am french and raised on sets Then there is the simple legacy reason, folks have grown to view create and start as different lifecycles on their services, and I see nothing wrong with that, might be redundant (you say the factorization only needs one call, I agree on linear graphs disagree on sets), but there is an extremelly clear sentence being said to service developers. Simple semantics is good. And it is what they know. So that is a reason why I like sets, sorry for saying don't waste my time these are non -trivial points :D Can we close this case and I will ask you to take a few minutes to review the 40 lines in ServiceDeployer __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5378 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: AutoDeployer and Deployers
I think this is pretty much accidental and not thought through. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5470 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Bugs, mostly: Server stops delivering messsages.
OK so I have never been able to work out exactly how people get assigned to bugs that have been reported. There is a note on the sourceforge bug tracker page about assigning yourself to bugs you are going to fix to avoid duplicated effort. This is clearly a good idea, I just don't know how to do it. Also how do you change the status of a bug report (to close it etc). Maybe I don't have the required permissions do these things? I'm not sure if any special permissions are required. Anyway, Hiram, the point of my above question is that I am pretty sure I know what the problem is for the recently reported bug #491613 that has been assigned to you, do you want me to fix it? Or just let you know what I think the problem is. David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can xdoclet not do unnecessary work?
On 2001.12.11 14:46:49 -0500 Ean Schuessler wrote: Something I don't understand about xdoclet. Doesn't putting the ejb-jar configuration information into your source code sort of defeat the purpose of having a deployment descriptor? I thought that the whole idea was to decouple the configuration from the source. Personally, I've hardly used xdoclet (may change soon;-)) I think the generation of home and remote and local and local-home interfaces is universally and unconditionally a good idea. Generation of config files seems to me to imply that each ejb will be deployed using only one dd. This is presumably by far the most frequent case, and for that it makes a lot of sense. Generating all the dd's for different app servers seems pretty useful too. So, my current uninformed optinion is that it makes the most frequent use really easy, and provides something to modify for other cases when you need to deploy the same codebase as several ejbs. I think it is mostly targeted at ejb development, where one person is filling all those roles at once. If you have a separate deployer-person, at least it gives you somewhere to start. david jencks On Tue, 2001-12-11 at 11:00, David Jencks wrote: Is there a reasonably simple way to make xdoclet only run if one of the files it is processing has changed? Most of the time for my server module builds seems to be taken with xdoclet, and I never change stuff it starts with. -- _ Ean Schuessler [EMAIL PROTECTED] Brainfood, Inc. http://www.brainfood.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can xdoclet not do unnecessary work?
Generation of config files seems to me to imply that each ejb will be deployed using only one dd. This is presumably by far the most frequent case, and for that it makes a lot of sense. Generating all the dd's for different app servers seems pretty useful too. So, my current uninformed optinion is that it makes the most frequent use really easy, and provides something to modify for other cases when you need to deploy the same codebase as several ejbs. I think it is mostly targeted at ejb development, where one person is filling all those roles at once. If you have a separate deployer-person, at least it gives you somewhere to start. I do not agree :O The [b]merging[/b] feature of xdoclet permits to do almost everything in multi deployment mode. It has really turned xdoclet from a developement tool to also a deployment tool. Personnally I deploy on different environments and never change a XML file by hand. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Can xdoclet not do unnecessary work?
Is there a reasonably simple way to make xdoclet only run if one of the files it is processing has changed? Most of the time for my server module builds seems to be taken with xdoclet, and I never change stuff it starts with. Xdoclet checks the timestamp of the file, if newer that the generated, then regenerate. The usual way of doing is to touch the files on every build so regenerates every time. The reason is the timestamp is not enough in special cases : update xdoclet with a new version (or being a xdoclet developer ;) ) or add a Tag in a super class (xdoclet goes through them :-) ). Second thing : xdoclet runs as fast as the speed, the problem is javadoc. Some people there develop [b]xjavadoc[/b] that will replace javadoc and hopefully run faster :O __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management MBeanFeatureInfo.java
User: squirest
Date: 01/12/11 13:18:24
Modified:src/main/javax/management MBeanFeatureInfo.java
Log:
formatting and prettying up
Revision ChangesPath
1.2 +24 -13jmx/src/main/javax/management/MBeanFeatureInfo.java
Index: MBeanFeatureInfo.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/MBeanFeatureInfo.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MBeanFeatureInfo.java 2001/12/03 02:01:30 1.1
+++ MBeanFeatureInfo.java 2001/12/11 21:18:24 1.2
@@ -1,31 +1,42 @@
/*
- * LGPL
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
*/
package javax.management;
-public class MBeanFeatureInfo extends java.lang.Object implements
java.io.Serializable {
-
- private String name= null;
+/**
+ * General information for MBean descriptor objects.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
+ *
+ * @version $Revision: 1.2 $
+ */
+public class MBeanFeatureInfo extends java.lang.Object
+ implements java.io.Serializable
+{
+
+ // Attributes
+ private String name = null;
private String description = null;
-
+
+ // Constructors --
public MBeanFeatureInfo(java.lang.String name,
- java.lang.String description) {
+ java.lang.String description)
+ {
this.name = name;
this.description = description;
}
- public java.lang.String getName()
+ // Public
+ public String getName()
{
return name;
}
- public java.lang.String getDescription()
+ public String getDescription()
{
return description;
}
-
-
-
-
}
-
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
However it is done, does anyone want something like SysV, where there are different levels of services available at each runlevel, and you can do something like jboss-init 3 to get to having only the level 3 services running? I don't see how a SysV-like configuration helps... rather it just introduces new wrinkles. Do you intent to have the server boot into these levels, starting and killing services in the running level? If not, then this talk about SysV doesn't make anysense. If you are talking about that, then it seems like we need to put together some more infrastructure to walk through those levels, starting and killing services. I personally don't see how it will be useful. I do however see that it would make sence to add more order to the organization of the deployment directory with respect to how these deployables get loaded. Is it sufficient to have more control over deployment ordering? Don't we already have this? Who likes the list of directories approach? (either level1, level2,... or system/base system/..., user/base, user/app, user/final or whatever) I would go with meaningful names rather than meaningless levels. Who likes the lexicographically ordered list approach? (one deploy directory, files named 0001boot.sar, 011jboss.sar, 012jetty.sar, ..., 990app27.ear, 991userstartup.sar) Yikes... no please, no. Could probably support this anyways for users who want it, but lets not force its usage. (one possible problem with this is if you want to insert something between 780app1.ear and 782userservices.sar you have to rename stuff. But it does give you more control over the ordering). If you want real ordering, specify the order in the URL of the deployment unit in the AutoDeployer list. Hiram, I don't understand your problem with deploy dirs and different configurations. Can't you have directories I *think* he might mean grouping rars, .ears, .wars and such... but that is just a guess. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management MBeanConstructorInfo.java MBeanInfo.java MBeanNotificationInfo.java MBeanOperationInfo.java MBeanParameterInfo.java
User: squirest
Date: 01/12/11 13:19:47
Modified:src/main/javax/management MBeanConstructorInfo.java
MBeanInfo.java MBeanNotificationInfo.java
MBeanOperationInfo.java MBeanParameterInfo.java
Log:
changed constructors to shallow-clone input arrays
changed getXXX() methods to return shallow array clones
formatting and prettying
Revision ChangesPath
1.3 +39 -19jmx/src/main/javax/management/MBeanConstructorInfo.java
Index: MBeanConstructorInfo.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/MBeanConstructorInfo.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MBeanConstructorInfo.java 2001/12/05 14:12:46 1.2
+++ MBeanConstructorInfo.java 2001/12/11 21:19:47 1.3
@@ -1,44 +1,64 @@
/*
- * LGPL
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
*/
package javax.management;
+/**
+ * Describes a constructor exposed by an MBean
+ *
+ * This implementation protects its immutability by taking shallow clones of all
arrays
+ * supplied in constructors and by returning shallow array clones in getXXX()
methods.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
+ * @author a href=mailto:[EMAIL PROTECTED];Trevor Squires/a.
+ *
+ * @version $Revision: 1.3 $
+ */
public class MBeanConstructorInfo extends MBeanFeatureInfo
- implements java.io.Serializable, Cloneable {
+ implements java.io.Serializable, Cloneable
+{
+ // Attributes
protected MBeanParameterInfo[] signature = null;
-
+
+ // Constructors --
public MBeanConstructorInfo(java.lang.String description,
- java.lang.reflect.Constructor constructor) {
+ java.lang.reflect.Constructor constructor)
+ {
super(constructor.getName(), description);
Class[] sign = constructor.getParameterTypes();
signature = new MBeanParameterInfo[sign.length];
-
- for (int i = 0; i sign.length; ++i) {
+
+ for (int i = 0; i sign.length; ++i)
+ {
String name = sign[i].getName();
signature[i] = new MBeanParameterInfo(name, name, MBean Constructor
Parameter.);
}
-
}
-
+
public MBeanConstructorInfo(java.lang.String name,
java.lang.String description,
- MBeanParameterInfo[] signature) {
+ MBeanParameterInfo[] signature)
+ {
super(name, description);
- this.signature = signature;
+ this.signature = (null == signature) ? new MBeanParameterInfo[0] :
(MBeanParameterInfo[]) signature.clone();
}
- public java.lang.Object clone() throws CloneNotSupportedException {
- MBeanConstructorInfo clone = (MBeanConstructorInfo)super.clone();
- clone.signature = getSignature();
- return clone;
+ // Public
+ public MBeanParameterInfo[] getSignature()
+ {
+ return (MBeanParameterInfo[]) signature.clone();
}
- public MBeanParameterInfo[] getSignature() {
- return signature;
+ // Cloneable implementation --
+ public java.lang.Object clone() throws CloneNotSupportedException
+ {
+ MBeanConstructorInfo clone = (MBeanConstructorInfo) super.clone();
+ clone.signature = getSignature();
+ return clone;
}
-
-
-
}
1.4 +20 -47jmx/src/main/javax/management/MBeanInfo.java
Index: MBeanInfo.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/MBeanInfo.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MBeanInfo.java2001/12/10 17:20:04 1.3
+++ MBeanInfo.java2001/12/11 21:19:47 1.4
@@ -9,18 +9,21 @@
/**
* Describes an MBeans' management interface.
*
+ * This implementation protects its immutability by taking shallow clones of all
arrays
+ * supplied in constructors and by returning shallow array clones in getXXX()
methods.
+ *
* @see javax.management.MBeanServer
*
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
* @author a href=mailto:[EMAIL PROTECTED];Trevor Squires/a.
+ *
+ * @version $Revision: 1.4 $
*
- * @version $Revision: 1.3 $
- *
*/
public class MBeanInfo
implements Cloneable, java.io.Serializable
{
-
+
// Attributes
Re: [JBoss-dev] Can xdoclet not do unnecessary work?
snip I think it is mostly targeted at ejb development, where one person is filling all those roles at once. If you have a separate deployer-person, at least it gives you somewhere to start. I do not agree :O The [b]merging[/b] feature of xdoclet permits to do almost everything in multi deployment mode. It has really turned xdoclet from a developement tool to also a deployment tool. Personnally I deploy on different environments and never change a XML file by hand. Here's my chance to get some good info on xdoclet from an expert ;-) 1. Looking at the docs for xdoclet it looks to me as if the merge stuff lets you easily construct a complete dd. I was talking about deploying the same java class(es) under several jndi names, with say mappings to several database tables. Is this possible? 2. Is there some way to use xdoclet with a package of ejb's you buy where you don't get the source code? I thought it started with source code and generated the complete deployable package that will work on many app servers without further modification. That's why I was talking about role separation. If you are forced to start with binary classes and an existing ejb-jar.xml does it help you? __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bugs, mostly: Server stops delivering messsages.
Hi David, From: David Maplesden [EMAIL PROTECTED] To: JBossDev (E-mail) [EMAIL PROTECTED] Subject: [JBoss-dev] Bugs, mostly: Server stops delivering messsages. Date: Wed, 12 Dec 2001 08:50:43 +1300 OK so I have never been able to work out exactly how people get assigned to bugs that have been reported. There is a note on the sourceforge bug tracker page about assigning yourself to bugs you are going to fix to avoid duplicated effort. This is clearly a good idea, I just don't know how to do it. Also how do you change the status of a bug report (to close it etc). Maybe I don't have the required permissions do these things? I'm not sure if any special permissions are required. Anyway, Hiram, the point of my above question is that I am pretty sure I know what the problem is for the recently reported bug #491613 that has been assigned to you, do you want me to fix it? Or just let you know what I think the problem is. If you know whats broke, fix it ;-) David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ 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] CVS update: jbossmq/src/main/org/jboss/mq SpyConnectionConsumer.java
User: dmaplesden
Date: 01/12/11 14:21:49
Modified:src/main/org/jboss/mq Tag: Branch_2_4
SpyConnectionConsumer.java
Log:
Fixed bug #491613, server stops delivering messages
Revision ChangesPath
No revision
No revision
1.5.2.2 +5 -5 jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java
Index: SpyConnectionConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- SpyConnectionConsumer.java2001/08/23 03:57:08 1.5.2.1
+++ SpyConnectionConsumer.java2001/12/11 22:21:49 1.5.2.2
@@ -19,7 +19,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.5.2.1 $
+ * @version$Revision: 1.5.2.2 $
*/
public class SpyConnectionConsumer implements javax.jms.ConnectionConsumer,
SpyConsumer, Runnable {
@@ -148,9 +148,9 @@
while ( true ) {
//get Message
while ( mes == null ) {
- mes = connection.receive( subscription, 0 );
- if ( mes == null ) {
- synchronized ( queue ) {
+ synchronized ( queue ) {
+ mes = connection.receive( subscription, 0 );
+ if ( mes == null ) {
waitingForMessage = true;
while ( queue.isEmpty() !closed ) {
try {
@@ -171,7 +171,7 @@
SpySession spySession = ( SpySession )serverSession.getSession();
if ( spySession.sessionConsumer == null ) {
- cat.debug( + this + Session did not have a set MessageListner
);
+ cat.debug( + this + Session did not have a set MessageListener
);
} else {
spySession.sessionConsumer.subscription = subscription;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Can xdoclet not do unnecessary work?
Xdoclet checks the timestamp of the file, if newer that the generated, then regenerate. Looking harder at my output, it looks like it is only regenerating the dd files (no source files have been touched). Is this normal? Is there some way to make it quit doing this? __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bugs, mostly: Server stops delivering messsages.
Anyway, Hiram, the point of my above question is that I am pretty sure I know what the problem is for the recently reported bug #491613 that has been assigned to you, do you want me to fix it? Or just let you know what I think the problem is. If you know whats broke, fix it ;-) OK, done :-) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491613 ] Server stops delivering messages to MDBs
Bugs item #491613, was opened at 2001-12-11 08:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Hiram Chirino (chirino) Summary: Server stops delivering messages to MDBs Initial Comment: hi, we found a very hard to reproduce bug in JBossMQ; it *might* be a race condition. We tracked the problem down to the interaction between org.jboss.mq.server.BasicQueue and org.jboss.mq.SpyConnectionConsumer. Here's what happens: SpyConnectionConsumer.java reaches line 105 (commented unwanted msg) and delivers a NACK. BasicQueue.java receives the NACK and tries to restore the message using the restoreMessage() method. However, from that point of time *NO* receiver is being added to the receivers list in BasicQueue.java, resulting in the internal message queue growing without EVER delivering any messages anymore. This *only* happens when Line 105 in SpyConnectionConsumer.java is invoked -- if my MDB calls setRollbackOnly(), everything continues working. As I said, this is *very* hard to reproduce and my guess is on a race condition. We tried to fix this on our own but got lost in the MQ magic. P.S.: Running JBoss 2.4.4 CVS as of today but this bug has been in before as it seems, we're getting the same behaviour on a vanilla 2.4.3 configuration. I'll try to come up with a testcase if you need it. -- Comment By: David Maplesden (dmaplesden) Date: 2001-12-11 12:08 Message: Logged In: YES user_id=298030 Hi, you are correct, I have looked at the code and this is being caused by a race condition very similar to one we fixed recently in SpyMessageConsumer. It will be fixed shortly. What is essentially happening is in the run() method the call to connection.receive() is occuring but returning null because no message is waiting for the bean. Then, before the waitingForMessage flag is set to true a couple of lines later, a message arrives at the server for the bean and is delivered to the connection consumer using addMessage(). This then rejects the message because the flag is not set. The consumer is then frozen because the run() now sets the flag to true and waits for a message to arrive (which never does). There is an easy fix which simply involves moving the connection.receive() call inside the synchronized block. -- Comment By: Christian Riege (lqd) Date: 2001-12-11 08:19 Message: Logged In: YES user_id=176671 ooops, forgot one maybe important detail: if i have multiple MDB's deployed, the effect will only show up on a per-bean basis. i.e. i have one bean which is b0rked while other MDB's are running along just fine. obviously the effect shows up on the bean with the heaviest traffic first but the other beans get affected after a certain amount of time, too. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can xdoclet not do unnecessary work?
Here's my chance to get some good info on xdoclet
from an expert ;-)
1. Looking at the docs for xdoclet it looks to me as
if the merge stuff lets you easily construct a
complete dd. I was talking about deploying the same
java class(es) under several jndi names, with say
mappings to several database tables. Is this
possible?
Yes it is.
And if it is not, it is a bug in xdoclet.
JNDI, h, I go that way already ;-). The issue here is to all lookups hardcoded in
your program to name (usually the COMP_NAME generated by xdoclet in home interfaces),
so you need an indirection here, use jboss.xml could solve the problem here.
I choose to use a Map (read through xml through a MBean) to forward a name A to a name
B. For example OrderCMPHome to OrderBMPHome, then all my existing code continue to
work and go to see another JNDI under different deployment.
Back to xdoclet, here I see no merge point in jboss_xml.j so it's a xdoclet bug :(
Database name:
You have a merge in jboss-jaws.j : jaws-db-settings-{0}.xml
This means if you have jaws-db-settings-OrderBean.xml, when you run xdoclet on
OrderBean, all the information will be extracted from the file (under a directory path
similar to the classpath) and replace all what you can find under XDtMerge:merge
file=jaws-db-settings-{0}.xml in jboss-jaws.j.
Got it ?
Thanks to Ara (Southern Rickard ;) )
2. Is there some way to use xdoclet with a package of
ejb's you buy where you don't get the source code? I
thought it started with source code and generated the
complete deployable package that will work on many
app servers without further modification. That's why
I was talking about role separation. If you are
forced to start with binary classes and an existing
ejb-jar.xml does it help you?
xdoclet works on javadoc/doclet tags so it parses the source file for @ comments on
class and method. i am not sure to understand your question :(
__
View this jboss-dev thread in the online forums:
http://jboss.org/forums/thread.jsp?forum=66thread=5471
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RH, CMR: very bad performance
Hi, I have 3 beans: Item, ItemGroup, UnitOfMeasure. Item has a foreign key reference to ItemGroup and a reference to UnitOfMeasure, but not the other way around. So this are two many to one relationships, unidirektional. I traced the executed SQL's and found out the following: Executing and ItemHome.create(...) with all fields of item in the argument list, this SQL's are executed: select count(*) from item where id = ? insert into item ( id, description1, ... ) values ( ?, ?, ...) (all fields without itemgroup_id and unifofmeasure_id). After this select description from item_group where id = ? is executed. OK so far, but now ... select id from item where itemgroup_id = ? is executed and all the results are fetched (JDBCFindByForeignKeyCommand). The more items are created the longer it takes to add a new one. I get an horrible high count of database read calls for only a few data written. Frank ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] SAR the Super ARchive
Soon yes -peter --fagerlund ---style .. wap apa here we go Ok seriously, it is just a teaser at the moment but I am about as deep as I want to go in the deployer stuff and my gut feeling is that I am staring at the unified deployer and the unified CL, it is one and the same problem. It is one of those gut feelings moments, that make the research so much fun, but I really want to swim back to the surface. It feels like I can actually breethe down here, like when you are in your dreams you realize it is possible to breathe under water. So the SAR, the real one, is on its way, next. Interestingly enough the SUPER-ARCHIVE format is un-jarred, we will be able to monitor fine things like that, such as being able to see if one file has changed in jsp for example and bla bla all unified with the EJB and SAR But I want to commit what I was working on so I won't open that door for now, but it is pretty seen from some distance... I will go tackle that monster when I am done with clustering rewrite of invokers. remember I love you marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5495 ___ 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/jaws/bmp CustomFindByEntitiesCommand.java
User: patriot1burke
Date: 01/12/11 15:39:37
Modified:src/main/org/jboss/ejb/plugins/jaws/bmp Tag: Branch_2_4
CustomFindByEntitiesCommand.java
Log:
FinderExceptions were not being thrown up stack when customer finder throws
for example, ObjectNotFouncException
Revision ChangesPath
No revision
No revision
1.3.4.2 +16 -8
jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java
Index: CustomFindByEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java,v
retrieving revision 1.3.4.1
retrieving revision 1.3.4.2
diff -u -r1.3.4.1 -r1.3.4.2
--- CustomFindByEntitiesCommand.java 2001/11/20 09:42:51 1.3.4.1
+++ CustomFindByEntitiesCommand.java 2001/12/11 23:39:37 1.3.4.2
@@ -30,7 +30,7 @@
*
* @see org.jboss.ejb.plugins.jaws.jdbc.JDBCFindEntitiesCommand
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.3.4.1 $
+ * @version $Revision: 1.3.4.2 $
*/
public class CustomFindByEntitiesCommand implements JPMFindEntitiesCommand
{
@@ -82,19 +82,27 @@
coll.add(finderImplMethod.invoke(ctx.getInstance(),args));
result = new FinderResults(coll, null, null, null);
}
- } catch (IllegalAccessException e1)
+ }
+ catch (IllegalAccessException e1)
{
throw new FinderException(Unable to access finder
implementation:+finderImplMethod.getName());
- } catch (IllegalArgumentException e2)
+ }
+ catch (IllegalArgumentException e2)
{
throw new FinderException(Illegal arguments for finder
implementation:+finderImplMethod.getName());
- } catch (InvocationTargetException e3)
+ }
+ catch (ExceptionInInitializerError e5)
{
- throw new FinderException(Exception in finder
implementation:+finderImplMethod.getName());
- } catch (ExceptionInInitializerError e5)
- {
throw new FinderException(Unable to initialize finder
implementation:+finderImplMethod.getName());
- }
+ }
+ catch (InvocationTargetException e3)
+ {
+ Throwable target = e3.getTargetException();
+ if(target instanceof FinderException) {
+throw (FinderException)target;
+ }
+ throw new FinderException(Unable to initialize finder implementation: +
finderImplMethod.getName());
+ }
return result;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] customer == custom in ChangeNote I just submitted
sorry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491613 ] Server stops delivering messages to MDBs
Bugs item #491613, was opened at 2001-12-11 08:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: David Maplesden (dmaplesden) Summary: Server stops delivering messages to MDBs Initial Comment: hi, we found a very hard to reproduce bug in JBossMQ; it *might* be a race condition. We tracked the problem down to the interaction between org.jboss.mq.server.BasicQueue and org.jboss.mq.SpyConnectionConsumer. Here's what happens: SpyConnectionConsumer.java reaches line 105 (commented unwanted msg) and delivers a NACK. BasicQueue.java receives the NACK and tries to restore the message using the restoreMessage() method. However, from that point of time *NO* receiver is being added to the receivers list in BasicQueue.java, resulting in the internal message queue growing without EVER delivering any messages anymore. This *only* happens when Line 105 in SpyConnectionConsumer.java is invoked -- if my MDB calls setRollbackOnly(), everything continues working. As I said, this is *very* hard to reproduce and my guess is on a race condition. We tried to fix this on our own but got lost in the MQ magic. P.S.: Running JBoss 2.4.4 CVS as of today but this bug has been in before as it seems, we're getting the same behaviour on a vanilla 2.4.3 configuration. I'll try to come up with a testcase if you need it. -- Comment By: David Maplesden (dmaplesden) Date: 2001-12-11 12:08 Message: Logged In: YES user_id=298030 Hi, you are correct, I have looked at the code and this is being caused by a race condition very similar to one we fixed recently in SpyMessageConsumer. It will be fixed shortly. What is essentially happening is in the run() method the call to connection.receive() is occuring but returning null because no message is waiting for the bean. Then, before the waitingForMessage flag is set to true a couple of lines later, a message arrives at the server for the bean and is delivered to the connection consumer using addMessage(). This then rejects the message because the flag is not set. The consumer is then frozen because the run() now sets the flag to true and waits for a message to arrive (which never does). There is an easy fix which simply involves moving the connection.receive() call inside the synchronized block. -- Comment By: Christian Riege (lqd) Date: 2001-12-11 08:19 Message: Logged In: YES user_id=176671 ooops, forgot one maybe important detail: if i have multiple MDB's deployed, the effect will only show up on a per-bean basis. i.e. i have one bean which is b0rked while other MDB's are running along just fine. obviously the effect shows up on the bean with the heaviest traffic first but the other beans get affected after a certain amount of time, too. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491613group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jetty-discuss] Jetty4 temp directory
For the moment then, you should just be able to attach a logger ni the jetty.xml. In the future this will be supported, as Greg suggests, directly via MBeans configured in the sar's jboss-service.xml Jules Greg Wilkins wrote: Jetty now has a pluggable access log mechanism so multiple formats can be supported. The standard and extended formats are supported. Note there is still some work to do to clean this up as the formatters separation from the log sink is not good. I assume in JBoss, this is setup via the jetty.xml file and will go where ever it is defined there (probably JETTY_HOME/logs). But we need to start moving all the core configuration out of the Jetty.xml file into the normal JMX configuration mechanism of JBoss. cheers Hunter Hillegas wrote: I think this will be a big issue. If the idea is that you don't need Apache anymore with Jetty, Jetty has to support log files that people can generate reports from... That means piping it to the Jboss log isn't enough since no tool I know of for Web reporting will parse out the log4J categories, etc... Hunter From: Julian Gosnell [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 11 Dec 2001 20:54:59 + To: [EMAIL PROTECTED] Subject: Re: [jetty-discuss] Jetty4 temp directory Good question I have simply written a bridge between Jetty and JBoss/Log4J logging systems, so if Jetty logged it, it will be in the JBoss log. If you want an access log, have a look at what standalone Jetty does in this respect and then we will discuss how this best might be done in JBoss/Jetty.. Perhaps we want a separate 'access' logging category - but I'm not sure, without looking, how Jetty splits the various logging outputs Greg ? Jules Hunter Hillegas wrote: Jules- One thing I've been wondering... Where does JBoss3+Jetty4 put it's access logs? Hunter From: Julian Gosnell [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 11 Dec 2001 20:40:14 + To: [EMAIL PROTECTED] Subject: Re: [jetty-discuss] Jetty4 temp directory I'll probably hang back from this one for a while, Hunter. I like to keep my life simple. Jules P.S. If you REALLY want to live on the bleeding edge, check out a Jetty tree from SF, build it and stick it into your jetty-plugin.sar - probably not worth the effort though. If there is an important fix, I will stick it into JBoss cvs immediately... Hunter Hillegas wrote: I'll try it as soon as Jules gets it into Jboss CVS... BTW, MacOS is not bizarre! OS X rules! End or rant. From: Greg Wilkins [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 11 Dec 2001 19:02:33 +1100 To: [EMAIL PROTECTED] Subject: [jetty-discuss] Jetty4 temp directory So can those of you with bizarre operating systems (and I'm thinking VMS, MVS, MacOS, Win32 here) For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ Yahoo! Groups Sponsor -~-- Quit now for Great American Smokeout http://us.click.yahoo.com/0vN8tD/9pSDAA/ySSFAA/CefplB/TM -~- For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty integration is broken in 2.4.4
Just got latest from CVS. How do I check out this Jetty integration from 2.4.4 so that I can fix it? I can't seem to figure out what module to use. Thanks, Bill [ConfigurationService] Could not create MBean DefaultDomain:service=Jetty(org.jboss.jetty.JettyService) java.lang.NoClassDefFoundError: org/jboss/logging/log4j/JBossCategory at java.lang.Class.getConstructors0(Native Method) at java.lang.Class.getConstructors(Class.java:775) at com.sun.management.jmx.Introspector.testCompliance(Introspector.java:95) at com.sun.management.jmx.MetaData.testCompliance(MetaData.java:132) at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:759) at org.jboss.configuration.ConfigurationService.create(ConfigurationService.jav a:683) at org.jboss.configuration.ConfigurationService.loadConfiguration(Configuration Service.java:461) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.Main.init(Main.java:200) at org.jboss.Main$1.run(Main.java:110) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.Main.main(Main.java:106) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jetty-service.jar
User: starksm Date: 01/12/11 16:32:08 Removed: src/lib Tag: Branch_2_4 jetty-service.jar Log: Remove the obsolete jetty-service.jar. This is only exists in the bundled downloads or by building from the contrib/jetty cvs module. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty integration is broken in 2.4.4
The jetty-service.jar in CVS is out of date. Download the current 2.4.4 bundle from sourceforge. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 4:16 PM Subject: [JBoss-dev] Jetty integration is broken in 2.4.4 Just got latest from CVS. How do I check out this Jetty integration from 2.4.4 so that I can fix it? I can't seem to figure out what module to use. Thanks, Bill [ConfigurationService] Could not create MBean DefaultDomain:service=Jetty(org.jboss.jetty.JettyService) java.lang.NoClassDefFoundError: org/jboss/logging/log4j/JBossCategory at java.lang.Class.getConstructors0(Native Method) at java.lang.Class.getConstructors(Class.java:775) at com.sun.management.jmx.Introspector.testCompliance(Introspector.java:95) at com.sun.management.jmx.MetaData.testCompliance(MetaData.java:132) at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:759) at org.jboss.configuration.ConfigurationService.create(ConfigurationService.jav a:683) at org.jboss.configuration.ConfigurationService.loadConfiguration(Configuration Service.java:461) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.Main.init(Main.java:200) at org.jboss.Main$1.run(Main.java:110) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.Main.main(Main.java:106) ___ 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] Jetty integration is broken in 2.4.4
thanks dude. Did the trick. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Tuesday, December 11, 2001 7:37 PM To: [EMAIL PROTECTED]; Jboss-Development@Lists. Sourceforge. Net Subject: Re: [JBoss-dev] Jetty integration is broken in 2.4.4 The jetty-service.jar in CVS is out of date. Download the current 2.4.4 bundle from sourceforge. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 4:16 PM Subject: [JBoss-dev] Jetty integration is broken in 2.4.4 Just got latest from CVS. How do I check out this Jetty integration from 2.4.4 so that I can fix it? I can't seem to figure out what module to use. Thanks, Bill [ConfigurationService] Could not create MBean DefaultDomain:service=Jetty(org.jboss.jetty.JettyService) java.lang.NoClassDefFoundError: org/jboss/logging/log4j/JBossCategory at java.lang.Class.getConstructors0(Native Method) at java.lang.Class.getConstructors(Class.java:775) at com.sun.management.jmx.Introspector.testCompliance(Introspector.java:95) at com.sun.management.jmx.MetaData.testCompliance(MetaData.java:132) at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl .java:759) at org.jboss.configuration.ConfigurationService.create(ConfigurationS ervice.jav a:683) at org.jboss.configuration.ConfigurationService.loadConfiguration(Con figuration Service.java:461) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.Main.init(Main.java:200) at org.jboss.Main$1.run(Main.java:110) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.Main.main(Main.java:106) ___ 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] Support for upackaged EARs, JARs, WARs added to 2.4
2.4.3 2.4.4 2.4.4beta Adam, I know you didn't write the debian package rules, but this is the most retarded fucking thing I have ever seen. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/security - New directory
User: starksm Date: 01/12/11 18:26:38 contrib/catalina/src/main/org/jboss/web/security - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/security JBossSecurityMgrRealm.java SSLServerSocketFactory.java
User: starksm
Date: 01/12/11 18:27:15
Added: catalina/src/main/org/jboss/web/security
JBossSecurityMgrRealm.java
SSLServerSocketFactory.java
Log:
Start moving the 2.4 branch code to main
Revision ChangesPath
1.1
contrib/catalina/src/main/org/jboss/web/security/JBossSecurityMgrRealm.java
Index: JBossSecurityMgrRealm.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.web.catalina.security;
import java.io.IOException;
import java.security.Principal;
import java.security.cert.X509Certificate;
import java.util.Arrays;
import java.util.Hashtable;
import java.util.HashSet;
import java.util.Set;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.security.auth.Subject;
import javax.servlet.ServletException;
import org.apache.log4j.Category;
import org.apache.catalina.Realm;
import org.apache.catalina.Request;
import org.apache.catalina.Response;
import org.apache.catalina.Valve;
import org.apache.catalina.ValveContext;
import org.apache.catalina.realm.RealmBase;
import org.jboss.logging.log4j.TracePriority;
import org.jboss.security.AuthenticationManager;
import org.jboss.security.RealmMapping;
import org.jboss.security.SimplePrincipal;
import org.jboss.security.SecurityAssociation;
import org.jboss.security.SubjectSecurityManager;
/** An implementation of the catelinz Realm and Valve interfaces. The Realm
implementation handles authentication and authorization using the JBossSX
security framework. It relieas on the JNDI ENC namespace setup by the
AbstractWebContainer. In particular, it uses the java:comp/env/security
subcontext to access the security manager interfaces for authorization and
authenticaton.
The Valve interface is used to associated the authenticated user with the
SecurityAssociation class when a request begins so that web components may
call EJBs and have the principal propagated. The security association is
removed when the request completes.
@see org.jboss.web.AbstractWebContainer
@see org.jboss.security.AuthenticationManager
@see org.jboss.security.RealmMapping
@see org.jboss.security.SimplePrincipal
@see org.jboss.security.SecurityAssociation
@see org.jboss.security.SubjectSecurityManager
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class JBossSecurityMgrRealm extends RealmBase implements Realm, Valve
{
static Category category =
Category.getInstance(JBossSecurityMgrRealm.class.getName());
private String subjectAttributeName = j_subject;
private boolean useJAAS = false;
/** A flag to indicate if the security manager implements the
SubjectSecurityManager
rather than AuthenticationManager. When true, the authenticated Subject is
obtained
from the SubjectSecurityManager and placed into the request under the
subjectAttributeName attribute.
*/
public void setUseJAAS(boolean useJAAS)
{
this.useJAAS = useJAAS;
}
/** The name of the request attribute under with the authenticated JAAS
Subject is stored on successful authentication.
*/
public void setSubjectAttributeName(String subjectAttributeName)
{
this.subjectAttributeName = subjectAttributeName;
}
private Context getSecurityContext()
{
Context securityCtx = null;
// Get the JBoss security manager from the ENC context
try
{
InitialContext iniCtx = new InitialContext();
securityCtx = (Context) iniCtx.lookup(java:comp/env/security);
}
catch(NamingException e)
{
// Apparently there is no security context?
}
return securityCtx;
}
/**
* Return the Principal associated with the specified chain of X509
* client certificates. If there is none, return codenull/code.
*
* @param certs Array of client certificates, with the first one in
* the array being the certificate of the client itself.
*/
public Principal authenticate(X509Certificate[] certs)
{
SimplePrincipal principal = null;
Context securityCtx = getSecurityContext();
if( securityCtx == null )
{
return null;
}
try
{
// Get the JBoss security manager from the ENC context
AuthenticationManager securityMgr = (AuthenticationManager)
securityCtx.lookup(securityMgr);
}
catch(NamingException e)
{
category.error(Error during authenticate,
[JBoss-dev] CVS update: CVSROOT modules
User: starksm Date: 01/12/11 18:28:29 Modified:.modules Log: Add catalin and tomcat contrib modules to varia Revision ChangesPath 1.77 +4 -0 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.76 retrieving revision 1.77 diff -u -r1.76 -r1.77 --- modules 2001/12/07 00:27:35 1.76 +++ modules 2001/12/12 02:28:29 1.77 @@ -61,6 +61,8 @@ _plugins_varia -d variacontrib/varia _plugins_jetty -d jettycontrib/jetty +_plugins_catalina-d catalina contrib/catalina +_plugins_tomcat -d tomcat contrib/tomcat _plugins_jboss.net -d jboss.netcontrib/jboss.net ## @@ -92,6 +94,8 @@ build/_emptydir \ _plugins_varia \ _plugins_jetty \ + _plugins_catalina \ + _plugins_tomcat \ _plugins_jboss.net ## ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491806 ] Catalina *always* binds to port 8080
Bugs item #491806, was opened at 2001-12-11 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491806group_id=22866 Category: CatalinaBundle Group: v2.4 BETA (stable) Status: Open Resolution: None Priority: 5 Submitted By: Brill Pappin (brill) Assigned to: Scott M Stark (starksm) Summary: Catalina *always* binds to port 8080 Initial Comment: See the attached trace.txt for machine info. To reproduce: Start any service on port 8080, then try and run jboss with catalin (v4.x). No matter what I do, Catalina always binds to port 8080. I have search *every* file in the installation for references to port 8080, and changed them to 80, and still the catalin service starts on port 8080. e.g. [INFO,Default] Apache Tomcat/4.0.1 [INFO,EmbeddedCatalinaServiceSX] HttpConnector Opening server socket on all host IP addresses [INFO,EmbeddedCatalinaServiceSX] HttpConnector[8080] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080] [0] Starting background thread [INFO,EmbeddedCatalinaServiceSX] OK [INFO,EmbeddedCatalinaServiceSX] Started I've taken a look at the code, and it looks as if someone made a mistake, and hard coded the port into the class. Of course, if I have another binding on 8080, i get a stack trace when the catalina service attempts to start. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491806group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Support for upackaged EARs, JARs, WARs added to 2.4
On Tue, 11 Dec 2001, Dain Sundstrom wrote: 2.4.3 2.4.4 2.4.4beta Adam, I know you didn't write the debian package rules, but this is the most retarded fucking thing I have ever seen. Well, it does cause problems, I'll agree there. I'll explain how dpkg does version comparison below. For those who don't care, you can skip it, as it's just a FYI. -- For each version string, split into atoms, where each atom contains only digits, or non-digits. Numeric atoms are then compared numerically(54 123 numerically, but as a string is ). When comparing 2 unlike atoms between 2 versions, compare them as strings(54 ab) If one version has more atoms than another, then that version compares higher(this is based on the assumption that more text for a version more accurately describes the version) -- So, let's run this algo on '2.4.4' and '2.4.4beta'. 2.4.4 (2), (.), (4), (.), (4) 2.4.4beta (2), (.), (4), (.), (4), (beta) Obvsiously, it's the last rule above that causes 2.4.4beta to compare higher than 2.4.4. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Can xdoclet not do unnecessary work?
On Tue, 11 Dec 2001, Vincent Harcq wrote: Is there a reasonably simple way to make xdoclet only run if one of the files it is processing has changed? Most of the time for my server module builds seems to be taken with xdoclet, and I never change stuff it starts with. Xdoclet checks the timestamp of the file, if newer that the generated, then regenerate. Shouldn't it check if the timestamp has *changed*? What happens when a file is restored from backup? Any generated files that are built from this modified file should be rebuilt. Of course, from my readings here, it appears that xdoclet is not a jboss project, so obviously can't fix bugs therein. Ignore this mail as you will. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491806 ] Catalina *always* binds to port 8080
Bugs item #491806, was opened at 2001-12-11 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491806group_id=22866 Category: CatalinaBundle Group: v2.4 BETA (stable) Status: Closed Resolution: Invalid Priority: 5 Submitted By: Brill Pappin (brill) Assigned to: Scott M Stark (starksm) Summary: Catalina *always* binds to port 8080 Initial Comment: See the attached trace.txt for machine info. To reproduce: Start any service on port 8080, then try and run jboss with catalin (v4.x). No matter what I do, Catalina always binds to port 8080. I have search *every* file in the installation for references to port 8080, and changed them to 80, and still the catalin service starts on port 8080. e.g. [INFO,Default] Apache Tomcat/4.0.1 [INFO,EmbeddedCatalinaServiceSX] HttpConnector Opening server socket on all host IP addresses [INFO,EmbeddedCatalinaServiceSX] HttpConnector[8080] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080] [0] Starting background thread [INFO,EmbeddedCatalinaServiceSX] OK [INFO,EmbeddedCatalinaServiceSX] Started I've taken a look at the code, and it looks as if someone made a mistake, and hard coded the port into the class. Of course, if I have another binding on 8080, i get a stack trace when the catalina service attempts to start. -- Comment By: Scott M Stark (starksm) Date: 2001-12-11 15:26 Message: Logged In: YES user_id=175228 Read the 2.4.2 change note on catalina and the Port MBean attribute. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491806group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-491817 ] customer finder bug fixed
Change Notes item #491817, was opened at 2001-12-11 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=491817group_id=22866 Category: None Group: v2.4.4 Status: Open Priority: 5 Submitted By: Bill Burke (patriot1burke) Assigned to: Nobody/Anonymous (nobody) Summary: customer finder bug fixed Initial Comment: When a customer finder would throw ObjectNotFoundException it was not being thrown up the stack, but rather caught and a new generic Finder exception was thrown. This was already fixed in 3.0 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=491817group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Support for upackaged EARs, JARs, WARs added to 2.4
I'll update the source tonight. - Original Message - From: Adam Heath [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: JBoss Dev [EMAIL PROTECTED] Sent: Tuesday, December 11, 2001 6:27 PM Subject: Re: [JBoss-dev] Support for upackaged EARs, JARs, WARs added to 2.4 On Tue, 11 Dec 2001, Scott M Stark wrote: It has been sitting on sourceforge since last night. See the Files page. Ah, my bad. It wasn't on http://jboss.org/binary.jsp. Fetching. Actually, the links on (1) show no new files since November 28. So, looking at (2), I see files that have had their timestamps modified, but not updated in (1). Also, I see no uptodate JBoss-2.4.4-src.tgz. I only see an updated binary zip. I'd like an updated src tarball, if it's not too much trouble. 1: http://sourceforge.net/project/showfiles.php?group_id=22866release_id=63281 2: http://prdownloads.sourceforge.net/jboss/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server MessageCache.java
User: dmaplesden
Date: 01/12/11 19:24:58
Modified:src/main/org/jboss/mq/server MessageCache.java
Log:
Undo my object pooling code, it causes a number of bugs when server is under high
load.
Revision ChangesPath
1.9 +4 -28 jbossmq/src/main/org/jboss/mq/server/MessageCache.java
Index: MessageCache.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/MessageCache.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- MessageCache.java 2001/12/09 05:50:31 1.8
+++ MessageCache.java 2001/12/12 03:24:58 1.9
@@ -24,14 +24,10 @@
* later.
*
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
- * @version$Revision: 1.8 $
+ * @version$Revision: 1.9 $
*/
public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
- //pool of message ref objects
- public static final int MAX_POOL_SIZE = 100*1000;
- protected ArrayList pool = new ArrayList(MAX_POOL_SIZE);
-
// The cached messages are orded in a LRU linked list
private LinkedList lruCache = new LinkedList();
@@ -61,25 +57,6 @@
return this;
}
- //this method is only called from within synchronized block, so don't need to
sync
- protected MessageReference getMessageReference(MessageCache messageCache, Long
referenceId, SpyMessage message) {
- MessageReference ref = null;
- if(!pool.isEmpty())
- ref = (MessageReference)pool.remove(pool.size()-1);
- else
- ref = new MessageReference();
- ref.init(messageCache,referenceId,message);
- return ref;
- }
-
- //this method is only called from within synchronized block, so don't need to
sync
- protected void releaseMessageReference(MessageReference ref){
- if(pool.size() MAX_POOL_SIZE){
- ref.reset();
- pool.add(ref);
- }
- }
-
/**
* Adds a message to the cache
*/
@@ -88,7 +65,8 @@
log.trace(add lock aquire);
synchronized (this)
{
- MessageReference mh = getMessageReference(this, new
Long(messageCounter++), message);
+ MessageReference mh = new MessageReference();
+ mh.init(this, new Long(messageCounter++), message);
lruCache.addLast(mh);
totalCacheSize++;
validateSoftReferenceDepth();
@@ -108,7 +86,6 @@
{
mr.clear();
lruCache.remove(mr);
- releaseMessageReference(mr);
totalCacheSize--;
log.trace(remove lock release);
}
@@ -443,5 +420,4 @@
public void setCacheStore(ObjectName cacheStore) {
cacheStoreObjectName = cacheStore;
}
-
-}
+ }
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Support for upackaged EARs, JARs, WARs added to 2.4
On Tue, 11 Dec 2001, Scott M Stark wrote: I'll update the source tonight. Kisses. The feature in $topic will allow us here at work to completely change our build system, to generate this unpacked form, then use rsync to send to the live servers. We are all waiting anxiously. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Ordering What is Returned from a CMR Method
Nope, if you are getting ordered results, it is your db. I would guess it is a byproduct of the pk index. Anyway, I have no plans to add ordering to cmr fields anytime soon, but you will always be able to use a selector. -dain -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 9:44 PM To: JBoss Dev Subject: [JBoss-dev] Ordering What is Returned from a CMR Method Let's say I have an entity called Product that has a CMR One to Many relationship with another entity called ProductLineItem. If I call Product.getLineItems(), it returns a Collection of ProductLineItems. In the current RH code, is there any way to order the way the results are returned? I think now they are ordered by their primary key but it would be really useful to be able to order them by another field... Hunter ___ 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] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 127 Successful tests: 125 Errors:2 Failures: 0 [time of test: 12 December 2001 4:53 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 127 Successful tests: 127 Errors:0 Failures: 0 [time of test: 12 December 2001 7:29 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! 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 org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - kill -9 See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Can xdoclet not do unnecessary work?
Looking harder at my output, it looks like it is only regenerating the dd files (no source files have been touched). Is this normal? Is there some way to make it quit doing this? Well, we haven't yet imeplemented dd timestamp checking. I'll implement it this weekend. XDoclet operates in two modes: per-class (like generating remote interface), and for-all (like ejb-jar.xml). Timestamp/modification checks are not done for the second case. Later we'll also add a XDtChunk namespace too, so xdoclet will only generate *parts of a dd file* and not regenerate all, but just substitute relevent parts. As Vincent pointed out we're also working on a customized/rewritten javadoc doclet API. This will make it much faster and bug-free and more importantly it'll let us implement a GUI tool for xdoclet (along with IDE integration in a later phase). Regarding third party beans in binary form: No need to worry, you just merge in the dd of that legacy bean into the ejb-jar.xml. For example if you have a set of session beans which you don't have the source or you're not willing to annotate it with xdoclet @tags, just create a file sessionbeans.xml and put it in where mergeDir param points to, xdoclet will pick it and merge it in but generate the rest of the dd file by looking at @tags. Regarding jndi-name and multiple deployments: well I guess there are some shortcommings atm (not everything allows a merge file), but merge files are the way to go. XDoclet is based around the vision that it'll ease development but will also deploy easily. You can also parameterize some settings (say table-name for a cmp bean) as normal Ant properties. XDoclet knwos about Ant properties too, so you can put this setting outseide of your code and rebuild with different values for different deployment targets. Merge files also are targeted for this purpose too. So you really have control over all aspects of development/deployment. Regarding making xdoclet part of jboss: No problem IMHO. But I really want to keep it vendor-independent but it's absolutely ok to use it in jboss as a core component. Hey I'm using WebSphere myself :-) But I think I should look at jboss more seriously ;-) Cheers, Ara. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5471 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-491806 ] Catalina *always* binds to port 8080
Bugs item #491806, was opened at 2001-12-11 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491806group_id=22866 Category: CatalinaBundle Group: v2.4 BETA (stable) Status: Closed Resolution: Invalid Priority: 5 Submitted By: Brill Pappin (brill) Assigned to: Scott M Stark (starksm) Summary: Catalina *always* binds to port 8080 Initial Comment: See the attached trace.txt for machine info. To reproduce: Start any service on port 8080, then try and run jboss with catalin (v4.x). No matter what I do, Catalina always binds to port 8080. I have search *every* file in the installation for references to port 8080, and changed them to 80, and still the catalin service starts on port 8080. e.g. [INFO,Default] Apache Tomcat/4.0.1 [INFO,EmbeddedCatalinaServiceSX] HttpConnector Opening server socket on all host IP addresses [INFO,EmbeddedCatalinaServiceSX] HttpConnector[8080] Starting background thread [INFO,EmbeddedCatalinaServiceSX] HttpProcessor[8080] [0] Starting background thread [INFO,EmbeddedCatalinaServiceSX] OK [INFO,EmbeddedCatalinaServiceSX] Started I've taken a look at the code, and it looks as if someone made a mistake, and hard coded the port into the class. Of course, if I have another binding on 8080, i get a stack trace when the catalina service attempts to start. -- Comment By: Brill Pappin (brill) Date: 2001-12-11 23:40 Message: Logged In: YES user_id=7933 Thanks, solved the problem... to make a suggestion, add the attribute to the config file now... even if its redundant, it would have saved me hours of hair-pulling, and I wouldn't have had to bug you about it. -- Comment By: Scott M Stark (starksm) Date: 2001-12-11 15:26 Message: Logged In: YES user_id=175228 Read the 2.4.2 change note on catalina and the Port MBean attribute. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=491806group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Ordering What is Returned from a CMR Method
Let's say I have an entity called Product that has a CMR One to Many relationship with another entity called ProductLineItem. If I call Product.getLineItems(), it returns a Collection of ProductLineItems. In the current RH code, is there any way to order the way the results are returned? I think now they are ordered by their primary key but it would be really useful to be able to order them by another field... Hunter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
