[JBoss-dev] Automated JBoss Testsuite Results: 30-April-2002
Number of tests run: 584 Successful tests: 561 Errors:21 Failures: 2 [time of test: 30 April 2002 8:13 GMT] [java.version: 1.4.0] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.0-b92] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_j2sdk140 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 30-April-2002
Number of tests run: 578 Successful tests: 555 Errors:22 Failures: 1 [time of test: 30 April 2002 7:17 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_02 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
For what its worth, here's my hand reconfig notes for changing the
default DS to Oracle prior to running the test suite:
Oracle Setup for JBoss Unit Test Suite
1. Add the following to auth.conf
OracleDbRealm {
//
// Security domain for new jca framework.
// One per ManagedConnectionFactory are required.
org.jboss.resource.security.ConfiguredIdentityLoginModule required
principal="jbtest"
userName="jbtest"
password="jbtest"
managedConnectionFactoryName="jboss.jca:service=LocalTxCM,name=OracleDS"
;
};
2. Add oracle-service.xml to deploy directory
3. Change the jndi name in hsqldb-service.xml to (say) hsqldbDS
4. Change the jndi name in oracle-service.xml to DefaultDS
5. Ensure that conf/standardjbosscmp-jdbc.xml has up-to-date Oracle
mappings and the
default type mapping points at it
6. Ensure that conf/standardjaws.xml has up-to-date Oracle mappings
and the default
type mapping points at it
Some of this is slightly out of date with the introduction of
login-config.xml, but I think it provides the information that anyone
needs.
On Tuesday, April 30, 2002, at 02:31 PM, David Jencks wrote:
> On 2002.04.29 23:35:20 -0400 Dain Sundstrom wrote:
>> Stephen Coy wrote:
>>
>>> I'm willing to tackle this. Do you have any idea what shape you would
>>> like?
>>
>>
>> Not sure what that means.
>>
>>> Particular areas to cover?
>>
>>
>> To start the I'd just like to see the CMP 1.1 tests running under
>> JBossCMP and JAWS in the unit test suite. Then it would be cool to
>> have
>> similar tests that are just modified for CMP 2.0, but that is for
>> another day. The following tests should run fine in JBossCMP
>>
>>
> ./resources/bank/META-INF/jaws.xml
> ./resources/bankiiop/META-INF/jaws.xml
> ./resources/bench/ejb/META-INF/jaws.xml
> ./resources/dbtest/META-INF/jaws.xml
>>
> ./resources/testbean2/META-INF/jaws.xml
>>
>> This test may not run as readahead is very different in JBossCMP
>>
> ./resources/readahead/META-INF/jaws.xml
>>
>> Also, David was looking at changing the config files so the tests could
>> be run under several databases. To start we just need to remove any
>> specified datasource or type-mapping elements from the jaws.xml files.
>> Then we need to figure out how to gets the test code to switch
>> DefaultDS
>> and the default type-mapping (datasource-mapping in JBossCMP). Again,
>> that is for another day.
>
> I think our best bet for this is to use the ant copy/filter task to
> replace
> tokens where needed. I think it will take building jboss + the
> testsuite
> for a given db so that standardJaws and standardJbossCmp-jdbc have the
> appropriate type mapping. I may have already done this, I can't
> remember.
>
> I'll say it again, I think eventually all the ejbs in our tests should
> be
> built with xdoclet (except perhaps for the ones that intentionally have
> errors;-) If I had time to work on this I would be moving the tests to
> xdoclet now.
>
> thanks
> david jencks
>
>>
>> Remember KISS,
>>
>> -dain
>>
>>
>> ___
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 30-April-2002
Number of tests run: 579 Successful tests: 556 Errors:22 Failures: 1 [time of test: 30 April 2002 5:52 GMT] [java.version: 1.3.1_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_03-b03] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_03 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ JavaCC Problem
To all JavaCC Gurus, The javacc grammar that JBossMQ is using has a problem. It can't detect that the selector: "definitely not a message selector!" is an invalid selector. It just parses the first itentifier, "definitely" and then skips over the rest of the selector. Is there an easy way for javacc to pick up that there are some excess tokens and spit out an error??? Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
On 2002.04.29 23:35:20 -0400 Dain Sundstrom wrote: > Stephen Coy wrote: > > > I'm willing to tackle this. Do you have any idea what shape you would > > like? > > > Not sure what that means. > > > Particular areas to cover? > > > To start the I'd just like to see the CMP 1.1 tests running under > JBossCMP and JAWS in the unit test suite. Then it would be cool to have > similar tests that are just modified for CMP 2.0, but that is for > another day. The following tests should run fine in JBossCMP > > > >>> ./resources/bank/META-INF/jaws.xml > >>> ./resources/bankiiop/META-INF/jaws.xml > >>> ./resources/bench/ejb/META-INF/jaws.xml > >>> ./resources/dbtest/META-INF/jaws.xml > > >>> ./resources/testbean2/META-INF/jaws.xml > > This test may not run as readahead is very different in JBossCMP > > >>> ./resources/readahead/META-INF/jaws.xml > > Also, David was looking at changing the config files so the tests could > be run under several databases. To start we just need to remove any > specified datasource or type-mapping elements from the jaws.xml files. > Then we need to figure out how to gets the test code to switch DefaultDS > and the default type-mapping (datasource-mapping in JBossCMP). Again, > that is for another day. I think our best bet for this is to use the ant copy/filter task to replace tokens where needed. I think it will take building jboss + the testsuite for a given db so that standardJaws and standardJbossCmp-jdbc have the appropriate type mapping. I may have already done this, I can't remember. I'll say it again, I think eventually all the ejbs in our tests should be built with xdoclet (except perhaps for the ones that intentionally have errors;-) If I had time to work on this I would be moving the tests to xdoclet now. thanks david jencks > > Remember KISS, > > -dain > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
Stephen Coy wrote: > I'm willing to tackle this. Do you have any idea what shape you would > like? Not sure what that means. > Particular areas to cover? To start the I'd just like to see the CMP 1.1 tests running under JBossCMP and JAWS in the unit test suite. Then it would be cool to have similar tests that are just modified for CMP 2.0, but that is for another day. The following tests should run fine in JBossCMP >>> ./resources/bank/META-INF/jaws.xml >>> ./resources/bankiiop/META-INF/jaws.xml >>> ./resources/bench/ejb/META-INF/jaws.xml >>> ./resources/dbtest/META-INF/jaws.xml >>> ./resources/testbean2/META-INF/jaws.xml This test may not run as readahead is very different in JBossCMP >>> ./resources/readahead/META-INF/jaws.xml Also, David was looking at changing the config files so the tests could be run under several databases. To start we just need to remove any specified datasource or type-mapping elements from the jaws.xml files. Then we need to figure out how to gets the test code to switch DefaultDS and the default type-mapping (datasource-mapping in JBossCMP). Again, that is for another day. Remember KISS, -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 30-April-2002
Number of tests run: 584 Successful tests: 570 Errors:13 Failures: 1 [time of test: 30 April 2002 4:14 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] System out usage creeping back in?
19:58:53,880 INFO [STDOUT] * putting invoker entity-rmi-invoker into ApplicationMetaData 19:58:55,543 INFO [STDOUT] _ creating binding for ejb/jmx/ejb/Adaptor:stateless-rmi-invoker 19:58:55,763 INFO [STDOUT] ---Binding Home ejb/jmx/ejb/Adaptor Please use logging. --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=14412 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
I'm willing to tackle this. Do you have any idea what shape you would like? Particular areas to cover? On Tuesday, April 30, 2002, at 04:31 AM, Dain Sundstrom wrote: > Yep the main test only use JAWS. I think david was looking at getting > these tests to use JAWS and JBossCMP, but I think he got to busy. Do > you want to try to get them running under JAWS and JBossCMP? > > -dain > > Stephen Coy wrote: > >> Hi, >> By looking for usage of jaws.xml files, I think I've uncovered some >> holes in the test suite: >> [steve@ws102 src]$ find . -name jaws.xml >> ./resources/bank/META-INF/jaws.xml >> ./resources/bankiiop/META-INF/jaws.xml >> ./resources/bench/ejb/META-INF/jaws.xml >> ./resources/dbtest/META-INF/jaws.xml >> ./resources/readahead/META-INF/jaws.xml >> ./resources/testbean2/META-INF/jaws.xml >> These tests all exercise CMP1.1, but as far as can see (with a cursory >> look), there are no equivalent tests for CMP2.0. >> In particular, I think that we need a CMP2.0 version of dbtest, >> because this is extremely useful for checking the default >> standardjbosscmp- >> jdbc.xml mappings with different databases. >> Steve Coy >> ___ >> 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: 30-April-2002
Number of tests run: 584 Successful tests: 562 Errors:21 Failures: 1 [time of test: 30 April 2002 2:56 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-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-31] See http://lubega.com/testarchive/blackdown_jdk131_02_native 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss 2.4.x Marathon Tests
Hi Geeks Just uploaded the newest version of the 2.4.x marathon test. It contains it own compilation path and startup script (see: /jbosstest/src/build/marathon.sh) which you can adjust to your needs. Of course there is also a windows script: marathon.bat. ATTENTION: the idea behind is to run this on a moderate load for hours or days (50 to 60% CPU load) best of course on 2 boxes (client/server). Please adjust the THREAD_COUNT accordingly (on a Pentium III I could run 100 to 130 threads on a Pentium IV 200 to 350). If the load is too high you will get a backlog on the transactions, they will timeout and the test will exit. Currently I am working on a JBossMQ test because Hiram and I found some problems with it. I am still looking for a good test scenario because the only one I came up was a mail server sending messages to a MDB to be saved in a DB. So does anyone have an idea to test connections,session, topics and queues because I found a real scenario better to implement and to analyse than a complete artifical one. Have fun BTW by tomorrow I will port this to JBoss 3 as well. x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 30-April-2002
Number of tests run: 575 Successful tests: 549 Errors:15 Failures: 11 [time of test: 30 April 2002 2:5 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-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20020124 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
I just double checked my app and I am closing senders, sessions and connections where appropriate... and yet I am still getting XAExceptions like this: WARN TxCapsule [SocketListener-1] (MailingManager) XAException: tx=XidImpl [FormatId=257, GlobalId=eng-ecr3a//21, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException at com.swiftmq.jms.XAResourceImpl.start(XAResourceImpl.java:121) at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1090) at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:623) at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:111) at org.jboss.pool.connector.BaseConnectionManager$XAListener.enlist(BaseConnectionManager.java:592) at org.jboss.pool.connector.BaseConnectionManager$XAListener.register(BaseConnectionManager.java:601) at org.jboss.pool.connector.XAConnectionManager.allocateConnection(XAConnectionManager.java:95) at org.jboss.jms.ra.JmsSessionFactoryImpl.createQueueSession(JmsSessionFactoryImpl.java:125) at com.boldfish.does.mailing.service.internal.MailingManagerEJB.enqueueStartJob(MailingManagerEJB.java:130) at com.boldfish.does.mailing.service.internal.MailingManagerEJB.enqueueCreateJob(MailingManagerEJB.java:230) at com.boldfish.does.mailing.service.internal.MailingManagerEJB.createMailing(MailingManagerEJB.java:253) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:572) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:67) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:282) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445) at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:339) at org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123) at $Proxy9.createMailing(Unknown Source) at com.boldfish.does.listener.xmlrpc.MailingHandler.createMailing(MailingHandler.java:977) at com.boldfish.does.listener.xmlrpc.MailingHandler.uploadEndOfPostedList(MailingHandler.java:763) at java.lang.reflect.Method.invoke(Native Method) at com.boldfish.xmlrpc.handler.DynamicHandler.execute(DynamicHandler.java:126) at com.boldfish.xmlrpc.handler.DynamicHandler.execute(DynamicHandler.java:81) at com.boldfish.xmlrpc.handler.NestedHandler.execute(NestedHandler.java:79) at com.boldfish.xmlrpc.handler.XmlRpcHandlerAdapter.execute(XmlRpcHandlerAdapter.java:56) at org.apache.xmlrpc.XmlRpcServer$Worker.execute(XmlRpcServer.java) at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java) at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java) at com.boldfish.xmlrpc.handler.servlet.XRServlet.doPost(XRServlet.java:205) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.boldfish.xmlrpc.handler.servlet.XRServlet.service(XRServlet.java:127) at com.mortbay.Jetty.Servlet.ServletHolder.handle(ServletHolder.java:488) at com.mortbay.Jetty.Servlet.ServletHandler.handle(ServletHandler.java:537) at com.mortbay.Jetty.Servlet.ServletHandler.handle(ServletHandler.java:366) at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:956) at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:913) at com.mortbay.HTTP.HttpServer.service(HttpServer.java:718) at com.mortbay.HTTP.HttpConnection.service(HttpConnection.java:547) at com.mortbay.HTTP.HttpConnection.handle(HttpConnection.java:365) at com.mortbay.HTTP.SocketListener.handleConnection(SocketListener.java:107) at com.mortbay.Util.ThreadedServer.handle(ThreadedServer.java:294) at com.mortbay.Util.ThreadPool$PoolThreadRunnable.run(ThreadPool.java:613) at java.lang.Thread.run(Thread.java:484) Note this is in a pre 3.0 container... I will try running the same app in the 3.0 RC, but that is going to be a pain, since I have to reconfig everything (and unsar jetty and others so that I can config everything as I could in 2.4.x & pre-3.0. I posted a question on the SwiftMQ forums, but if someone here could tell
[JBoss-dev] Automated JBoss Testsuite Results: 30-April-2002
Number of tests run: 584 Successful tests: 560 Errors:13 Failures: 11 [time of test: 30 April 2002 0:40 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] See http://lubega.com/testarchive/ibm_jdk13_20010626 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS HEAD in danger
||I was just kidding... I was smoking blunts =P | |Ah then I am not the one to blame you :T I miss saying hi to my little green friends marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS HEAD in danger
|I was just kidding... I was smoking blunts =P Ah then I am not the one to blame you :T marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS HEAD in danger
The sauce helps me to wake up in the morning... I was just kidding... I was smoking blunts =P --jason marc fleury wrote: >aaaww, cuute > >isn't this pretty, you ladies are so polite, > >even SMD sounds kind of polite in your case, > >marcf > >PS: what the F*CK is jason doing on Gin and Juice at 3 PM on a Monday... or >are you talking about yesterday... well come to think of it I was on the >juice for the server side video blurb (upcoming) > > >|-Original Message- >|From: [EMAIL PROTECTED] >|[mailto:[EMAIL PROTECTED]]On Behalf Of Bill >|Burke >|Sent: Monday, April 29, 2002 2:59 PM >|To: Jason Dillon >|Cc: Jboss-Dev >|Subject: RE: [JBoss-dev] CVS HEAD in danger >| >| >|Dude, I was in a bad mood this morning. Sorry for being harsh. >| >|> -Original Message- >|> From: [EMAIL PROTECTED] >|> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason >|> Dillon >|> Sent: Monday, April 29, 2002 5:51 PM >|> To: Bill Burke >|> Cc: Jboss-Dev >|> Subject: RE: [JBoss-dev] CVS HEAD in danger >|> >|> >|> I am chill'n like a villon... got me some gin and juice and I am >|> mighty fine. >|> >|> As my note said, I had not finished reading email, and I did notice some >|> subjects that indicated that CVS was happy... no problem there. >|> I did still >|> feel the need to express that I feel very strongly about properly >|> merging to >|> avoid losing work. >|> >|> Your words "... so I may kill commits that that have been done in that >|> timespan" made it appear as if you were not going to merge... so >|> I commented >|> on it. >|> >|> Anyways, it is all good... no worries. >|> >|> --jason >|> >|> >|> Quoting Bill Burke <[EMAIL PROTECTED]>: >|> >|> > Fucking chill! I merged then committed. Everything is fine. >|> > >|> > > -Original Message- >|> > > From: [EMAIL PROTECTED] >|> > > [mailto:[EMAIL PROTECTED]]On >|> Behalf Of Jason >|> > > Dillon >|> > > Sent: Monday, April 29, 2002 3:28 AM >|> > > To: Bill Burke >|> > > Cc: Jboss-Dev >|> > > Subject: Re: [JBoss-dev] CVS HEAD in danger >|> > > >|> > > >|> > > WHAT!!!?? This is not cool... I am still early into reading 300+ >|> > > messages for >|> > > today... one of which I think you posted saying things are >|cool... BUT >|> > > >|> > > It is not cool to not update your workspace before committing. >|> > > Marc has done >|> > > this before and it just ends up in lost work... some of my >|> > > work... minor and >|> > > easy to fix, but a royal pain in the ass. We have a version >|> > > control system to >|> > > avoid problems like this. >|> > > >|> > > True CVS is crap when it comes to merging, but this can be >|> minimized by >|> > > disabling keyword subst and isolating your updates & checking >|> for merge >|> > > conflicts. >|> > > >|> > > Committing in a fashion where it losses potential fixes, >|> enhancements or >|> > > documentation is a very, very, very, VERY bad idea. >|> > > >|> > > Please don't... take the time and deal with the merges. Please. >|> > > >|> > > --jason >|> > > >|> > > >|> > > Quoting Bill Burke <[EMAIL PROTECTED]>: >|> > > >|> > > > I'll be doing some major commits in a few hours. I haven't >|> merged from >|> > > > mainline in about 1.5 weeks so I may kill commits that have >|> been done >|> > in >|> > > > that timespan. Sorry for the problems... >|> > > > >|> > > > Bill >|> > > > >|> > > > >|> > > > ___ >|> > > > Jboss-development mailing list >|> > > > [EMAIL PROTECTED] >|> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development >|> > > > >|> > > >|> > > >|> > > >|> > > >|> > > - >|> > > This mail sent through IMP: http://horde.org/imp/ >|> > > >|> > > ___ >|> > > Jboss-development mailing list >|> > > [EMAIL PROTECTED] >|> > > https://lists.sourceforge.net/lists/listinfo/jboss-development >|> > >|> >|> >|> >|> >|> - >|> This mail sent through IMP: http://horde.org/imp/ >|> >|> ___ >|> Jboss-development mailing list >|> [EMAIL PROTECTED] >|> https://lists.sourceforge.net/lists/listinfo/jboss-development >| >| >|___ >|Jboss-development mailing list >|[EMAIL PROTECTED] >|https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS HEAD in danger
aaaww, cuute isn't this pretty, you ladies are so polite, even SMD sounds kind of polite in your case, marcf PS: what the F*CK is jason doing on Gin and Juice at 3 PM on a Monday... or are you talking about yesterday... well come to think of it I was on the juice for the server side video blurb (upcoming) |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Monday, April 29, 2002 2:59 PM |To: Jason Dillon |Cc: Jboss-Dev |Subject: RE: [JBoss-dev] CVS HEAD in danger | | |Dude, I was in a bad mood this morning. Sorry for being harsh. | |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason |> Dillon |> Sent: Monday, April 29, 2002 5:51 PM |> To: Bill Burke |> Cc: Jboss-Dev |> Subject: RE: [JBoss-dev] CVS HEAD in danger |> |> |> I am chill'n like a villon... got me some gin and juice and I am |> mighty fine. |> |> As my note said, I had not finished reading email, and I did notice some |> subjects that indicated that CVS was happy... no problem there. |> I did still |> feel the need to express that I feel very strongly about properly |> merging to |> avoid losing work. |> |> Your words "... so I may kill commits that that have been done in that |> timespan" made it appear as if you were not going to merge... so |> I commented |> on it. |> |> Anyways, it is all good... no worries. |> |> --jason |> |> |> Quoting Bill Burke <[EMAIL PROTECTED]>: |> |> > Fucking chill! I merged then committed. Everything is fine. |> > |> > > -Original Message- |> > > From: [EMAIL PROTECTED] |> > > [mailto:[EMAIL PROTECTED]]On |> Behalf Of Jason |> > > Dillon |> > > Sent: Monday, April 29, 2002 3:28 AM |> > > To: Bill Burke |> > > Cc: Jboss-Dev |> > > Subject: Re: [JBoss-dev] CVS HEAD in danger |> > > |> > > |> > > WHAT!!!?? This is not cool... I am still early into reading 300+ |> > > messages for |> > > today... one of which I think you posted saying things are |cool... BUT |> > > |> > > It is not cool to not update your workspace before committing. |> > > Marc has done |> > > this before and it just ends up in lost work... some of my |> > > work... minor and |> > > easy to fix, but a royal pain in the ass. We have a version |> > > control system to |> > > avoid problems like this. |> > > |> > > True CVS is crap when it comes to merging, but this can be |> minimized by |> > > disabling keyword subst and isolating your updates & checking |> for merge |> > > conflicts. |> > > |> > > Committing in a fashion where it losses potential fixes, |> enhancements or |> > > documentation is a very, very, very, VERY bad idea. |> > > |> > > Please don't... take the time and deal with the merges. Please. |> > > |> > > --jason |> > > |> > > |> > > Quoting Bill Burke <[EMAIL PROTECTED]>: |> > > |> > > > I'll be doing some major commits in a few hours. I haven't |> merged from |> > > > mainline in about 1.5 weeks so I may kill commits that have |> been done |> > in |> > > > that timespan. Sorry for the problems... |> > > > |> > > > Bill |> > > > |> > > > |> > > > ___ |> > > > Jboss-development mailing list |> > > > [EMAIL PROTECTED] |> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development |> > > > |> > > |> > > |> > > |> > > |> > > - |> > > This mail sent through IMP: http://horde.org/imp/ |> > > |> > > ___ |> > > Jboss-development mailing list |> > > [EMAIL PROTECTED] |> > > https://lists.sourceforge.net/lists/listinfo/jboss-development |> > |> |> |> |> |> - |> This mail sent through IMP: http://horde.org/imp/ |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS HEAD in danger
Dude, I was in a bad mood this morning. Sorry for being harsh. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > Dillon > Sent: Monday, April 29, 2002 5:51 PM > To: Bill Burke > Cc: Jboss-Dev > Subject: RE: [JBoss-dev] CVS HEAD in danger > > > I am chill'n like a villon... got me some gin and juice and I am > mighty fine. > > As my note said, I had not finished reading email, and I did notice some > subjects that indicated that CVS was happy... no problem there. > I did still > feel the need to express that I feel very strongly about properly > merging to > avoid losing work. > > Your words "... so I may kill commits that that have been done in that > timespan" made it appear as if you were not going to merge... so > I commented > on it. > > Anyways, it is all good... no worries. > > --jason > > > Quoting Bill Burke <[EMAIL PROTECTED]>: > > > Fucking chill! I merged then committed. Everything is fine. > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Jason > > > Dillon > > > Sent: Monday, April 29, 2002 3:28 AM > > > To: Bill Burke > > > Cc: Jboss-Dev > > > Subject: Re: [JBoss-dev] CVS HEAD in danger > > > > > > > > > WHAT!!!?? This is not cool... I am still early into reading 300+ > > > messages for > > > today... one of which I think you posted saying things are cool... BUT > > > > > > It is not cool to not update your workspace before committing. > > > Marc has done > > > this before and it just ends up in lost work... some of my > > > work... minor and > > > easy to fix, but a royal pain in the ass. We have a version > > > control system to > > > avoid problems like this. > > > > > > True CVS is crap when it comes to merging, but this can be > minimized by > > > disabling keyword subst and isolating your updates & checking > for merge > > > conflicts. > > > > > > Committing in a fashion where it losses potential fixes, > enhancements or > > > documentation is a very, very, very, VERY bad idea. > > > > > > Please don't... take the time and deal with the merges. Please. > > > > > > --jason > > > > > > > > > Quoting Bill Burke <[EMAIL PROTECTED]>: > > > > > > > I'll be doing some major commits in a few hours. I haven't > merged from > > > > mainline in about 1.5 weeks so I may kill commits that have > been done > > in > > > > that timespan. Sorry for the problems... > > > > > > > > Bill > > > > > > > > > > > > ___ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > > > > > - > > > This mail sent through IMP: http://horde.org/imp/ > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS HEAD in danger
I am chill'n like a villon... got me some gin and juice and I am mighty fine. As my note said, I had not finished reading email, and I did notice some subjects that indicated that CVS was happy... no problem there. I did still feel the need to express that I feel very strongly about properly merging to avoid losing work. Your words "... so I may kill commits that that have been done in that timespan" made it appear as if you were not going to merge... so I commented on it. Anyways, it is all good... no worries. --jason Quoting Bill Burke <[EMAIL PROTECTED]>: > Fucking chill! I merged then committed. Everything is fine. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > > Dillon > > Sent: Monday, April 29, 2002 3:28 AM > > To: Bill Burke > > Cc: Jboss-Dev > > Subject: Re: [JBoss-dev] CVS HEAD in danger > > > > > > WHAT!!!?? This is not cool... I am still early into reading 300+ > > messages for > > today... one of which I think you posted saying things are cool... BUT > > > > It is not cool to not update your workspace before committing. > > Marc has done > > this before and it just ends up in lost work... some of my > > work... minor and > > easy to fix, but a royal pain in the ass. We have a version > > control system to > > avoid problems like this. > > > > True CVS is crap when it comes to merging, but this can be minimized by > > disabling keyword subst and isolating your updates & checking for merge > > conflicts. > > > > Committing in a fashion where it losses potential fixes, enhancements or > > documentation is a very, very, very, VERY bad idea. > > > > Please don't... take the time and deal with the merges. Please. > > > > --jason > > > > > > Quoting Bill Burke <[EMAIL PROTECTED]>: > > > > > I'll be doing some major commits in a few hours. I haven't merged from > > > mainline in about 1.5 weeks so I may kill commits that have been done > in > > > that timespan. Sorry for the problems... > > > > > > Bill > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > - > > This mail sent through IMP: http://horde.org/imp/ > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
|standard consultant disclaimer: "Or not." ha ha aha aha LOL LOL LOL Reminds me of the days I was out there, thinking to myself, "whatever you say dude! I charge you by the hour"... these days I do the exact opposite, I say exactly what is on my mind, with all the diplomacy you know I am capable of (not) and they seem to like it... :) man that made my day marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-550389 ] jboss_3_0.dtd
Bugs item #550389, was opened at 2002-04-29 15:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=550389&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Dennis Muhlestein (mulicheng) Assigned to: Nobody/Anonymous (nobody) Summary: jboss_3_0.dtd Initial Comment: According to the dtd for jboss.xml: All the fields in container-configuration are optional (Except container-name). I want to change only one attribute like this: Commit A A JBoss croaks with many Null-Pointer exceptions If I try this. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=550389&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
The spec says that NOT_SUPPORTED is an optional thing for entities. Frankly, I'm glad that the new stuff doesn't support it - really the bizarre thing is doing anything with a dirty entity outside of a transaction. It means that somebody is bringing in a lot of overhead and not making use of any of it. I think that if you're going to allow this nonsense, though, that storing does follow the principal of least astonishment by extending the equally bletcherous notion of JDBC 'auto-commit'. standard consultant disclaimer: "Or not." -danch marc fleury wrote: > I know, i agree, but most don't :( > > the claim (supposedly from the spec) is that the absence of a transaction > triggers a storage. > > If you ask it makes no sense > > marcf > > PS: can you get to compile on JDK1.4? > > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill > |Burke > |Sent: Monday, April 29, 2002 12:58 PM > |To: Jboss-Dev > |Subject: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method? > | > | > |Why are we storing a dirty entity when the method call is not called within > |the context of a transaction (NOT_SUPPORTED, NEVER, etc...)? Seems kind of > |bizarre. > | > |Bill > | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
The jca spec says any operations done outside a managed transaction (i.e one controlled by the tx manager) should be autocommit. So, presumably they envisage writes being done outside tx, such as those you speak of. The new local wrapper has this behavior, the xa one still doesn't. david jencks On 2002.04.29 16:23:50 -0400 marc fleury wrote: > I know, i agree, but most don't :( > > the claim (supposedly from the spec) is that the absence of a transaction > triggers a storage. > > If you ask it makes no sense > > marcf > > PS: can you get to compile on JDK1.4? > > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill > |Burke > |Sent: Monday, April 29, 2002 12:58 PM > |To: Jboss-Dev > |Subject: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method? > | > | > |Why are we storing a dirty entity when the method call is not called > within > |the context of a transaction (NOT_SUPPORTED, NEVER, etc...)? Seems kind > of > |bizarre. > | > |Bill > | > | > |___ > |Jboss-development mailing list > |[EMAIL PROTECTED] > |https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
both, frankly it is now so inter-woven in applications that it would be suicidal to change that. I just wanted to go on record for the Nth time that it makes little sense to me. That is what Bill is pointing out as well. It seems bizarre to me as well. Oh well, marcf "con la iglesia hemos topado amigo sancho" -- Don Quijote -- |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Monday, April 29, 2002 1:29 PM |To: Bill Burke |Cc: Jboss-Dev |Subject: Re: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method? | | |JAWS or JBossCMP? JBossCMP must have a transaction. | |-dain | |Bill Burke wrote: | |> Why are we storing a dirty entity when the method call is not |called within |> the context of a transaction (NOT_SUPPORTED, NEVER, etc...)? |Seems kind of |> bizarre. |> |> Bill |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
JAWS or JBossCMP? JBossCMP must have a transaction. -dain Bill Burke wrote: > Why are we storing a dirty entity when the method call is not called within > the context of a transaction (NOT_SUPPORTED, NEVER, etc...)? Seems kind of > bizarre. > > Bill > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: build fails on connectors?
??? from the jdk 1.4 javadoc for java.sql.CallableStatement. Works for me with linux jdk 1.4. This is a jdbc 3 method, however its part of jdk 1.4 david jencks --- setNull public void setNull(String parameterName, int sqlType, String typeName) throws SQLException Sets the designated parameter to SQL NULL. This version of the method setNull should be used for user-defined types and REF type parameters. Examples of user-defined types include: STRUCT, DISTINCT, JAVA_OBJECT, and named array types. Note: To be portable, applications must give the SQL type code and the fully-qualified SQL type name when specifying a NULL user-defined or REF parameter. In the case of a user-defined type the name is the type name of the parameter itself. For a REF parameter, the name is the type name of the referenced type. If a JDBC driver does not need the type code or type name information, it may ignore it. Although it is intended for user-defined and Ref parameters, this method may be used to set a null parameter of any JDBC type. If the parameter does not have a user-defined or REF type, the given typeName is ignored. Parameters: sqlType - a value from java.sql.TypestypeName - the fully-qualified name of an SQL user-defined type; ignored if the parameter is not a user-defined type or SQL REF value Throws: SQLException - if a database access error occursSince: 1.4 On 2002.04.29 16:06:34 -0400 marc fleury wrote: > ok second time today I do a clean co (yeah the one where I nuke my > repository) and I can't compile. > > I get > > compile-source-jdbc-version: > > compile-classes: > [mkdir] Created dir: > C:\cygwin\home\Administrator\jboss-all\connector\output > \classes > [javac] Compiling 55 source files to > C:\cygwin\home\Administrator\jboss-all\ > connector\output\classes > C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re > sour > ce\adapter\jdbc\local\LocalPreparedStatement.java:42: warning: > setUnicodeStream( > int,java.io.InputStream,int) in java.sql.PreparedStatement has been > deprecated > public class LocalPreparedStatement >^ > C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re > sour > ce\adapter\jdbc\local\LocalPreparedStatement.java:529: warning: > setUnicodeStream > (int,java.io.InputStream,int) in java.sql.PreparedStatement has been > deprecated > ps.setUnicodeStream(parameterIndex, stream, length); >^ > C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re > sour > ce\adapter\jdbc\local\LocalCallableStatement.java:66: warning: > getBigDecimal(int > ,int) in java.sql.CallableStatement has been deprecated > public class LocalCallableStatement >^ > C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re > sour > ce\adapter\jdbc\local\LocalCallableStatement.java:66: warning: > setUnicodeStream( > int,java.io.InputStream,int) in java.sql.PreparedStatement has been > deprecated > public class LocalCallableStatement >^ > C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re > sour > ce\adapter\jdbc\local\LocalCallableStatement.java:980: warning: > getBigDecimal(in > t,int) in java.sql.CallableStatement has been deprecated > return cs.getBigDecimal(parameterIndex, scale); > ^ > C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re > sour > ce\adapter\jdbc\local\LocalCallableStatement.java:1516: cannot resolve > symbol > symbol : method setNull (java.lang.String,int,java.lang.String) > location: interface java.sql.CallableStatement > cs.setNull(parameterName, sqlType, typeName); >^ > 1 error > 5 warnings > > BUILD FAILED > > C:\cygwin\home\Administrator\jboss-all\connector\build.xml:344: Compile > failed, > messages should have been provided. > > Total time: 11 minutes 35 seconds > > $ java -version > java version "1.4.0" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92) > Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) > > is anyone else seeing this in jdk1.4??? (windows XP) > > what gives? > > marcf > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
I know, i agree, but most don't :( the claim (supposedly from the spec) is that the absence of a transaction triggers a storage. If you ask it makes no sense marcf PS: can you get to compile on JDK1.4? |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Monday, April 29, 2002 12:58 PM |To: Jboss-Dev |Subject: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method? | | |Why are we storing a dirty entity when the method call is not called within |the context of a transaction (NOT_SUPPORTED, NEVER, etc...)? Seems kind of |bizarre. | |Bill | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-550362 ] TxManager trace bug
Patches item #550362, was opened at 2002-04-29 13:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=550362&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Dan Ciarniello (dciarnie) Assigned to: Nobody/Anonymous (nobody) Summary: TxManager trace bug Initial Comment: org.jboss.tm.TxManager set trace to log.isDebugEnabled () rather than log.isTraceEnabled(). The attached patch file corrects the problem. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=550362&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] build fails on connectors?
ok second time today I do a clean co (yeah the one where I nuke my repository) and I can't compile. I get compile-source-jdbc-version: compile-classes: [mkdir] Created dir: C:\cygwin\home\Administrator\jboss-all\connector\output \classes [javac] Compiling 55 source files to C:\cygwin\home\Administrator\jboss-all\ connector\output\classes C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re sour ce\adapter\jdbc\local\LocalPreparedStatement.java:42: warning: setUnicodeStream( int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated public class LocalPreparedStatement ^ C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re sour ce\adapter\jdbc\local\LocalPreparedStatement.java:529: warning: setUnicodeStream (int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated ps.setUnicodeStream(parameterIndex, stream, length); ^ C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re sour ce\adapter\jdbc\local\LocalCallableStatement.java:66: warning: getBigDecimal(int ,int) in java.sql.CallableStatement has been deprecated public class LocalCallableStatement ^ C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re sour ce\adapter\jdbc\local\LocalCallableStatement.java:66: warning: setUnicodeStream( int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated public class LocalCallableStatement ^ C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re sour ce\adapter\jdbc\local\LocalCallableStatement.java:980: warning: getBigDecimal(in t,int) in java.sql.CallableStatement has been deprecated return cs.getBigDecimal(parameterIndex, scale); ^ C:\cygwin\home\Administrator\jboss-all\connector\output\gen-src\org\jboss\re sour ce\adapter\jdbc\local\LocalCallableStatement.java:1516: cannot resolve symbol symbol : method setNull (java.lang.String,int,java.lang.String) location: interface java.sql.CallableStatement cs.setNull(parameterName, sqlType, typeName); ^ 1 error 5 warnings BUILD FAILED C:\cygwin\home\Administrator\jboss-all\connector\build.xml:344: Compile failed, messages should have been provided. Total time: 11 minutes 35 seconds $ java -version java version "1.4.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92) Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) is anyone else seeing this in jdk1.4??? (windows XP) what gives? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
Why are we storing a dirty entity when the method call is not called within the context of a transaction (NOT_SUPPORTED, NEVER, etc...)? Seems kind of bizarre. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
I sure did. My hope was to also convert to generating all the dds from xdoclet, which will generate both jaws.xml and jbosscmp-jdbc.xml from the same source. I'm not sure how stable xdoclet is today, they are doing some kind of code reorganization. Another really nice feature would be to make it so everything got set up for a particular database by setting a config option in only one place. BTW do we have any cmp tests that use "maximal" jbosscmp-jdbc.xml configuration, everything specified there? Maybe with xdoclet we could have 2 versions, one with minimal, one with maximal-xdoclet generated. thanks david jencks On 2002.04.29 14:31:12 -0400 Dain Sundstrom wrote: > Yep the main test only use JAWS. I think david was looking at getting > these tests to use JAWS and JBossCMP, but I think he got to busy. Do > you want to try to get them running under JAWS and JBossCMP? > > -dain > > Stephen Coy wrote: > > > Hi, > > > > By looking for usage of jaws.xml files, I think I've uncovered some > > holes in the test suite: > > > > [steve@ws102 src]$ find . -name jaws.xml > > ./resources/bank/META-INF/jaws.xml > > ./resources/bankiiop/META-INF/jaws.xml > > ./resources/bench/ejb/META-INF/jaws.xml > > ./resources/dbtest/META-INF/jaws.xml > > ./resources/readahead/META-INF/jaws.xml > > ./resources/testbean2/META-INF/jaws.xml > > > > These tests all exercise CMP1.1, but as far as can see (with a cursory > > look), there are no equivalent tests for CMP2.0. > > > > In particular, I think that we need a CMP2.0 version of dbtest, because > > > this is extremely useful for checking the default standardjbosscmp- > > jdbc.xml mappings with different databases. > > > > Steve Coy > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MONTREAL training June 10-12
It just pisses me off, You ask for it, we go through the pain of scheduling it and reserving rooms etc etc and not very many people sign up. If we don't get a 10 person minimum, we will have to cancel this training. That would be a shame considering training is a prerequisite for JBoss services partners and the fact that Montreal is not that far from NYC and Boston and the US Northeast in general. This is the brand new training on JBoss 2.4 (production usage) and 3.0 (development). If you are serious about JBoss you should be there. Plus I will soon be handing over the training legacy to others in JBoss Group. This may be your last chances in North America to see me live. Discount deadline is May 15. Putain de Quebecois, vous n'etes pas mieux que les francais. Dieu merci pour les allemands, les britons et les scandinaves. Eux, au moins, il font de l'open source professionelle. marcf x Marc Fleury, Ph.D President JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-550305 ] JNP TImeout
Patches item #550305, was opened at 2002-04-29 11:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=550305&group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Lucas McGregor (lmcgregor) Assigned to: Nobody/Anonymous (nobody) Summary: JNP TImeout Initial Comment: When JNP utilizes a connection or attempts to make a connection to a server, there is no timeout value as there is with RMI. Also, the Socket class used for this connection is the standard SDK java.net.Socket, which does not have a connection timeout option as of SDK1.3. An attempt to connect to a bad address can take up to 4 minutes to timeout, and 15 minutes to timeout established connections gone dead on a default install of Solaris8. So a new SocketOpener support object is used that spawns a timer thread that will timeout connections that have not been established in a period of time. So if either a jnp.connect.timeout or jnp.sotimeout value has been set in the Context.environment (usually via the jndi.properties file), this NamingContext object will use the SocketOpener to create the socket, enforce a connect timeout, and set the soTimeout. If neither value is set, then it NamingContext will save the resources and simply call the java.net.Socket constructor. This patch includes a a patch for org.jnp.interfaces.NamingContext and a new org.jnp.interfaces.SocketOpener class. Two new values can be added to the jndi.properties file: jnp.connect.timeout and jnp.sotimeout (both in ms). jnp.connect.timeout is the time the socket opener will spend attemping to make a connection before throwing an exception. jnp.sotimeout is the soTimeout value the newly created socket. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=550305&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
Yep the main test only use JAWS. I think david was looking at getting these tests to use JAWS and JBossCMP, but I think he got to busy. Do you want to try to get them running under JAWS and JBossCMP? -dain Stephen Coy wrote: > Hi, > > By looking for usage of jaws.xml files, I think I've uncovered some > holes in the test suite: > > [steve@ws102 src]$ find . -name jaws.xml > ./resources/bank/META-INF/jaws.xml > ./resources/bankiiop/META-INF/jaws.xml > ./resources/bench/ejb/META-INF/jaws.xml > ./resources/dbtest/META-INF/jaws.xml > ./resources/readahead/META-INF/jaws.xml > ./resources/testbean2/META-INF/jaws.xml > > These tests all exercise CMP1.1, but as far as can see (with a cursory > look), there are no equivalent tests for CMP2.0. > > In particular, I think that we need a CMP2.0 version of dbtest, because > this is extremely useful for checking the default standardjbosscmp- > jdbc.xml mappings with different databases. > > Steve Coy > > > ___ > 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] Performance 3.0 vs 2.4
Dan, Debugging and logging is the biggest source of load, submit a patch as this is an oversight, for the load 3.0 should in fact perform better than 2.x series, it is designed for high load in the lock policies (and I believe bill backported these?) debug and trace will be turned OFF for the final release, they are ON for the RC releases. Also what we did for the 2.x releases was to put the FINAL out and then start tuning the system for optimizations. We did that in fact in an "official" performance team it was very succesful. We are wrapping up functionality then optimizing gets in the picture. We will dedicate the "performance" forum to that, your help will be more than welcome. Once we have FINAL, unleash that OptimizeIT and do all you want. marcf PS: the marshalling we have some ideas on, a pure hack to accelerate. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan |Ciarniello |Sent: Monday, April 29, 2002 11:13 AM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Performance 3.0 vs 2.4 | | |I have been running some tests to test the performance of JBoss |3.0 versus that of JBoss 2.4 and have found that, under load, |JBoss 3.0 is considerably slower than JBoss 2.4. My initial posts |on this topic were to the DB forum but Dain Sundstrom suggested |that I post my findings here. The original posts are at | |http://www.jboss.org/forums/thread.jsp?forum=46&thread=13695 | |Since my original post I found one other problem which is not a |big contributor but is an easy fix. For some reason, in |org.jboss.tm.TxManager, the trace member is set to |log.isDebugEnabled() which returns true. This causes TxManager to |attempt to log requests. This is problematic because (a) the log |messages don't end up anywhere (at least they aren't in |server.log) and (b) unnecessary calls to |org.jboss.tm.XidImpl.toString() are made which contributes a small |but not insignificant amount to the performance problem. By |comparing to org.jboss.tm.TxCapsule, I think that trace should be |set to log.isTraceEnabled(). | |By studying the OptimizeIT snapshots a little more, I've come to |the conclusion that while the unmarshalling process seems to be |taking more time than it should, it is probably not the whole |story and there are other sources of the performance hit as well. |Unfortunately, I cannot see anything else so obvious in the |OptimizeIT output other than everything seems to take longer |especially as the server load goes up. Hopefully someone with |more familiarity with the code than I have and that has an |OptimizeIT licence that is not about to expire can take a closer |look at this issue. | |Dan. | |* * * | |View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=14367 ___ 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] Performance 3.0 vs 2.4
I have been running some tests to test the performance of JBoss 3.0 versus that of JBoss 2.4 and have found that, under load, JBoss 3.0 is considerably slower than JBoss 2.4. My initial posts on this topic were to the DB forum but Dain Sundstrom suggested that I post my findings here. The original posts are at http://www.jboss.org/forums/thread.jsp?forum=46&thread=13695 Since my original post I found one other problem which is not a big contributor but is an easy fix. For some reason, in org.jboss.tm.TxManager, the trace member is set to log.isDebugEnabled() which returns true. This causes TxManager to attempt to log requests. This is problematic because (a) the log messages don't end up anywhere (at least they aren't in server.log) and (b) unnecessary calls to org.jboss.tm.XidImpl.toString() are made which contributes a small but not insignificant amount to the performance problem. By comparing to org.jboss.tm.TxCapsule, I think that trace should be set to log.isTraceEnabled(). By studying the OptimizeIT snapshots a little more, I've come to the conclusion that while the unmarshalling process seems to be taking more time than it should, it is probably not the whole story and there are other sources of the performance hit as well. Unfortunately, I cannot see anything else so obvious in the OptimizeIT output other than everything seems to take longer especially as the server load goes up. Hopefully someone with more familiarity with the code than I have and that has an OptimizeIT licence that is not about to expire can take a closer look at this issue. Dan. * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=14367 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-549313 ] jdbc-rar/META-INF/ra.xml typo
Bugs item #549313, was opened at 2002-04-26 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=549313&group_id=22866 Category: JBossCX Group: CVS HEAD >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ricardo Arguello (pajama) Assigned to: Nobody/Anonymous (nobody) Summary: jdbc-rar/META-INF/ra.xml typo Initial Comment: In JBoss HEAD: File jboss-all/connector/src/resources/jdbc-rar/META- INF/ra.xml Says this in line 50: org.jbossresource.adapter.jdbc.JDBCDataSource Should be: org.jboss.resource.adapter.jdbc.JDBCDataSource -- >Comment By: Ricardo Arguello (pajama) Date: 2002-04-29 11:38 Message: Logged In: YES user_id=49224 Minerva pool has been deleted from CVS HEAD. This is not longer an issue. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=549313&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
Get this OFF jboss-dev and in the web forum that is there for this kind of
issue
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Michael Delamere
|Sent: Monday, April 29, 2002 8:36 AM
|To: [EMAIL PROTECTED]; Ricardo Argüello
|Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
|hosts
|
|
|Hi,
|
|Thanks for the answer.
|
|My problem was more concerned with the use of virtual hosts using the
|combination of servers mentioned in the subject line. Have you managed to
|get this working?
|
|I actually managed to get mod_jk to map my virtual host. So when
|I entered:
|http://my.host.com/examples/ I got a tomcat directory listing of the
|examples.war situated in the webtest.ear. However I didn´t manage to get
|past this point.
|
|Mod_webapp didn´t work at all.
|
|regards
|
| Michael Delamere
|
|
|
|- Original Message -
|From: "Ricardo Argüello" <[EMAIL PROTECTED]>
|To: "Michael Delamere" <[EMAIL PROTECTED]>;
|<[EMAIL PROTECTED]>
|Sent: Monday, April 29, 2002 5:02 PM
|Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
|hosts
|
|
|> I sent this last week to jboss-user:
|>
|> Finally somebody with a Visual C++ compiler provides a binary
|distribution
|for the new tomcat-connectors:
|>
|> http://www.acg-gmbh.de/mod_jk/
|> http://www.jguru.com/faq/view.jsp?EID=853905
|>
|>
|> Ricardo Argüello
|>
|>
|>
|> ___
|> JBoss-user mailing list
|> [EMAIL PROTECTED]
|> https://lists.sourceforge.net/lists/listinfo/jboss-user
|>
|> - Original Message -
|> From: "Michael Delamere" <[EMAIL PROTECTED]>
|> To: <[EMAIL PROTECTED]>
|> Sent: Monday, April 29, 2002 2:03 AM
|> Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
|hosts
|>
|>
|> sorry,
|>
|> I´ll drop the subject.
|>
|> Michael Delamere
|>
|>
|> - Original Message -
|> From: "Scott M Stark" <[EMAIL PROTECTED]>
|> To: <[EMAIL PROTECTED]>
|> Sent: Monday, April 29, 2002 12:44 AM
|> Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
|> hosts
|>
|>
|> > Your asking at the wrong time as I don't care about hooking up an
|> > external Apache server to Tomcat while Tomcat inside of JBoss
|> > works and we are in the process of getting releases out. Further,
|> > mod_webapp seems about an alpha release given all the problems
|> > on the tomcat list and I'm not debugging this connector until
|> > the final 3.0 release is out in about 2 weeks.
|> >
|> >
|> > Scott Stark
|> > Chief Technology Officer
|> > JBoss Group, LLC
|> >
|> > - Original Message -
|> > From: "Michael Delamere" <[EMAIL PROTECTED]>
|> > To: <[EMAIL PROTECTED]>
|> > Sent: Sunday, April 28, 2002 3:16 PM
|> > Subject: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
|hosts
|> >
|> >
|> > Hi,
|> >
|> > Sorry, it´s me again.
|> >
|> > I´m still trying to get virtual hosts working via apache2.0.35
|using the
|> > mod_webapp connector, jboss3.0RC1 and tomcat4.0.3.
|> >
|> > I don´t want to get on your nerves but I´ve tried just about everything
|> and
|> > I haven´t received any answers to my previous virtual host questions.
|> >
|> > The strange thing is that when using mod_jk I at least get a "tomcat"
|> > directory listing of my virtual host, however I haven´t managed to get
|any
|> > servlets running yet.
|> >
|> > When I switch to mod_webapp whilst keeping everything else the same I
|> don´t
|> > even get that.
|> > I decided to tamper a bit with the webapp code and the output tells me
|> that
|> > the context is "null"! Why? I know this might not be a jboss question
|> and
|> > more a webapp question but I´m hoping that you might be able to shed
|some
|> > light on the topic.
|> >
|> > + CODE CHANGED +++
|> > try {
|> > context=deploy(connection,logger,appl,host,path);
|> > logger.log("+++ MD_CONTEXT_OUTPUT: " + context + " +++");
|> > } catch (Exception e) {
|> > logger.log(e);
|> > }
|> >
|> > OUTPUT
|> > 00:04:50,966 ERROR [Engine]
|> > [org.apache.catalina.connector.warp.WarpConfigurationHandler] +++
|> > MD_CONTEXT_OUTPUT: null +++
|> > 00:04:50,966 ERROR [Engine]
|> > [org.apache.catalina.connector.warp.WarpConfigurationHandler]
|+++_MD_+++
|> > Error deploying web ap
|> >
|> > This must be just about my 5th posting on this subject. Maybe
|this time
|> > I´ll have more luck :-).
|> > Any hints at all would be of great help!!
|> >
|> > bye Michael Delamere
|> >
|> >
|> > ___
|> > 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-d
[JBoss-dev] Why don't tests run twice? (3.0 cvs)
I'm starting to look into why so many tests fail if you run the tests twice. I'm looking for the cause of 2002-04-29 01:08:00,408 ERROR [STDERR] java.sql.SQLException: ResourceException javax.resource.ResourceException: No matching credentials in Subject! 2002-04-29 01:08:00,410 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:105) So far my guesses about what is causing the login module and managedconnectionfactory to get out of synch with each other have been wrong. If you figure out which test is causing this problem to start or anything else about the cause I'd like to know. Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
Hi,
Thanks for the answer.
My problem was more concerned with the use of virtual hosts using the
combination of servers mentioned in the subject line. Have you managed to
get this working?
I actually managed to get mod_jk to map my virtual host. So when I entered:
http://my.host.com/examples/ I got a tomcat directory listing of the
examples.war situated in the webtest.ear. However I didn´t manage to get
past this point.
Mod_webapp didn´t work at all.
regards
Michael Delamere
- Original Message -
From: "Ricardo Argüello" <[EMAIL PROTECTED]>
To: "Michael Delamere" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, April 29, 2002 5:02 PM
Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
hosts
> I sent this last week to jboss-user:
>
> Finally somebody with a Visual C++ compiler provides a binary distribution
for the new tomcat-connectors:
>
> http://www.acg-gmbh.de/mod_jk/
> http://www.jguru.com/faq/view.jsp?EID=853905
>
>
> Ricardo Argüello
>
>
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
>
> - Original Message -
> From: "Michael Delamere" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, April 29, 2002 2:03 AM
> Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
hosts
>
>
> sorry,
>
> I´ll drop the subject.
>
> Michael Delamere
>
>
> - Original Message -
> From: "Scott M Stark" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, April 29, 2002 12:44 AM
> Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
> hosts
>
>
> > Your asking at the wrong time as I don't care about hooking up an
> > external Apache server to Tomcat while Tomcat inside of JBoss
> > works and we are in the process of getting releases out. Further,
> > mod_webapp seems about an alpha release given all the problems
> > on the tomcat list and I'm not debugging this connector until
> > the final 3.0 release is out in about 2 weeks.
> >
> >
> > Scott Stark
> > Chief Technology Officer
> > JBoss Group, LLC
> >
> > - Original Message -
> > From: "Michael Delamere" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, April 28, 2002 3:16 PM
> > Subject: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
hosts
> >
> >
> > Hi,
> >
> > Sorry, it´s me again.
> >
> > I´m still trying to get virtual hosts working via apache2.0.35 using the
> > mod_webapp connector, jboss3.0RC1 and tomcat4.0.3.
> >
> > I don´t want to get on your nerves but I´ve tried just about everything
> and
> > I haven´t received any answers to my previous virtual host questions.
> >
> > The strange thing is that when using mod_jk I at least get a "tomcat"
> > directory listing of my virtual host, however I haven´t managed to get
any
> > servlets running yet.
> >
> > When I switch to mod_webapp whilst keeping everything else the same I
> don´t
> > even get that.
> > I decided to tamper a bit with the webapp code and the output tells me
> that
> > the context is "null"! Why? I know this might not be a jboss question
> and
> > more a webapp question but I´m hoping that you might be able to shed
some
> > light on the topic.
> >
> > + CODE CHANGED +++
> > try {
> > context=deploy(connection,logger,appl,host,path);
> > logger.log("+++ MD_CONTEXT_OUTPUT: " + context + " +++");
> > } catch (Exception e) {
> > logger.log(e);
> > }
> >
> > OUTPUT
> > 00:04:50,966 ERROR [Engine]
> > [org.apache.catalina.connector.warp.WarpConfigurationHandler] +++
> > MD_CONTEXT_OUTPUT: null +++
> > 00:04:50,966 ERROR [Engine]
> > [org.apache.catalina.connector.warp.WarpConfigurationHandler] +++_MD_+++
> > Error deploying web ap
> >
> > This must be just about my 5th posting on this subject. Maybe this time
> > I´ll have more luck :-).
> > Any hints at all would be of great help!!
> >
> > bye Michael Delamere
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-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] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
I sent this last week to jboss-user:
Finally somebody with a Visual C++ compiler provides a binary distribution for the new
tomcat-connectors:
http://www.acg-gmbh.de/mod_jk/
http://www.jguru.com/faq/view.jsp?EID=853905
Ricardo Argüello
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
- Original Message -
From: "Michael Delamere" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 29, 2002 2:03 AM
Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
sorry,
I´ll drop the subject.
Michael Delamere
- Original Message -
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 29, 2002 12:44 AM
Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
hosts
> Your asking at the wrong time as I don't care about hooking up an
> external Apache server to Tomcat while Tomcat inside of JBoss
> works and we are in the process of getting releases out. Further,
> mod_webapp seems about an alpha release given all the problems
> on the tomcat list and I'm not debugging this connector until
> the final 3.0 release is out in about 2 weeks.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> - Original Message -
> From: "Michael Delamere" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, April 28, 2002 3:16 PM
> Subject: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
>
>
> Hi,
>
> Sorry, it´s me again.
>
> I´m still trying to get virtual hosts working via apache2.0.35 using the
> mod_webapp connector, jboss3.0RC1 and tomcat4.0.3.
>
> I don´t want to get on your nerves but I´ve tried just about everything
and
> I haven´t received any answers to my previous virtual host questions.
>
> The strange thing is that when using mod_jk I at least get a "tomcat"
> directory listing of my virtual host, however I haven´t managed to get any
> servlets running yet.
>
> When I switch to mod_webapp whilst keeping everything else the same I
don´t
> even get that.
> I decided to tamper a bit with the webapp code and the output tells me
that
> the context is "null"! Why? I know this might not be a jboss question
and
> more a webapp question but I´m hoping that you might be able to shed some
> light on the topic.
>
> + CODE CHANGED +++
> try {
> context=deploy(connection,logger,appl,host,path);
> logger.log("+++ MD_CONTEXT_OUTPUT: " + context + " +++");
> } catch (Exception e) {
> logger.log(e);
> }
>
> OUTPUT
> 00:04:50,966 ERROR [Engine]
> [org.apache.catalina.connector.warp.WarpConfigurationHandler] +++
> MD_CONTEXT_OUTPUT: null +++
> 00:04:50,966 ERROR [Engine]
> [org.apache.catalina.connector.warp.WarpConfigurationHandler] +++_MD_+++
> Error deploying web ap
>
> This must be just about my 5th posting on this subject. Maybe this time
> I´ll have more luck :-).
> Any hints at all would be of great help!!
>
> bye Michael Delamere
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS HEAD in danger
Fucking chill! I merged then committed. Everything is fine. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > Dillon > Sent: Monday, April 29, 2002 3:28 AM > To: Bill Burke > Cc: Jboss-Dev > Subject: Re: [JBoss-dev] CVS HEAD in danger > > > WHAT!!!?? This is not cool... I am still early into reading 300+ > messages for > today... one of which I think you posted saying things are cool... BUT > > It is not cool to not update your workspace before committing. > Marc has done > this before and it just ends up in lost work... some of my > work... minor and > easy to fix, but a royal pain in the ass. We have a version > control system to > avoid problems like this. > > True CVS is crap when it comes to merging, but this can be minimized by > disabling keyword subst and isolating your updates & checking for merge > conflicts. > > Committing in a fashion where it losses potential fixes, enhancements or > documentation is a very, very, very, VERY bad idea. > > Please don't... take the time and deal with the merges. Please. > > --jason > > > Quoting Bill Burke <[EMAIL PROTECTED]>: > > > I'll be doing some major commits in a few hours. I haven't merged from > > mainline in about 1.5 weeks so I may kill commits that have been done in > > that timespan. Sorry for the problems... > > > > Bill > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ > 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] Multi invokers per container committed
Whoops! Did look to see if HA-SFSB had specific container interceptors. Is that the only one? I'll put it back. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha > Labourey > Sent: Monday, April 29, 2002 4:37 AM > To: Bill Burke; Jboss-Dev > Subject: RE: [JBoss-dev] Multi invokers per container committed > > > Excellent work Bill! > > I will take a look at the code later, but in the meantime there > is something I haven't seen. You say that clustering-specific > config have been removed from standard-jboss.xml. So, where are > defined the default stack config for clustering? For example, for > HA-SFSB, we need to have some specific interceptors. Where are > they defined now? > > Thanks. Cheers, > > > > Sacha > > > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de Bill > > Burke > > Envoyé : lundi, 29 avril 2002 02:14 > > À : Jboss-Dev > > Objet : [JBoss-dev] Multi invokers per container committed > > > > > > JBoss 3.1 (CVS-HEAD) now has the ability to bind multiple > invokers per EJB > > container. This means that one EJB container can serve up requests from > > IIOP, RMI, SOAP, all at the same time. > Also, if your > > EJBs are configured correctly in jboss.xml Beans accessed through bean > > ejb-refs will automatically and transparently use the correct protocol. > > Meaning, if you start off on IIOP, you'll stay on IIOP (unless > the call is > > colocated). > > > > There have been some fundamental changes to configuration: > > 1. no longer has client-interceptors defined > > within it. A new invoker to proxy factory binding has the > > client-interceptor definitions for each proxyfactory/invoker > > binding combo. > > 2. Also, configuration tag has been removed from > > . > > 3. jdk1.2.2 support has been removed from standardjboss.xml > > 4. THere are no more Clustered definitions in > > standardjboss.xml. They're no longer needed > > > ___ > 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] Multi invokers per container committed
> > Whoops! Did look to see if HA-SFSB had specific container > interceptors. Is > that the only one? I'll put it back. > what you just did is TERRIFIC! ;) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] getting jboss from cvs
Hello Sean, Please, use the online forums @ http://www.jboss.org/forums/ For your particular problem, see http://www.jboss.org/developers/cvs.jsp Cheers, Sacha > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > [EMAIL PROTECTED] > Envoyé : lundi, 29 avril 2002 12:29 > À : [EMAIL PROTECTED] > Objet : [JBoss-dev] getting jboss from cvs > > > I was wondering if someone could give me a few pointers on getting jboss > source from cvs. > I've downloaded tortoise cvs, but on browsing the cvs tree from the > sourceforge home page i got a bit lost. > I'm looking for the lastest jboss version with jetty, but can figure out > what to download. > > Thanks > > ___ > Sean O'Donnell > > Sentia Technologies Ltd. > Sentia House > 104 Coolmine Business Park > Dublin 15 Ireland > > e-mail[EMAIL PROTECTED] > web http://www.sentia.ie > phone + 353 1 821 9020 > fax + 353 1 821 9025 > mobile+ 353 86 854 3389 > > > ___ > 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] [ jboss-Bugs-547160 ] ClassCastException
Bugs item #547160, was opened at 2002-04-22 18:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547160&group_id=22866 Category: CatalinaBundle Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matthias Damsch (damschm) Assigned to: Scott M Stark (starksm) Summary: ClassCastException Initial Comment: I am using the JBoss 2.4.4 / Tomcat 4.0.1 bundle from the jboss homepage. Our application is using a servlet (MyServlet in the sample code) which instantiates some stateful sessionbeans (X in the sample code) which implements a interface (Base in the sample code). If we try to cast the bean to this interface we receive a 'ClassCastException'. Normally we add the class-file of the interface 'Base' to both, the ejb-jar and the war file. If we do so, the exception will be thrown. If we put the class file to the ejb-jar file only, this application works fine. Because this preventing us to run the servlet in an other VM than the session bean this is not really a workaround. I attach a zip file which contains sources and a ant build.xml file, which should help you to reproduce the problem. The doPost method of the MyServlet class contained in the attached zip file, implements two approaches which will fail. Depending on the approach that is used either java.lang.ClassCastException or java.lang.IncompatibleClassChangeError will be thrown. I tried the same application using the JBoss 2.4.3 / Tomcat 3.2.3 bundle and this works fine. The JBoss Server is running on a Windows NT4 Box with Sun JDK 1.3.1 installed. -- >Comment By: Matthias Damsch (damschm) Date: 2002-04-29 12:29 Message: Logged In: YES user_id=522793 scott, could you explain your note more in detail. As far as I know the servlet 2.3 specification changed the class loading model only to prevent servlets to load server classes. But how is that related to this problem and what could we do to get our code running ? -- Comment By: Scott M Stark (starksm) Date: 2002-04-28 00:08 Message: Logged In: YES user_id=175228 This is due to the servlet 2.3 class loading model loading from the war before its parent class loader. This behavior has been disabled by default. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=547160&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] getting jboss from cvs
I was wondering if someone could give me a few pointers on getting jboss source from cvs. I've downloaded tortoise cvs, but on browsing the cvs tree from the sourceforge home page i got a bit lost. I'm looking for the lastest jboss version with jetty, but can figure out what to download. Thanks ___ Sean O'Donnell Sentia Technologies Ltd. Sentia House 104 Coolmine Business Park Dublin 15 Ireland e-mail [EMAIL PROTECTED] web http://www.sentia.ie phone + 353 1 821 9020 fax + 353 1 821 9025 mobile + 353 86 854 3389 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Multi invokers per container committed
Excellent work Bill! I will take a look at the code later, but in the meantime there is something I haven't seen. You say that clustering-specific config have been removed from standard-jboss.xml. So, where are defined the default stack config for clustering? For example, for HA-SFSB, we need to have some specific interceptors. Where are they defined now? Thanks. Cheers, Sacha > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de Bill > Burke > Envoyé : lundi, 29 avril 2002 02:14 > À : Jboss-Dev > Objet : [JBoss-dev] Multi invokers per container committed > > > JBoss 3.1 (CVS-HEAD) now has the ability to bind multiple invokers per EJB > container. This means that one EJB container can serve up requests from > IIOP, RMI, SOAP, all at the same time. Also, if your > EJBs are configured correctly in jboss.xml Beans accessed through bean > ejb-refs will automatically and transparently use the correct protocol. > Meaning, if you start off on IIOP, you'll stay on IIOP (unless the call is > colocated). > > There have been some fundamental changes to configuration: > 1. no longer has client-interceptors defined > within it. A new invoker to proxy factory binding has the > client-interceptor definitions for each proxyfactory/invoker > binding combo. > 2. Also, configuration tag has been removed from > . > 3. jdk1.2.2 support has been removed from standardjboss.xml > 4. THere are no more Clustered definitions in > standardjboss.xml. They're no longer needed ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CMP2.0 test case coverage
Hi, By looking for usage of jaws.xml files, I think I've uncovered some holes in the test suite: [steve@ws102 src]$ find . -name jaws.xml ./resources/bank/META-INF/jaws.xml ./resources/bankiiop/META-INF/jaws.xml ./resources/bench/ejb/META-INF/jaws.xml ./resources/dbtest/META-INF/jaws.xml ./resources/readahead/META-INF/jaws.xml ./resources/testbean2/META-INF/jaws.xml These tests all exercise CMP1.1, but as far as can see (with a cursory look), there are no equivalent tests for CMP2.0. In particular, I think that we need a CMP2.0 version of dbtest, because this is extremely useful for checking the default standardjbosscmp- jdbc.xml mappings with different databases. Steve Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
> 2 solutions. > 1- I build a mapper that takes String and returns ObjectName > 2- you build a ObjectName implementation that caches the ObjectName and > returns the right Object if you pass me exactly the same String. OK, but it must be a requirement that this mapping be deterministic i.e. when you bind a bean (=> container => mbean) in a JBoss instance, we will use your "cache MBEAN" with a key that is a simple string. But this key must be identical for all deployments of the same bean because our clustered proxy will use the same key while making invocation on any nodes. Just to be sure you don't use some kind of counter as the key you give back to the proxy. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] thoughts on speeding up the invocation in 3.0
> This > would of course break all custom interceptor stuff (where you > actually pass > data back and forth) but would enable a "cheat mode" for all If I remember well, we can only attach generic data when sending data to the server, but not receiving FROM the server. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
sorry,
I´ll drop the subject.
Michael Delamere
- Original Message -
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 29, 2002 12:44 AM
Subject: Re: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual
hosts
> Your asking at the wrong time as I don't care about hooking up an
> external Apache server to Tomcat while Tomcat inside of JBoss
> works and we are in the process of getting releases out. Further,
> mod_webapp seems about an alpha release given all the problems
> on the tomcat list and I'm not debugging this connector until
> the final 3.0 release is out in about 2 weeks.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> - Original Message -
> From: "Michael Delamere" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, April 28, 2002 3:16 PM
> Subject: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
>
>
> Hi,
>
> Sorry, it´s me again.
>
> I´m still trying to get virtual hosts working via apache2.0.35 using the
> mod_webapp connector, jboss3.0RC1 and tomcat4.0.3.
>
> I don´t want to get on your nerves but I´ve tried just about everything
and
> I haven´t received any answers to my previous virtual host questions.
>
> The strange thing is that when using mod_jk I at least get a "tomcat"
> directory listing of my virtual host, however I haven´t managed to get any
> servlets running yet.
>
> When I switch to mod_webapp whilst keeping everything else the same I
don´t
> even get that.
> I decided to tamper a bit with the webapp code and the output tells me
that
> the context is "null"! Why? I know this might not be a jboss question
and
> more a webapp question but I´m hoping that you might be able to shed some
> light on the topic.
>
> + CODE CHANGED +++
> try {
> context=deploy(connection,logger,appl,host,path);
> logger.log("+++ MD_CONTEXT_OUTPUT: " + context + " +++");
> } catch (Exception e) {
> logger.log(e);
> }
>
> OUTPUT
> 00:04:50,966 ERROR [Engine]
> [org.apache.catalina.connector.warp.WarpConfigurationHandler] +++
> MD_CONTEXT_OUTPUT: null +++
> 00:04:50,966 ERROR [Engine]
> [org.apache.catalina.connector.warp.WarpConfigurationHandler] +++_MD_+++
> Error deploying web ap
>
> This must be just about my 5th posting on this subject. Maybe this time
> I´ll have more luck :-).
> Any hints at all would be of great help!!
>
> bye Michael Delamere
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS HEAD in danger
WHAT!!!?? This is not cool... I am still early into reading 300+ messages for today... one of which I think you posted saying things are cool... BUT It is not cool to not update your workspace before committing. Marc has done this before and it just ends up in lost work... some of my work... minor and easy to fix, but a royal pain in the ass. We have a version control system to avoid problems like this. True CVS is crap when it comes to merging, but this can be minimized by disabling keyword subst and isolating your updates & checking for merge conflicts. Committing in a fashion where it losses potential fixes, enhancements or documentation is a very, very, very, VERY bad idea. Please don't... take the time and deal with the merges. Please. --jason Quoting Bill Burke <[EMAIL PROTECTED]>: > I'll be doing some major commits in a few hours. I haven't merged from > mainline in about 1.5 weeks so I may kill commits that have been done in > that timespan. Sorry for the problems... > > Bill > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
