[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 2-June-2002
Number of tests run: 606
Successful tests: 605
Errors:0
Failures: 1
[time of test: 2 June 2002 0:29 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.4]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
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.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-563448 ] deployment exceptions cause problems
How about deployment returning lists of successfully deployed mbeans, mbeans waiting for others, and mbeans that failed deployment? Due to the dependency management, many of these mbeans may not be in the package just deployed. To make the original deployer of each mbean get notified we will either have to have asynchronous callbacks or multithreaded deployment with blocking on missing mbeans. Can you write down a list of all the problems you have with the dependency system? thanks david jencks On 2002.06.02 01:38:43 -0400 Jason Dillon wrote: Yes, well... the dependency system is flawed in many ways. We should not have to eat exceptions to make it work. Consider command line deployments where if we eat the exception we have no clue if the deploy() op suceeded. Note this is not limited to command line deployments but really anything that needs to rely on an exception being throw and propagated (not eaten) to detect failure sitations. --jason Quoting [EMAIL PROTECTED]: Bugs item #563448, was opened at 2002-06-02 02:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=563448group_id= 22866 Category: JBossServer Group: v3.1 Status: Open Resolution: None Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: Nobody/Anonymous (nobody) Summary: deployment exceptions cause problems Initial Comment: Recently 3.1 and I think 3.0 were modified so that deployment exceptions propagated out of main deployer. This has some questionable consequences in the presence of mbean dependencies, which was the reason I hid the exceptions in the first place. If mbean B depends on mbean A, but B does not deploy successfully, then: If A is deployed first, it will deploy successfully, then B can be deployed unsuccessfully. However if B is deployed first, it will wait for A. During the deployment of A, B will be deployed, and the resulting exception will cause the deployment of A to fail also. For instance, if there is a undeployable depending on the ConnectionManager mbean for DefaultDS, and the undeployable happens to get deployed before the ConnectionManager, it will prevent DefaultDS from deploying, thus breaking large amounts of the system. I'm not sure what the best solution to this is. I don't think the current state of affairs is desirable, since a rogue mbean can break any correctly working mbean by arranging to be deployed first. I lean toward having an easily accessible list of mbeans that can't be deployed and possibly returning a status code from deployers. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=563448group_id= 22866 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where should the Jasper jar live ?
Maybe having to install and learn to manage emacs and custom edit the emacs config to modify the Jetty log system (for example) is a bit too much for the average Windows user. Not my case (I use emacs every now and then), but I see this as a major handicap for spreading use of the JBoss/Jetty bundle and subsequent world domination :). I see Scott point of view more practical. OTOH, I also agree that this approach should not be the general case, but necesary for this. I say this because I have to modify every now and then Jetty files and having them on a SAR by default is a PITA. James Higginbotham wrote: David, You can add any extension to the archive mode with the following code in your .emacs: (setq auto-mode-alist (cons '(\\.sar$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.war$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.ear$ . archive-mode) auto-mode-alist)) Share and Enjoy, James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:07 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I still like the sar concept. I notice that emacs can edit files in jars (such as ejb-jar.xml) and save them back into the jar. Anyone know enough elisp to figure out how to make it edit .sar, .ear, .war, etc the same way? (I presume it just means recognizing the file format/extension as zip-like) Then there won't be anything to complain about having to repack for small changes. For large changes you'll be doing an ant build anyway. david jencks On 2002.05.31 21:04:26 -0400 Jules Gosnell wrote: The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas --
RE: [JBoss-dev] Where should the Jasper jar live ?
|take all the | |resources out of their ears and deploy them in lib/, then | |just drop the | |dds into deploy/. | |Ok, so they can edit their descriptors - but it's not J2EE, is it ? This is the future yes, for all the deployment types. marcf ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] new JBoss website KDE's konqueror
Hey List, I just wanted to say the new JBoss website looks very nice. However, one thing would make it even better: if it rendered properly in konqueror 3.0.0-2, the KDE 3.0 web browser. The main content area is not bounded by the window; it extends several screen-widths to the right, forcing a lot of horizontal scrolling. Briefly looking at the html, it appears to be a table opening/closing issue (i.e., not properly completing a table and/or a few td tags) near the beginning of the content section (starting around '!SIMPLER, CHEAPER, BETTER!'). look towards the end of the output from the following page (midway down): http://validator.w3.org/check/?uri=http%3A//main.jboss.org/ The site renders fine in mozilla though, which is generally a bit more forgiving than konqueror. Thanks for all of the hard work you fellas put into this product. It is certainly appreciated. Justin ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-562004 ] 'Error setting column value' using dependent value classes with existing db records
hey List, Since there hasn't been any feedback on this bug yet, I would like to start taking a look at it myself, as it is important for the project I'm working on. I would appreciate any extra developer documentation (UML diagrams would be super) that might be out there that would help me get up to speed quickly on (for starters) the JBossCMP portion of the codebase. I looked on the developer page of the website, but noticed that the developer guide page ( http://main.jboss.org/developers/guide/ ) is empty. I already have a working cvs HEAD, so I'm really just looking for codebase docs. Thanks justin Bugs item #562004, was opened at 2002-05-29 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=562004group_id =22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Justin Casp (jcasp) Assigned to: Nobody/Anonymous (nobody) Summary: 'Error setting column value' using dependent value classes with existing db records Initial Comment: I posted this problem a few weeks ago on jboss.org forums, but it's down right now so I can't reference that post. I figured out how to create a simple test case that reliably reproduces the problem. The error message 'Error setting column value' occurs when I have an existing CMP bean that reads existing records from a datasource. The bean uses a dependent value class, although I'm not sure if this problem is specific to dependent value classes or just any cmp bean with fields mapped to columns. If I create the record externally (e.g., using psql, the postgres command line tool) and only set a few of the columns to non-null values, when I attempt to load that bean instance with a finder, jboss throws the following exception on the server: 12:03:56,650 ERROR [STDERR] java.lang.NullPointerException 12:03:56,652 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 12:03:56,652 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) 12:03:56,653 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) 12:03:56,653 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 12:03:56,653 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplexProperty.setColumnValue(JDBCT ypeComplexProperty.java:142) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplex.setColumnValue(JDBCTypeCompl ex.java:158) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplex.setColumnValue(JDBCTypeCompl ex.java:133) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgume ntResults(JDBCAbstractCMPFieldBridge.java:352) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstan ceResults(JDBCAbstractCMPFieldBridge.java:304) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntity Command.java:140) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntity Command.java:62) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager .java:496) 12:03:56,656 ERROR [STDERR] at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManage r.java:410) 12:03:56,656 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity (CachedConnectionInterceptor.java:314) 12:03:56,656 ERROR [STDERR] at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchro nizationInterceptor.java:310) 12:03:56,657 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Cac hedConnectionInterceptor.java:147) 12:03:56,657 ERROR [STDERR] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterc eptor.java:193) 12:03:56,657 ERROR [STDERR] at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.ja va:107) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterc eptor.java:69) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercepto r.java:96) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT .java:167) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:1 29) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) 12:03:56,659 ERROR [STDERR] at
Re: [JBoss-dev] [ jboss-Bugs-563448 ] deployment exceptions cause problems
I have a problem with the logic described in this bug. If A does not depend on B then its deployment should not be affected in any way by a failed deployment of B, the dependent object for exactly the reason you discuss. Why should the failure of some connection mgr dependent end up failing the deployment of the valid DefaultDS? This makes the entire system a fragile and unecessary coupled mess. I also have a problem with the behavior of deployment that does not have the required service class as mentioned in bug 559012. There is no failure and no timeout so ultimately it is the user that has to tell you the server is not working. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 02, 2002 5:07 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-563448 ] deployment exceptions cause problems How about deployment returning lists of successfully deployed mbeans, mbeans waiting for others, and mbeans that failed deployment? Due to the dependency management, many of these mbeans may not be in the package just deployed. To make the original deployer of each mbean get notified we will either have to have asynchronous callbacks or multithreaded deployment with blocking on missing mbeans. Can you write down a list of all the problems you have with the dependency system? thanks david jencks On 2002.06.02 01:38:43 -0400 Jason Dillon wrote: Yes, well... the dependency system is flawed in many ways. We should not have to eat exceptions to make it work. Consider command line deployments where if we eat the exception we have no clue if the deploy() op suceeded. Note this is not limited to command line deployments but really anything that needs to rely on an exception being throw and propagated (not eaten) to detect failure sitations. --jason Quoting [EMAIL PROTECTED]: Bugs item #563448, was opened at 2002-06-02 02:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=563448group_id= 22866 Category: JBossServer Group: v3.1 Status: Open Resolution: None Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: Nobody/Anonymous (nobody) Summary: deployment exceptions cause problems Initial Comment: Recently 3.1 and I think 3.0 were modified so that deployment exceptions propagated out of main deployer. This has some questionable consequences in the presence of mbean dependencies, which was the reason I hid the exceptions in the first place. If mbean B depends on mbean A, but B does not deploy successfully, then: If A is deployed first, it will deploy successfully, then B can be deployed unsuccessfully. However if B is deployed first, it will wait for A. During the deployment of A, B will be deployed, and the resulting exception will cause the deployment of A to fail also. For instance, if there is a undeployable depending on the ConnectionManager mbean for DefaultDS, and the undeployable happens to get deployed before the ConnectionManager, it will prevent DefaultDS from deploying, thus breaking large amounts of the system. I'm not sure what the best solution to this is. I don't think the current state of affairs is desirable, since a rogue mbean can break any correctly working mbean by arranging to be deployed first. I lean toward having an easily accessible list of mbeans that can't be deployed and possibly returning a status code from deployers. -- ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-562004 ] 'Error setting column value' using dependent value classes with existing db records
Bugs item #562004, was opened at 2002-05-29 18:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=562004group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Justin Casp (jcasp) Assigned to: Nobody/Anonymous (nobody) Summary: 'Error setting column value' using dependent value classes with existing db records Initial Comment: I posted this problem a few weeks ago on jboss.org forums, but it's down right now so I can't reference that post. I figured out how to create a simple test case that reliably reproduces the problem. The error message 'Error setting column value' occurs when I have an existing CMP bean that reads existing records from a datasource. The bean uses a dependent value class, although I'm not sure if this problem is specific to dependent value classes or just any cmp bean with fields mapped to columns. If I create the record externally (e.g., using psql, the postgres command line tool) and only set a few of the columns to non-null values, when I attempt to load that bean instance with a finder, jboss throws the following exception on the server: 12:03:56,650 ERROR [STDERR] java.lang.NullPointerException 12:03:56,652 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 12:03:56,652 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 12:03:56,653 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 12:03:56,653 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 12:03:56,653 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplexProperty.setColumnValue(JDBCTypeComplexProperty.java:142) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplex.setColumnValue(JDBCTypeComplex.java:158) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplex.setColumnValue(JDBCTypeComplex.java:133) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:352) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:304) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:140) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:62) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:496) 12:03:56,656 ERROR [STDERR] at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:410) 12:03:56,656 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:314) 12:03:56,656 ERROR [STDERR] at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:310) 12:03:56,657 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:147) 12:03:56,657 ERROR [STDERR] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:193) 12:03:56,657 ERROR [STDERR] at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:107) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:145) 12:03:56,660 ERROR [STDERR] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:482) 12:03:56,660 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:694) 12:03:56,660 ERROR [STDERR] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1024) 12:03:56,661 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) 12:03:56,661 ERROR [STDERR] at
Re: [JBoss-dev] new JBoss website KDE's konqueror
Hi Justin, I do see the same problem with an older version of Konqueror AND with Netscape 4.7x. My fix was to remove three NOWRAPs from the HTML source. The needed changes are already in the CVS and should be seen with the next outmated update of the website. Ciao, Tobias Justin Casp wrote: Hey List, I just wanted to say the new JBoss website looks very nice. However, one thing would make it even better: if it rendered properly in konqueror 3.0.0-2, the KDE 3.0 web browser. The main content area is not bounded by the window; it extends several screen-widths to the right, forcing a lot of horizontal scrolling. Briefly looking at the html, it appears to be a table opening/closing issue (i.e., not properly completing a table and/or a few td tags) near the beginning of the content section (starting around '!SIMPLER, CHEAPER, BETTER!'). look towards the end of the output from the following page (midway down): http://validator.w3.org/check/?uri=http%3A//main.jboss.org/ The site renders fine in mozilla though, which is generally a bit more forgiving than konqueror. Thanks for all of the hard work you fellas put into this product. It is certainly appreciated. Justin ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-563448 ] deployment exceptions cause problems
I'm glad we agree there are problems here. What do you think would be the most appropriate behavior? In both cases, the most useful behavior I can' think of is returning lists of mbeans affected by the current deployment ctivity in various states (successfully deployed, waiting for classes, waiting for depend targets, failed). I think the behavior in the current codebase is a clear indication that throwing exceptions to indicate failed deployments causes more problems than it solves. david jencks On 2002.06.02 13:10:48 -0400 Scott M Stark wrote: I have a problem with the logic described in this bug. If A does not depend on B then its deployment should not be affected in any way by a failed deployment of B, the dependent object for exactly the reason you discuss. Why should the failure of some connection mgr dependent end up failing the deployment of the valid DefaultDS? This makes the entire system a fragile and unecessary coupled mess. I also have a problem with the behavior of deployment that does not have the required service class as mentioned in bug 559012. There is no failure and no timeout so ultimately it is the user that has to tell you the server is not working. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 02, 2002 5:07 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-563448 ] deployment exceptions cause problems How about deployment returning lists of successfully deployed mbeans, mbeans waiting for others, and mbeans that failed deployment? Due to the dependency management, many of these mbeans may not be in the package just deployed. To make the original deployer of each mbean get notified we will either have to have asynchronous callbacks or multithreaded deployment with blocking on missing mbeans. Can you write down a list of all the problems you have with the dependency system? thanks david jencks On 2002.06.02 01:38:43 -0400 Jason Dillon wrote: Yes, well... the dependency system is flawed in many ways. We should not have to eat exceptions to make it work. Consider command line deployments where if we eat the exception we have no clue if the deploy() op suceeded. Note this is not limited to command line deployments but really anything that needs to rely on an exception being throw and propagated (not eaten) to detect failure sitations. --jason Quoting [EMAIL PROTECTED]: Bugs item #563448, was opened at 2002-06-02 02:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=563448group_id= 22866 Category: JBossServer Group: v3.1 Status: Open Resolution: None Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: Nobody/Anonymous (nobody) Summary: deployment exceptions cause problems Initial Comment: Recently 3.1 and I think 3.0 were modified so that deployment exceptions propagated out of main deployer. This has some questionable consequences in the presence of mbean dependencies, which was the reason I hid the exceptions in the first place. If mbean B depends on mbean A, but B does not deploy successfully, then: If A is deployed first, it will deploy successfully, then B can be deployed unsuccessfully. However if B is deployed first, it will wait for A. During the deployment of A, B will be deployed, and the resulting exception will cause the deployment of A to fail also. For instance, if there is a undeployable depending on the ConnectionManager mbean for DefaultDS, and the undeployable happens to get deployed before the ConnectionManager, it will prevent DefaultDS from deploying, thus breaking large amounts of the system. I'm not sure what the best solution to this is. I don't think the current state of affairs is desirable, since a rogue mbean can break any correctly working mbean by arranging to be deployed first. I lean toward having an easily accessible list of mbeans that can't be deployed and possibly returning a status code from deployers. -- ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas --
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 2-June-2002
Number of tests run: 606
Successful tests: 605
Errors:0
Failures: 1
[time of test: 2 June 2002 12:29 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.4]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
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.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 2-June-2002
What is that failure? Is it there in 3.0 final also?
Are there any failures when running on sun's 1.4? It just stopped when I tried.
On Sun, Jun 02, 2002 at 12:37:16PM -0700, [EMAIL PROTECTED] wrote:
Number of tests run: 606
Successful tests: 605
Errors:0
Failures: 1
[time of test: 2 June 2002 12:29 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.4]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
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.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
MVH
Marius Kotsbak
Boost communications AS
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 2-June-2002
Scott,
Have you noticed that this URL is broken?
On Monday, June 3, 2002, at 05:37 AM, [EMAIL PROTECTED] wrote:
See http://lubega.com/testarchive/${build.uid} for details of this test.
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where should the Jasper jar live ?
WinZip 8.1 allows you to click on a file to edit it. When you are done, it prompts you whether you want to update the file in the archive. The only braindead thing is it only works with files in the root directory of the archive. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ignacio Coloma Sent: Sunday, June 02, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? Maybe having to install and learn to manage emacs and custom edit the emacs config to modify the Jetty log system (for example) is a bit too much for the average Windows user. Not my case (I use emacs every now and then), but I see this as a major handicap for spreading use of the JBoss/Jetty bundle and subsequent world domination :). I see Scott point of view more practical. OTOH, I also agree that this approach should not be the general case, but necesary for this. I say this because I have to modify every now and then Jetty files and having them on a SAR by default is a PITA. James Higginbotham wrote: David, You can add any extension to the archive mode with the following code in your .emacs: (setq auto-mode-alist (cons '(\\.sar$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.war$ . archive-mode) auto-mode-alist)) (setq auto-mode-alist (cons '(\\.ear$ . archive-mode) auto-mode-alist)) Share and Enjoy, James -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:07 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where should the Jasper jar live ? I still like the sar concept. I notice that emacs can edit files in jars (such as ejb-jar.xml) and save them back into the jar. Anyone know enough elisp to figure out how to make it edit .sar, .ear, .war, etc the same way? (I presume it just means recognizing the file format/extension as zip-like) Then there won't be anything to complain about having to repack for small changes. For large changes you'll be doing an ant build anyway. david jencks On 2002.05.31 21:04:26 -0400 Jules Gosnell wrote: The natural progression of all this separation of config and implementation is that we will begin encouraging people to take all the resources out of their ears and deploy them in lib/, then just drop the dds into deploy/. Ok, so they can edit their descriptors - but it's not J2EE, is it ? Likewise, the sar is a nice extension of the J2EE packaging metaphor. It may not be perfect, but this is the platform that we are implementing, and I think consistency is important. Comments ? Jules Scott M Stark wrote: That is fine but why not just create a single jetty-service.jar that includes all Jetty specific files and have a seperate jetty-service.xml descriptor with your config that references the required jar: server classpath codebase=. archives=jetty-service.jar/ ... This is how I'm packaging the tomcat service except there I also reference the external catalina dist jars as well. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jan Bartel [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:31 PM Subject: [JBoss-dev] Where should the Jasper jar live ? Scott, Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? I figure: - jasper is an implementation - jasper version is tightly bound to Jetty version - Tomcat users will have their own version of Jasper I think the servlet api jar should stay in lib, seeing as this is part of the definition of the JBoss platform and will be needed by users to compile against (whilst they should not need Jetty and Jasper classes) My preemptive advice to anyone concerned that a sar is awkward to work with, because the configuration is, hidden is : run it unpacked. Concerns ? Jules P.S. What is the arrangement between HEAD and Branch_3_0 - would I be correct in assuming that bug-fixes should be merged, but new features not ? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL
[JBoss-dev] Automated JBoss(HEAD) Testsuite Results: 3-June-2002
Number of tests run: 733 Successful tests: 229 Errors:491 Failures: 13 [time of test: 3 June 2002 1:30 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-31] Useful resources: - http://lubega.com/testarchive/ibm_jdk13_20010626 for the junit report of this test. - http://lubega.com/testarchive/ibm_jdk13_20010626/logs/ for the logs for this test. - http://lubega.com for general test information. 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. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-562004 ] 'Error setting column value' using dependent value classes with existing db records
Bugs item #562004, was opened at 2002-05-29 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=562004group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Justin Casp (jcasp) Assigned to: Nobody/Anonymous (nobody) Summary: 'Error setting column value' using dependent value classes with existing db records Initial Comment: I posted this problem a few weeks ago on jboss.org forums, but it's down right now so I can't reference that post. I figured out how to create a simple test case that reliably reproduces the problem. The error message 'Error setting column value' occurs when I have an existing CMP bean that reads existing records from a datasource. The bean uses a dependent value class, although I'm not sure if this problem is specific to dependent value classes or just any cmp bean with fields mapped to columns. If I create the record externally (e.g., using psql, the postgres command line tool) and only set a few of the columns to non-null values, when I attempt to load that bean instance with a finder, jboss throws the following exception on the server: 12:03:56,650 ERROR [STDERR] java.lang.NullPointerException 12:03:56,652 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 12:03:56,652 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 12:03:56,653 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 12:03:56,653 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 12:03:56,653 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplexProperty.setColumnValue(JDBCTypeComplexProperty.java:142) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplex.setColumnValue(JDBCTypeComplex.java:158) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplex.setColumnValue(JDBCTypeComplex.java:133) 12:03:56,654 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgumentResults(JDBCAbstractCMPFieldBridge.java:352) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInstanceResults(JDBCAbstractCMPFieldBridge.java:304) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:140) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEntityCommand.java:62) 12:03:56,655 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManager.java:496) 12:03:56,656 ERROR [STDERR] at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceManager.java:410) 12:03:56,656 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:314) 12:03:56,656 ERROR [STDERR] at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:310) 12:03:56,657 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:147) 12:03:56,657 ERROR [STDERR] at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:193) 12:03:56,657 ERROR [STDERR] at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:107) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) 12:03:56,658 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) 12:03:56,659 ERROR [STDERR] at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:145) 12:03:56,660 ERROR [STDERR] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:482) 12:03:56,660 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:694) 12:03:56,660 ERROR [STDERR] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1024) 12:03:56,661 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) 12:03:56,661 ERROR [STDERR] at
Re: [JBoss-dev] Potential .jar problem in all build.xml(s)
Are you using xdoclet from xdoclet cvs? Does it build jboss correctly? I
would like to upgrade the jboss copy soon and when an xdoclet version is
released.
I think there is also a plan to move jboss specific code from xdoclet to
jboss. There is already an xdoclet include file for mbeans.
Thanks for investigating these duplicate jar problems. Can you build jboss
ok using only the jars from thirdparty (having removed the duplicates from
tools/lib)?
thanks
david jencks
On 2002.06.02 20:44:14 -0400 Frederick N. Brier wrote:
In attempting to use a modified xdoclet.jar local to a sub-project
(jboss.net) so we could slowly develop new XDoclet templates and later
submit them, I discovered that the ant shell script in ./tools/bin is
generating a classpath that is including all of the .jar(s) in
./tools/lib. It was pre-empting path-wise, the path I was specifying in
my
build script.
So even though there is all this code in all the build scripts specifying
the junit.jar in ./thirdparty/junit/junit/lib, the junit.jar actually
getting used is in ./tools/lib. There are classes overlapping in
./thirdparty/apache/log4j/lib/log4j.jar and ./tools/lib/log4j-core.jar.
In
the jmx sub-project build.xml, sax2.jar and sax2-ext.jar, located in
./thirdparty/xml/sax/lib are used which have overlapping classes with
crimson.jar in ./tools/lib. Further, there additional copies of
crimson.jar, jaxp.jar, and xalan.jar in both ./tools/lib and
./thirdparty/sun/jaxp with different dates and sizes. These files are
referenced in the top level build.xml.
There is a duplicate bsf.jar in the ./thirdparty/ibm/bsf/lib, but it
doesn't seem to be used anywhere.
If this really is a problem, several of us could be banging our head
against the wall trying to solve a bug in an old .jar. Perhaps we should
remove any .jar that appears in the thirdparty directory from
./tools/lib,
and only keep Ant required files there. I would like the xdoclet .jars
moved into the thirdparty. That way, as we develop new xdoclet templates
for generating deployment descriptors and code generators, we can evolve
them, before submitting them to be included in the XDoclet codebase.
The
relevant shell script was in ./tools/bin/ant:
# add in the dependency .jar files
DIRLIBS=${ANT_HOME}/lib/*.jar
for i in ${DIRLIBS}
do
# if the directory is empty, then it will return the input string
# this is stupid, so case for it
if [ $i != ${DIRLIBS} ] ; then
if [ -z $LOCALCLASSPATH ] ; then
LOCALCLASSPATH=$i
else
LOCALCLASSPATH=$i:$LOCALCLASSPATH
fi
fi
done
Frederick N. Brier
Sr. Software Engineer
Multideck Corporation
html
In attempting to use a modified xdoclet.jar local to a sub-project
(jboss.net) so we could slowly develop new XDoclet templates and later
submit them, I discovered that the quot;antquot; shell script in
./tools/bin is generating a classpath that is including all of the
.jar(s) in ./tools/lib.nbsp; It was pre-empting path-wise, the path I
was specifying in my build script.br
br
So even though there is all this code in all the build scripts specifying
the junit.jar in ./thirdparty/junit/junit/lib, the junit.jar actually
getting used is in ./tools/lib.nbsp; There are classes overlapping in
./thirdparty/apache/log4j/lib/log4j.jar and
./tools/lib/log4j-core.jar.nbsp; In the jmx sub-project build.xml,
sax2.jar and sax2-ext.jar, located in ./thirdparty/xml/sax/lib are used
which have overlapping classes with crimson.jar in ./tools/lib.nbsp;
Further, there additional copies of crimson.jar, jaxp.jar, and xalan.jar
in both ./tools/lib and ./thirdparty/sun/jaxp with different dates and
sizes.nbsp; These files are referenced in the top level build.xml.br
br
There is a duplicate bsf.jar in the ./thirdparty/ibm/bsf/lib, but it
doesn't seem to be used anywhere.br
br
If this really is a problem, several of us could be banging our head
against the wall trying to solve a bug in an old .jar.nbsp; Perhaps we
should remove any .jar that appears in the thirdparty directory from
./tools/lib, and only keep Ant required files there.nbsp; I would like
the xdoclet .jars moved into the thirdparty. That way, as we develop new
xdoclet templates for generating deployment descriptors and code
generators, we can evolve them, beforenbsp;nbsp; submitting them to be
included in the XDoclet codebase.nbsp; The relevant shell script was in
./tools/bin/ant:br
br
font face=Courier, Courier# add in the dependency .jar filesbr
DIRLIBS=${ANT_HOME}/lib/*.jarbr
for i in ${DIRLIBS}br
dobr
nbsp;nbsp;nbsp; # if the directory is empty, then it will return the
input stringbr
nbsp;nbsp;nbsp; # this is stupid, so case for itbr
nbsp;nbsp;nbsp; if [ quot;$iquot; != quot;${DIRLIBS}quot; ] ;
thenbr
nbsp;nbsp;nbsp;nbsp;nbsp; if [ -z quot;$LOCALCLASSPATHquot; ] ;
thenbr
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
[JBoss-dev] Re: [Xdoclet-user] Weird appearing X problem
I think I've tracked the problem down. The version of xdoclet.jar that is in the JBoss 3.0 CVS tree has a bug in it. Unzipping the .jar and looking at the binaries, both of the TLD_PUBLICID constants for 1.1 and 1.2 in JspTaglibSubTask.class both say XTag. Very bizarre. I will update the .jar in CVS. The final XDoclet 1.1.2 release that I snagged out of the XDoclet CVS did not have the bug. Thanks. Fred. At 09:21 PM 6/2/2002, you wrote: I have been trying to track down a problem, but feel like I am in the twilight zone. The line below says DTD JSP XTag Library instead of DTD JSP Tag Library, I have no idea where the X is coming from. !DOCTYPE taglib PUBLIC -//Sun Microsystems, Inc.//DTD JSP XTag Library 1.2//EN http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd; The JspTaglibSubTask.java file clearly says: private static String TLD_PUBLICID_1_2 = -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN; So where could the XTag be coming from. I've run the build a couple of times. The files are not getting filtered. They are generated to a destination directory and not moved. Any ideas? Anyone seen anything weird like this before? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [Xdoclet-user] Weird appearing X problem
Please be careful. IIRC, the jboss xdoclet version is tagged in xdoclet source and is ___AFTER___ 1.1.2, and it includes some functionality I added not in 1.1.2 that is used in the build. Please try with the cvs version of xdoclet. If it works I can tag the xdoclet source and get a reproducible version in jboss. Be sure to do a clean build and run the testsuite before changing the xdoclet version. thanks david jencks On 2002.06.02 22:15:19 -0400 Frederick N. Brier wrote: I think I've tracked the problem down. The version of xdoclet.jar that is in the JBoss 3.0 CVS tree has a bug in it. Unzipping the .jar and looking at the binaries, both of the TLD_PUBLICID constants for 1.1 and 1.2 in JspTaglibSubTask.class both say XTag. Very bizarre. I will update the .jar in CVS. The final XDoclet 1.1.2 release that I snagged out of the XDoclet CVS did not have the bug. Thanks. Fred. At 09:21 PM 6/2/2002, you wrote: I have been trying to track down a problem, but feel like I am in the twilight zone. The line below says DTD JSP XTag Library instead of DTD JSP Tag Library, I have no idea where the X is coming from. !DOCTYPE taglib PUBLIC -//Sun Microsystems, Inc.//DTD JSP XTag Library 1.2//EN http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd; The JspTaglibSubTask.java file clearly says: private static String TLD_PUBLICID_1_2 = -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN; So where could the XTag be coming from. I've run the build a couple of times. The files are not getting filtered. They are generated to a destination directory and not moved. Any ideas? Anyone seen anything weird like this before? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
