[JBoss-dev] [ jboss-Bugs-638804 ] Invalid JDBC type mapping for MSSQL 2000
Bugs item #638804, was opened at 2002-11-15 09:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638804&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid JDBC type mapping for MSSQL 2000 Initial Comment: in 3.0.4 java.lang.Ojbect mapping for MS SQLSERVER2000 is set to JAVA_OBJECT. This is unacceptable by both JDBC drivers I have (from MS and from Tyrex). i.e. setNull (index, Types.JAVA_OBJECT) raises SQLException "unsupported data type". In contrast, LONGVARBINARY works excellent for both setNull() and setBinaryStream() and for both drivers. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638804&group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
> > scenario. The PooledInvoker is 300% faster than the default > > RMI Invoker. > > > > 2nd scenario: > > invokor is 30% faster than the default RMI based invoker. > > > P.S. This code is extremely more simple than the Trunk > > Invoker and I've been told that the Trunk Invoker provides no > > performance boost. > > Plus the name sucks. Let's stir clear of 'cute names', PooledInvoker > clearly describes what it is. > Yes the 'trunk' name sucks.. Maybe you can help me give it a better name. here are the things it does: - bi-directional invocations. client can invoke the server, server can invoke the client. - Thread pooling (same as the PooledInvoker). - Connection sharing. Multiple invocations can be sent to the server at the same time. Sending an invocation down the socket does not stop other invocation from going down the pipe. - Uses NIO if running under java 1.4, normal blocking IO if on 1.3 My performance testing did not show it was better than RMI. Perhaps I was running a bad test, perhaps I need to add connection pooling so that more than one socket is established from the client to the server. Perhaps all this functionality is just adding too much overhead. Anyways. JMS need bi-directional invocations (BADLY). Should this become a requirement for the other invokers?? Regards, Hiram --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.net email transport
> The cool thing about a signed secure e-mail message is that you get > non-repudiation. If at a later time company B tells company A, hey I never > sent you a Purchase Order for 1 million widgets.. company A can show them > the signed secure e-mail message that they received the PO in. It would be > harder to do something like that over http. Thats not non-repudiation (or at least my understanding of it). Non-repudiation also provides for company B knowing that company A received it so that if company B doesn't fill the PO company A can say "I know you received it". nonetheless signed soap messages do (in theory) fill that hole in SOAP/SMTP ... cheers dim > > Regards, > Hiram > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt > > Munz > > Sent: Thursday, November 14, 2002 10:55 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] jboss.net email transport > > > > > > Jason, > > > > Well, you've peaked my interest... > > > > > This method(with digital signatures/encryption) would be more secure > > > than the Http(s) transport, > > > > Really? Any articles on the subject? > > > > > Authentication would be near definite > > > (rather hard to fake), > > > > Is there something in the mail protocol that facilitates this? > > I'd love to > > see a strong argument for "email is more secure than https"... > > > > > the server would not be exposed to the big bad > > > internet, > > > > Hmmm. Email attacks are fairly common. Email is, by definition, > > a part of > > the internet. I'm not sure where you're going with this... > > > > > and the company's IT guys don't have to set up a VPN to every > > > outside source that needs to update data in the server. > > > > VPNs are bad ;) What's wrong with the tried and true "poking a > > hole in the > > firewall" technique? What about https? > > > > Is the idea that "they have to have email anyway, so let's just > > tunnel over > > that"? Wasn't this same argument used for HTTP tunnelling? > > > > - Matt > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jason > > Essington > > Sent: Thursday, November 14, 2002 10:33 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] jboss.net email transport > > > > > > Hi Matt, > > > > Given an instance where a company would place a server on its intranet > > (behind a firewall that does not allow incoming connections from the > > internet). > > > > Now, If this company wanted to receive periodic updates to some > > semi-static data (iso country codes for instance) from a source on the > > internet. This source would need a VPN to get through the companies > > firewall (major hassle if this source has to update many servers, or if > > the company needs data updated from many different sources) or it could > > send a Signed and possibly Encrypted email to a mail account the > > company has set up for the server. The server checks it's email at a > > configured interval and processes any soap messages it finds there. The > > digital signature is used for message verification and authentication, > > while encryption could be used to protect sensitive parts of the > > message. The message is processed and it's response (or fault) is > > returned to the original sender via the mail server. > > > > This method(with digital signatures/encryption) would be more secure > > than the Http(s) transport, Authentication would be near definite > > (rather hard to fake), the server would not be exposed to the big bad > > internet, and the company's IT guys don't have to set up a VPN to every > > outside source that needs to update data in the server. > > > > All in all, and email transport with digital signatures and encryption > > has quite a bit of promise as a secure way to allow data to pass > > through/around a firewall without too much extra hassle. There would > > need to be a mechanism for key exchange, but no work on the part of IT. > > > > -jason > > > > On Thursday, November 14, 2002, at 07:21 AM, Matt Munz wrote: > > > > > Jason, > > > > > > Just out of curiosity, what would you use this for? > > > > > > - Matt > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > > > Jason > > > Essington > > > Sent: Wednesday, November 13, 2002 5:48 PM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] jboss.net email transport > > > > > > > > > Hi all > > > > > > I have managed to get a fairly crude email transport working in > > > jboss.net (It is lurking in head). I would appreciate any comments / > > > design ideas from folks who are interested. > > > > > > Check the javadocs in org.jboss.net.axis.mail.MailTransportService to > > > see how to set it up. > > > > > > It will currently process emails with simple soap messages (no > > > attachments). It req
Re: [JBoss-dev] org.jboss.test.jmx.test.DeployConnectionManagerUnitTestCase Failure
I'll take a look, probably tonight. david jencks On 2002.11.14 18:21:40 -0500 Scott M Stark wrote: > The DeployConnectionManagerUnitTestCase is failing in 3.2 with the > following NPE > > Please look into what the issue is here. > > 15:10:46,518 INFO [MainDeployer] Deployed package: > file:/C:/usr/JBoss3.2/jboss- > 3.2/testsuite/output/lib/jmxtest.jar > 15:10:46,788 INFO [JBossManagedConnectionPool] Creating > 15:10:46,788 INFO [JBossManagedConnectionPool] Created > 15:10:46,788 INFO [JBossManagedConnectionPool] Starting > 15:10:46,788 INFO [JBossManagedConnectionPool] Started > 15:10:46,788 INFO [LocalTxConnectionManager] Creating > 15:10:46,798 INFO [LocalTxConnectionManager] Created > 15:10:46,798 INFO [LocalTxConnectionManager] Starting > 15:10:46,798 ERROR [LocalTxConnectionManager] Starting failed > java.lang.NullPointerException > at >org.jboss.resource.connectionmanager.BaseConnectionManager2.startService(BaseConnectionManager2.java:396) > at >org.jboss.resource.connectionmanager.TxConnectionManager.startService(TxConnectionManager.java:243) > at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:197) > at java.lang.reflect.Method.invoke(Native Method) > at >org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at >org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:962) > at $Proxy30.start(Unknown Source) > at org.jboss.system.ServiceController.start(ServiceController.java:388) > at java.lang.reflect.Method.invoke(Native Method) > at >org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:269) > at java.lang.reflect.Method.invoke(Native Method) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) > at sun.rmi.transport.Transport$1.run(Transport.java:147) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:143) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) > at >sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) > at java.lang.Thread.run(Thread.java:479) > 15:10:46,808 WARN [ServiceController] Problem starting service > jboss.jca:name=TestDS,service=LocalTxCM > java.lang.NullPointerException > at >org.jboss.resource.connectionmanager.BaseConnectionManager2.startService(BaseConnectionManager2.java:396) > at >org.jboss.resource.connectionmanager.TxConnectionManager.startService(TxConnectionManager.java:243) > at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:197) > at java.lang.reflect.Method.invoke(Native Method) > at >org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at >org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:962) > at $Proxy30.start(Unknown Source) > at org.jboss.system.ServiceController.start(ServiceController.java:388) > at java.lang.reflect.Method.invoke(Native Method) > at >org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) > at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:269) > at java.lang.reflect.Method.invoke(Native Method) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) > at sun.rmi.transport.Transport$1.run(Transport.java:147) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:143) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) > at >sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) > at java.lang.Thread.run(Thread.java:479) > > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > --- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ---
Re: [JBoss-dev] jboss.net email transport
So send a signed HTTP post over SSL. A digital sig is a digital sig whether by email or post. The only advantange email has is that the clients are better setup to manage the keys and perform the signing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Hiram Chirino" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 4:19 PM Subject: RE: [JBoss-dev] jboss.net email transport > The cool thing about a signed secure e-mail message is that you get > non-repudiation. If at a later time company B tells company A, hey I never > sent you a Purchase Order for 1 million widgets.. company A can show them > the signed secure e-mail message that they received the PO in. It would be > harder to do something like that over http. > > Regards, > Hiram > --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Eclipse deployer
I use Eclipse and jboss quite a bit. I am really interested in the deployer. Could you please send out an email whenever you post your patches on the sf site. thanks prabhakar Few months ago I wrote special deployer that knows structure of eclipse workspace and is able to deploy ejb's directly from eclipse's workspace without need to package them first. My boss does not mind making code >available to public and I wonder if this is something that can/should be put into JBoss cvs repository. Any advice? --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 14-November-2002
Number of tests run: 995 Successful tests: 987 Errors:8 Failures: 0 [time of test: 2002-11-14.17-59 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.1] See http://users.jboss.org/~starksm/Branch_3_0/2002-11-14.17-59 for details of this test. 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! --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.net email transport
The cool thing about a signed secure e-mail message is that you get non-repudiation. If at a later time company B tells company A, hey I never sent you a Purchase Order for 1 million widgets.. company A can show them the signed secure e-mail message that they received the PO in. It would be harder to do something like that over http. Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt > Munz > Sent: Thursday, November 14, 2002 10:55 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] jboss.net email transport > > > Jason, > > Well, you've peaked my interest... > > > This method(with digital signatures/encryption) would be more secure > > than the Http(s) transport, > > Really? Any articles on the subject? > > > Authentication would be near definite > > (rather hard to fake), > > Is there something in the mail protocol that facilitates this? > I'd love to > see a strong argument for "email is more secure than https"... > > > the server would not be exposed to the big bad > > internet, > > Hmmm. Email attacks are fairly common. Email is, by definition, > a part of > the internet. I'm not sure where you're going with this... > > > and the company's IT guys don't have to set up a VPN to every > > outside source that needs to update data in the server. > > VPNs are bad ;) What's wrong with the tried and true "poking a > hole in the > firewall" technique? What about https? > > Is the idea that "they have to have email anyway, so let's just > tunnel over > that"? Wasn't this same argument used for HTTP tunnelling? > > - Matt > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jason > Essington > Sent: Thursday, November 14, 2002 10:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] jboss.net email transport > > > Hi Matt, > > Given an instance where a company would place a server on its intranet > (behind a firewall that does not allow incoming connections from the > internet). > > Now, If this company wanted to receive periodic updates to some > semi-static data (iso country codes for instance) from a source on the > internet. This source would need a VPN to get through the companies > firewall (major hassle if this source has to update many servers, or if > the company needs data updated from many different sources) or it could > send a Signed and possibly Encrypted email to a mail account the > company has set up for the server. The server checks it's email at a > configured interval and processes any soap messages it finds there. The > digital signature is used for message verification and authentication, > while encryption could be used to protect sensitive parts of the > message. The message is processed and it's response (or fault) is > returned to the original sender via the mail server. > > This method(with digital signatures/encryption) would be more secure > than the Http(s) transport, Authentication would be near definite > (rather hard to fake), the server would not be exposed to the big bad > internet, and the company's IT guys don't have to set up a VPN to every > outside source that needs to update data in the server. > > All in all, and email transport with digital signatures and encryption > has quite a bit of promise as a secure way to allow data to pass > through/around a firewall without too much extra hassle. There would > need to be a mechanism for key exchange, but no work on the part of IT. > > -jason > > On Thursday, November 14, 2002, at 07:21 AM, Matt Munz wrote: > > > Jason, > > > > Just out of curiosity, what would you use this for? > > > > - Matt > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > > Jason > > Essington > > Sent: Wednesday, November 13, 2002 5:48 PM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] jboss.net email transport > > > > > > Hi all > > > > I have managed to get a fairly crude email transport working in > > jboss.net (It is lurking in head). I would appreciate any comments / > > design ideas from folks who are interested. > > > > Check the javadocs in org.jboss.net.axis.mail.MailTransportService to > > see how to set it up. > > > > It will currently process emails with simple soap messages (no > > attachments). It requires the content type to be application/soap+xml > > with the action attribute set to the desired service. > > > > i.e. content-type: application/soap+xml; action=SomeService > > > > The response message is returned to the sender via email. > > > > Since email doesn't really have any type of authentication framework > > the transport will only work with ejb's / ejb methods's that have > > unchecked permissions. > > > > I have been able to sign (DSA) a soap message using apache's > > xml-security library and have jboss.net verify the signature (I haven't > > submit
Re: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 14-November-2002
These results are now available on our website Look into the errors that may be in your areas and try to address them for the beta2 release early next week. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 8:57 PM Subject: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 14-November-2002 > > Number of tests run: 1028 > > > > Successful tests: 1002 > Errors:23 > Failures: 3 > > > > [time of test: 2002-11-15.04-28 GMT] > [java.version: 1.3.1_05] > [java.vendor: Sun Microsystems Inc.] > [java.vm.version: 1.3.1_05-b02] > [java.vm.name: Java HotSpot(TM) Client VM] > [java.vm.info: mixed mode] > [os.name: Windows 2000] > [os.arch: x86] > [os.version: 5.0] > > Useful resources: > > - http://bliss.jboss.org/~starksm/Branch_3_2/2002-11-15.04-28 for the junit report >of this test. > - http://bliss.jboss.org/~starksm/Branch_3_2/2002-11-15.04-28/logs/ for the logs for >this test. > > 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! > > > > > --- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 14-November-2002
Number of tests run: 1028 Successful tests: 1002 Errors:23 Failures: 3 [time of test: 2002-11-15.04-28 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://bliss.jboss.org/~starksm/Branch_3_2/2002-11-15.04-28 for the junit report of this test. - http://bliss.jboss.org/~starksm/Branch_3_2/2002-11-15.04-28/logs/ for the logs for this test. 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! --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new forums for development
+1 - Original Message - From: "Lennart Petersson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 12, 2002 11:56 PM Subject: Re: [JBoss-dev] new forums for development > Looks good. Any news about nntp gateway? > > /Love mail and news - hate browsers :) > > tisdagen den 12 november 2002 kl 18.27 skrev marc fleury: > > > Guys, > > > > I just created a bunch of forums in the development forums. > > > --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CMP on JBoss
Please, share the vision. I would like to contribute here but don't know where to start as it seems everything might be changing. Jeremy -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of marc fleury Sent: Thursday, November 14, 2002 12:28 PM To: 'Dain Sundstrom' Cc: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] CMP on JBoss please dain, take the new development of the CMP on JBoss online. If there is a rewrite, put it online, share the docs for the design, let us know how you want the site to look and feel and we will do it. Explore new grounds of collaborative development marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.test.cmp2.lob.LOBUnitTestCase Failures
This is one of my tests, which was working a few of weeks ago when I checked it in. I'll look into it tonight (ie. in about ten hours time) and try and figure out what has happened to it. Have any of the other cmp2 tests been changed recently? Steve Coy On Friday, November 15, 2002, at 09:50 AM, Scott M Stark wrote: What are all of these org.jboss.test.cmp2.lob.LOBUnitTestCase failures I see in the 3.2 branch? Everyone is an NPE like the following: null; nested exception is: java.lang.NullPointerException javax.transaction.TransactionRolledbackException: null; nested exception is: java.lang.NullPointerException java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createBeanClassInstance (JDBCStoreManager.java:513) at org.jboss.ejb.plugins.CMPPersistenceManager.createBeanClassInstance(CMP PersistenceManager.java:165) at org.jboss.ejb.EntityContainer.createBeanClassInstance(EntityContainer.j ava:272) at org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.jav a:197) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstan ceInterceptor.java:78) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterc eptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreati onInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterc eptor.java:112) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercepto rCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java :71) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityIntercepto r.java:105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:131 ) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFac toryFinderInterceptor.java:125) at org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:475) at org.jboss.ejb.Container.invoke(Container.java:701) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1026) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:100) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java: 88) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.ja va:77) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:175) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:82) at $Proxy106.create(Unknown Source) at org.jboss.test.cmp2.lob.LOBUnitTestCase.testCreate0(LOBUnitTestCase.jav a:92) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:166) at junit.framework.TestCase.runBare(TestCase.java:140) at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133) at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBea n.java:102) at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:4 4) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Sta telessSessionContainer.java:606) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterc eptor.java:108) at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInt erceptorBMT.java:144) at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Statel essSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.ja va:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:206) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactory FinderInterceptor.java:154) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContaine r.java:303) at org.jboss.ejb.Container.invoke(Container.java:680) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:34 0) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460 ) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.j ava:701) at java.lang.Thread.run(Thread.java:479) Scott Stark Chief Technology Officer JBoss Group, LLC ---
[JBoss-dev] org.jboss.test.jmx.test.DeployConnectionManagerUnitTestCase Failure
The DeployConnectionManagerUnitTestCase is failing in 3.2 with the following NPE Please look into what the issue is here. 15:10:46,518 INFO [MainDeployer] Deployed package: file:/C:/usr/JBoss3.2/jboss- 3.2/testsuite/output/lib/jmxtest.jar 15:10:46,788 INFO [JBossManagedConnectionPool] Creating 15:10:46,788 INFO [JBossManagedConnectionPool] Created 15:10:46,788 INFO [JBossManagedConnectionPool] Starting 15:10:46,788 INFO [JBossManagedConnectionPool] Started 15:10:46,788 INFO [LocalTxConnectionManager] Creating 15:10:46,798 INFO [LocalTxConnectionManager] Created 15:10:46,798 INFO [LocalTxConnectionManager] Starting 15:10:46,798 ERROR [LocalTxConnectionManager] Starting failed java.lang.NullPointerException at org.jboss.resource.connectionmanager.BaseConnectionManager2.startService(BaseConnectionManager2.java:396) at org.jboss.resource.connectionmanager.TxConnectionManager.startService(TxConnectionManager.java:243) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:197) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:962) at $Proxy30.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:388) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:269) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) 15:10:46,808 WARN [ServiceController] Problem starting service jboss.jca:name=TestDS,service=LocalTxCM java.lang.NullPointerException at org.jboss.resource.connectionmanager.BaseConnectionManager2.startService(BaseConnectionManager2.java:396) at org.jboss.resource.connectionmanager.TxConnectionManager.startService(TxConnectionManager.java:243) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:197) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:962) at $Proxy30.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:388) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:269) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Metadata Service
Dain Sundstrom wrote: > Bill Burke wrote: > > IMHO, JMX is limiting. MBeans are declarations of object instances. > > standardjboss.xml, standardcmp-jdbc.xml, the new aspect configs, > > etc... are templates/defaultconfigs for object > > creations/instantiations. A major difference. > > > > Sometimes config is just config and there's really no object you can > > attach it to. > > This is one of the big problems I see with Jboss today. Jorg came to me > a few months ago and said I want to use a database for the cmp mapping > info... a data dictionary and I had to say can't be done. We need the > physical storage abstracted away from the server use. We need metadata > to be more configurable at runtime. What about using JNDI as the storage abstraction for attributes ? Naming services are pretty good ( and desgined for this kind of stuff ), instant integration with LDAP and similar services, there is already a lot of code, etc. I'm trying a similar thing for tomcat - I would be very interested to hear your opinions. Costin --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] error trying to run iiop tests
I've tried to run iiop tests (in 3.0.5rc1 and 3.2beta2) through the command: ./build.sh -Dtest=org.jboss.test.helloiiop.test.HelloTimingStressTestCase one-test but it down't work, just get a classcast exception. i started with all conf -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-638724 ] LdapLoginModule not support MS ActiveDir
Bugs item #638724, was opened at 2002-11-14 14:59
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638724&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Shoup (rshoup)
Assigned to: Nobody/Anonymous (nobody)
Summary: LdapLoginModule not support MS ActiveDir
Initial Comment:
OS: Windows2000
JDK: 1.4
LdapLoginModule in JBoss 3.0.3 does not have sufficient
flexibility to support reading user-role information
from user-Group assignments in Microsoft ActiveDirectory.
In the user record, ActiveDirectory stores the DNs of
the Groups to which the user has been assigned.
LdapLoginModule in JBoss 3.0.3 assumes that the role
attribute of a user record would be the role name
instead of a DN to a role object.
I submitted patch #638718 which fixes this issue.
This patch adds two additional config parameters:
roleAttributeIsDN: whether role attribute is a DN or a
role name
roleNameAttributeId: the name of the role name
attribute of the role object
If `roleAttributeIsDN` is true, the patch looks up the
object corresponding to the role DN, then gets the
attribute named by `roleNameAttributeId` to provide the
role name.
For ActiveDirectory, the appropriate login-module
config settings would look like:
testLdapToActiveDirectory {
org.jboss.security.auth.spi.LdapLoginModule required
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url="ldap://ldaphost.jboss.org:1389/";
java.naming.security.authentication=simple
rolesCtxDN=cn=Users,dc=ldaphost,dc=jboss,dc=org
uidAttributeID=userPrincipalName
roleAttributeID=memberOf
roleAttributeIsDN=true
roleNameAttributeID=name
};
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638724&group_id=22866
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.test.cmp2.lob.LOBUnitTestCase Failures
What are all of these org.jboss.test.cmp2.lob.LOBUnitTestCase failures I see in the 3.2 branch? Everyone is an NPE like the following: null; nested exception is: java.lang.NullPointerException javax.transaction.TransactionRolledbackException: null; nested exception is: java.lang.NullPointerException java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createBeanClassInstance(JDBCStoreManager.java:513) at org.jboss.ejb.plugins.CMPPersistenceManager.createBeanClassInstance(CMPPersistenceManager.java:165) at org.jboss.ejb.EntityContainer.createBeanClassInstance(EntityContainer.java:272) at org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.java:197) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:78) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:112) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:71) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:131) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:125) at org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:475) at org.jboss.ejb.Container.invoke(Container.java:701) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1026) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:100) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:88) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:77) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:175) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:82) at $Proxy106.create(Unknown Source) at org.jboss.test.cmp2.lob.LOBUnitTestCase.testCreate0(LOBUnitTestCase.java:92) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:166) at junit.framework.TestCase.runBare(TestCase.java:140) at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133) at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102) at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:606) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108) at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:144) at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:206) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:303) at org.jboss.ejb.Container.invoke(Container.java:680) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:340) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-638718 ] LdapLoginModule supports ActiveDirectory
Patches item #638718, was opened at 2002-11-14 14:48
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=638718&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Shoup (rshoup)
Assigned to: Nobody/Anonymous (nobody)
Summary: LdapLoginModule supports ActiveDirectory
Initial Comment:
LdapLoginModule in JBoss 3.0.3 does not have sufficient
flexibility to support reading user-role information
from user-Group assignments in Microsoft ActiveDirectory.
In the user record, ActiveDirectory stores the DNs of
the Groups to which the user has been assigned.
LdapLoginModule in JBoss 3.0.3 assumes that the role
attribute of a user record would be the role name
instead of a DN to a role object.
This patch adds two additional config parameters:
roleAttributeIsDN: whether role attribute is a DN or a
role name
roleNameAttributeId: the name of the role name
attribute of the role object
If `roleAttributeIsDN` is true, the patch looks up the
object corresponding to the role DN, then gets the
attribute named by `roleNameAttributeId` to provide the
role name.
For ActiveDirectory, the appropriate login-module
config settings would look like:
testLdapToActiveDirectory {
org.jboss.security.auth.spi.LdapLoginModule required
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url="ldap://ldaphost.jboss.org:1389/";
java.naming.security.authentication=simple
rolesCtxDN=cn=Users,dc=ldaphost,dc=jboss,dc=org
uidAttributeID=userPrincipalName
roleAttributeID=memberOf
roleAttributeIsDN=true
roleNameAttributeID=name
};
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=638718&group_id=22866
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RMI wire protocol version 2 ?
Hi, when capturing the RMI wire protocol of the client/jboss traffic I find that the stream has a 0x0002 as version whereas the spec of the 1.4.0 I used only talks about 0x0001. Anybody out there knows a pointer to an updated spec with version 0x0002? Regards, Michael --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-636920 ] JSP INCLUDE
Bugs item #636920, was opened at 2002-11-12 02:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636920&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Jeff Miner (jeff_miner) Assigned to: Nobody/Anonymous (nobody) Summary: JSP INCLUDE Initial Comment: v 3.0.4 See my previous #594563 which starksm closed. Inclusion of JSP using RequestDispatcher causes included content to jump to top of page. He claims this was fixed, yet the latest, greatest download (v 3.0.4) exhibits the same behavior. Do I need to upgrade Jetty separately? One can flush the out buffer in the JSP before including, but I need to do this in the object, not in the JSP. Why doesn't the RequestDispatcher know how to do this? -- >Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 22:35 Message: Logged In: YES user_id=592596 Aha! Looks like the clean way to do this is with PageContext.include() Thus, pass the PageContext, but not necessarily the Request and Response, and call PageContext.include() without a Dispatcher. Seems to work and is cleaner (though the Dispatcher still OUGHT to work) -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 10:58 Message: Logged In: YES user_id=592596 OK - Sorry I got hot under the collar - I'm having roughly the same discussion with Macromedia over JRun and they out and out said "it is not a bug, this is according to spec" which is just foolish. I guess I can sort of envision how the problem arises from not integrating the JSPs into the ServletEngine, but I still don't understand how the servlet can do ANY include properly if this doesn't work - that is, if the JSP servlet is up to spec, because any servlet's output would have to be properly inserted in the buffer. Why should the JSP servlet be different? I can use the workarounds, but it means an extensive rewrite. The reason things need to be done this way (in brief) is that the getOutput() method exists on many objects polymorphically and may not do an include at all, so I don't want to mess with buffers etc. and would rather not have to add params to all my method calls. FYI - This is actually a small part of a nested MVC design -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-11-14 10:27 Message: Logged In: YES user_id=44062 Hey Jeff - keep it cool OK. We are not ignoring your problem. We have analyzed it and given you some suggestions. Pretty good service for free! I agree - that it the include SHOULD work the same either way. It works for weblogic, because their JSP engine is integrated into their servlet engine. But many containers such as Jetty and Tomcat implement JSPs simply as a servlet within the container. It is not possible to simply resolve this problem with such an implementation of JSPs. The mood on the servlet JSR is that integrating JSPs with the servlet spec was a mistake and JSPs should no longer given special status within servlet containers. Why are JSPs favoured over webmacros, velocity, cocoon, etc. etc.? Hence future versions of the spec are moving away from tight integration of JSPs.If this was not the case, then I might be more inclined to jump hurdles to fix this problem. The root of the problem is a bad spec. It's not a bug, just poorly defined integration of several features. So the reality of the situation is that I think it VERY unlikey that this "bug" will be fixed by either the developers of jasper, tomcat or jetty. But, it is open source and you are free to give it a go yourself! PS. Servlets don't normally "have to know about JSP buggering, etc. in order to include them properly". You are using servlet code within a JSP and that is not normal. There are plenty of things you can break in JSPs if you start playing with the full servlet API - these are not bugs, just dangers inherent in the design of JSPs. I strongly suggest that once you have invoked a JSP, that you use JSP techniques for include etc. If you want to do servlet stuff, then do it in a servlet - not via a JSP. Better yet, get a propper MVC design going, where the servlets do the Control and JSPs to the View. regards -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 10:01 Message: Logged In: YES user_id=592596 Mr. Wilkins, I don't want to get snippy here, but I do not think there is any problem with MY code. A RequestDispatcher that dispatches to a JSP should do exactly what the tag does -- no more, no less. Servlets shouldn't have to know about JSP buffering, etc. in order to include them properly. Certainly I could pass the writer around, I can pass the PageContex
[JBoss-dev] [ jboss-Bugs-574130 ] Remote UserTransaction fails name lookup
Bugs item #574130, was opened at 2002-06-26 08:29
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=574130&group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Jon Swinth (jswinth)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remote UserTransaction fails name lookup
Initial Comment:
When using a UserTransaction from a remote client (i.e.
standalone Tomcat) in which JBoss is not on the same
server results in an exception when begin() is called.
This happens specifically when new
InitialContext(Properties) is used to connect to the
JBoss server. Traced the issue to
org.jboss.tm.usertx.client.ClientUserTransaction.createSession().
In this method new
InitialContext().lookup("UserTransactionSessionFactory")
is called. Since there are no jndi.properties, the
InitialContext defaults to 127.0.0.1 which fails.
--
>Comment By: Jon Swinth (jswinth)
Date: 2002-11-14 14:31
Message:
Logged In: YES
user_id=541070
Yes, I can see your point, but that isn't always an option.
My experience with Apache Tomcat has been that a
jndi.properties file does not work. Shouldn't the
UserTransaction object stub that I retrieve already know
what server it came from?
--
Comment By: Ole Husgaard (sparre)
Date: 2002-11-05 23:59
Message:
Logged In: YES
user_id=175257
This Remote UT implementation only controls transactions
on a single JBoss server. It has to find that server, and
that is done through jndi.
The fix is simple: Create a client jndi.properties file.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=574130&group_id=22866
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-558052 ] ENC is not set in ServletContextListener
Bugs item #558052, was opened at 2002-05-19 19:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=558052&group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Bogdan Ghidireac (ghidi)
Assigned to: Nobody/Anonymous (nobody)
Summary: ENC is not set in ServletContextListener
Initial Comment:
I want to use ServletContextListener to create an EJB
used to initialize my application.
When I am trying to lookup my bean, I get a
javax.naming.NameNotFoundException: env not bound
I am using JBoss3.0.0RC2-Jetty.
With JBoss3.0.0RC2-tomcat it is working fine.
Regards,
Bogdan
--
Comment By: Keenan Ross (keenanross)
Date: 2002-11-14 22:25
Message:
Logged In: YES
user_id=649277
I'm seeing the same error with an
javax.servlet.http.HttpSessionListener on either JBoss 3.0.4
or 3.2.0Beta, both the Jetty distribution. I'm on Jdk
1.4.1_01 on Windows. I have a HttpSessionListener who's
constructor creates a new ServiceLocator and puts it in the
session. The service locator calls "ic =new
InitialContext()" which works, but then as it tries to
navigate to the ENC with enc =
(Context)ic.lookup("java:comp/env"), I get a naming
exception indicating "env not bound". I don't actually want
to do any ENC lookups at this time, just store away the
context for future use.
I'm new to JBoss bug reporting, so let me know if I need to
supply more info, or if I should have opened this as a new bug.
--
Comment By: Jan Bartel (janb)
Date: 2002-05-22 15:17
Message:
Logged In: YES
user_id=45251
This is now fixed in JBoss HEAD.
Can a CVS admin please close this issue as I don't have
permission. Thanks.
--
Comment By: Jan Bartel (janb)
Date: 2002-05-21 15:18
Message:
Logged In: YES
user_id=45251
I have fixed this in Jetty HEAD. It will be incorporated
into JBoss HEAD in the next day or so.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=558052&group_id=22866
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Forums Search Fixed
FYI, the search feature of the forum should work again. Thanks to those who let us know it was broken. --jason --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-637880 ] RMI sockets not closed
Bugs item #637880, was opened at 2002-11-13 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=637880&group_id=22866 Category: JBossServer Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jim Snyder (jdsnyderii) Assigned to: Nobody/Anonymous (nobody) Summary: RMI sockets not closed Initial Comment: RMI sockets for the RMIObjectPort on conatiner configurations are not being closed and consume huge numbers of sockets. We have been able to show that for all releases of 2.4.x that RMI connections are terminated rather than closed. For example, if I telnet to the RMI port and close the connection correctly, all the sockets go away correctly. A large question is why are all of these sockets being created in the first place if everything is in the same VM? Applies to jdks (1.3 and 1.4) Applies to Win2K and Linux -- >Comment By: Jim Snyder (jdsnyderii) Date: 2002-11-14 14:35 Message: Logged In: YES user_id=424928 The behavior is actually correct. -- Comment By: Jimmy Wan (jwan) Date: 2002-11-13 12:22 Message: Logged In: YES user_id=648382 I have also observed this behavior, even though all standardjboss.xml and jboss.xml container-configuration elements contained container-invoker-conf subelements where Optimized was "True". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=637880&group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CMP on JBoss
please dain, take the new development of the CMP on JBoss online. If there is a rewrite, put it online, share the docs for the design, let us know how you want the site to look and feel and we will do it. Explore new grounds of collaborative development marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-633392 ] HANamingService uses MulticastSockets
Bugs item #633392, was opened at 2002-11-04 09:57
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633392&group_id=22866
Category: Clustering
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Simo Arajarvi (simo22)
Assigned to: Sacha Labourey (slaboure)
Summary: HANamingService uses MulticastSockets
Initial Comment:
HANamingService uses MulticastSocket instead of
JavaGroups methods for automatic discovery.
This seems to cause discovery mechanism to find HA
JNDI peers beyond the intended cluster partition.
See: AutomaticDiscovery -inner class of
org.jboss.ha.jndi.HANamingService.
OS: Win2K, Solaris
JDK: 1.4
Server trace: n/a
Reproduce: Start two cluster partitions (pA,pB) within
same subnet. Both partitions contain a HA-JNDI bound
object with same name but different implementation. if
partition pA becomes unavailable, clients using it's
services will resort to using pB instead of failing as
expected.
This issue was discovered by Scott Stark and Munir
Hafez at the Seattle advanced training seminar (Oct 21-
24, 2002)
--
>Comment By: Scott M Stark (starksm)
Date: 2002-11-14 10:59
Message:
Logged In: YES
user_id=175228
No, the problem Simo showed me was that the cluster node
would not even start because of this call to
java.net.MulticastSocket inside of the HANamingService (the
server side code):
public AutomaticDiscovery () throws Exception
{
socket = new java.net.MulticastSocket (adGroupPort);
group = InetAddress.getByName (adGroupAddress);
socket.joinGroup (group);
String address = getBindAddress();
if (address == null)
ipAddress = (java.net.InetAddress.getLocalHost
().getHostAddress() +
":" + port).getBytes();
else
ipAddress = (address + ":" + port).getBytes();
log.info("Listening on " + socket.getInterface() + ":" +
socket.getLoca
lPort());
}
Do the test yourself. Disable multicast on your box, configure
JG to not use multicast and try starting the
HANamingService.
--
Comment By: Sacha Labourey (slaboure)
Date: 2002-11-14 10:41
Message:
Logged In: YES
user_id=95900
No, the problem is on the client. Remember: the discovery
features aims to discover at least one server by a *client*. On
the server, JG is implicitly used because the answer send
from the server to the client is a clustered proxy (i.e. a proxy
containing the list of all available servers) and this clustered
proxy is built from information obtained from JG.
On the client side, we don't use JG. When no server is
available, we have only one way to try to discover one:
through multicast. This is what we do.
The complain is about the client not being able to discover a
HA-JNDI service for a *given* partition (and only this specific
partition). Currently, if more than one partition is available on
a network, an automatic discovery will return a clustered
proxy for one of the partition (randomly selected) => non-
deterministic!
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-13 13:35
Message:
Logged In: YES
user_id=175228
The problem is not on the client. The problem is with the
AutomaticDiscovery not using JG to do its discovery on the
server side. If you configure a cluster to use only TCP
because you are running in a network that does not have
multicast enabled, the HA-JNDI service will not start because
of the AutomaticDiscovery reliance on multicast.
--
Comment By: Sacha Labourey (slaboure)
Date: 2002-11-04 10:07
Message:
Logged In: YES
user_id=95900
The problem is not the fact that JG is not used to discover HA-
JNDI server: we don't want any JG code on the client side.
Instead we will add a new property in jndi.properties to
specify which partition is looked for. It will also be possible to
change the multicast address used for discovery.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633392&group_id=22866
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MetaDataRepository Proposal
Bill Burke wrote: We can just throw away any code I add later. It won't take very long.. What I am suggesting is a fairly small change. You guys are just getting way to excited about repository implementation details. I just I'm not focusing on implementation details, just throwing in ideas... Requirements: - Layered config. i.e. Cluster-wide vs. App-Server vs. Component - Notifications - search capability. - integration with JMX (or leveraging/extending it.) Whatever is decided. Understood. Do you see my point of view? From my point of view they are implementation details. The consumer of the data in a repository doesn't really need to know that it is layers, that is has notification, that complex searches can happen under the covers, etc. All the consumer wants to know is "what is the tx attribute for this invocation?" -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MetaDataRepository Proposal
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > Sundstrom > Sent: Thursday, November 14, 2002 1:04 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] MetaDataRepository Proposal > > > Matt Munz wrote: > >> and the worst part is we have no control over it at runtime. It is > >> way simpler. You'll see. > > > > > > It sounds like you have a vision. Please continue to make the effort > > to get the rest of us into the loop. I want to "see" also, but I'd > > prefer to do so sooner rather than later (not after it's done and > > finished). > > We can just throw away any code I add later. It won't take very long.. > What I am suggesting is a fairly small change. You guys are just > getting way to excited about repository implementation details. I just I'm not focusing on implementation details, just throwing in ideas... Requirements: - Layered config. i.e. Cluster-wide vs. App-Server vs. Component - Notifications - search capability. - integration with JMX (or leveraging/extending it.) Whatever is decided. > need a place to get information. I really don't care where it comes > from. Until you guys decide on how to load the repository and keep it > in sync with a physical store, I'll just write a very simple one that > uses our current metadata code. I made the interface super simple so it > can be replace later. Also the total size of the code will be a 3-4 > small classes, so we can just toss the entire idea if needed later. > > >> The easiest case for me the read ahead configuration in entity > >> beans. There is no reason for this to be static. In fact it should > >> be manageable at runtime, and if I'm luck I'll be able to pull it > >> off for 4.0. Scott tells me there is a similar need to manage > >> security at > > > > > > Great, now we're getting somewhere. Can you pick one of these > > (perhaps the read ahead), and provide some details? What does the > > server admin have to do that is particularly time consuming? It may > > be obvious to you, but I'd love to hear the details on this one. > > I'm saying that it is currently not possible to changes this type of > information, and if we could the metadata is scattered across the > interceptor and plugins. There is no regular usage, storage, or > management of the current data. I am only proposing a clean separation > between the data and the users (Interceptors) and nothing more. > > >> runtime. There really is no need to shut down an application in > >> production just to change some configuration data. > > > > > > This is *exactly* what MBean Persistence is supposed to do, IMO. > > Feel free to reread that last sentence for added emphasis. Why not > > channel this energy into making MBean Persistence even better? > > Shouldn't any and all server configuration be done through JMX > > anyway? Isn't that the point of JMX in the first place? > > I only want a clean separation. I really don't care what the backing > store is or how we actually managing it. I fully expect my lame > repository to be tossed and replaced with several implementations (until > we figure out the best way). > > >> Even if there is no real need the code is simpler. > > > > > > Simple is the key word. I'm new and all, so feel free to ignore me, > > but this whole thing just sets off my KISS alarm system -- it > > actually sounds rather complicated. > > Go take a look at the TxInterceptors, SecurityInterceptors and the > Containers. 90% of the code is getting data out of the metadata objects > and caching it in an internal hashtable. I am just proposing we > centralize that code into a single interceptor with a repository for > caching. Simpler. > > -dain > > > > --- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
great, > scenario. The PooledInvoker is 300% faster than the default > RMI Invoker. > > 2nd scenario: > invokor is 30% faster than the default RMI based invoker. > P.S. This code is extremely more simple than the Trunk > Invoker and I've been told that the Trunk Invoker provides no > performance boost. Plus the name sucks. Let's stir clear of 'cute names', PooledInvoker clearly describes what it is. amrc f > > > > --- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-633392 ] HANamingService uses MulticastSockets
Bugs item #633392, was opened at 2002-11-04 18:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633392&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Simo Arajarvi (simo22) Assigned to: Sacha Labourey (slaboure) Summary: HANamingService uses MulticastSockets Initial Comment: HANamingService uses MulticastSocket instead of JavaGroups methods for automatic discovery. This seems to cause discovery mechanism to find HA JNDI peers beyond the intended cluster partition. See: AutomaticDiscovery -inner class of org.jboss.ha.jndi.HANamingService. OS: Win2K, Solaris JDK: 1.4 Server trace: n/a Reproduce: Start two cluster partitions (pA,pB) within same subnet. Both partitions contain a HA-JNDI bound object with same name but different implementation. if partition pA becomes unavailable, clients using it's services will resort to using pB instead of failing as expected. This issue was discovered by Scott Stark and Munir Hafez at the Seattle advanced training seminar (Oct 21- 24, 2002) -- >Comment By: Sacha Labourey (slaboure) Date: 2002-11-14 19:41 Message: Logged In: YES user_id=95900 No, the problem is on the client. Remember: the discovery features aims to discover at least one server by a *client*. On the server, JG is implicitly used because the answer send from the server to the client is a clustered proxy (i.e. a proxy containing the list of all available servers) and this clustered proxy is built from information obtained from JG. On the client side, we don't use JG. When no server is available, we have only one way to try to discover one: through multicast. This is what we do. The complain is about the client not being able to discover a HA-JNDI service for a *given* partition (and only this specific partition). Currently, if more than one partition is available on a network, an automatic discovery will return a clustered proxy for one of the partition (randomly selected) => non- deterministic! -- Comment By: Scott M Stark (starksm) Date: 2002-11-13 22:35 Message: Logged In: YES user_id=175228 The problem is not on the client. The problem is with the AutomaticDiscovery not using JG to do its discovery on the server side. If you configure a cluster to use only TCP because you are running in a network that does not have multicast enabled, the HA-JNDI service will not start because of the AutomaticDiscovery reliance on multicast. -- Comment By: Sacha Labourey (slaboure) Date: 2002-11-04 19:07 Message: Logged In: YES user_id=95900 The problem is not the fact that JG is not used to discover HA- JNDI server: we don't want any JG code on the client side. Instead we will add a new property in jndi.properties to specify which partition is looked for. It will also be possible to change the multicast address used for discovery. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633392&group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] article about cache - local/global
he he lol marc f > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net] On > Behalf Of Dain Sundstrom > Sent: Wednesday, November 13, 2002 10:59 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] article about cache - local/global > > > Did you actually read all the way to the bottom? This fucking smuck > thinks this is a new idea and has applied for patent in Russia. > > -dain > > Holger Baxmann wrote: > > http://www.opencores.org/articles?cmd=view_article&id=6 > > > > bax > > > > > > --- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Eclipse deployer
we may start an eclipse on jboss project soon, I am still looking for the natural leader in that space. Please put this in the patches in the meantime and watch the online space from time to time marc f > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net] On > Behalf Of Igor Fedorenko > Sent: Tuesday, November 12, 2002 3:34 PM > To: jboss-development > Subject: [JBoss-dev] Eclipse deployer > > > Hi, > > Few months ago I wrote special deployer that knows structure > of eclipse > workspace and is able to deploy ejb's directly from eclipse's > workspace > without need to package them first. My boss does not mind making this > code available to public and I wonder if this is something that > can/should be put into JBoss cvs repository. Any advice? > > -- > Igor Fedorenko > Think smart. Think automated. Think Dynamics. www.thinkdynamics.com > > > > --- > This sf.net email is sponsored by: > To learn the basics of securing your web site with SSL, > click here to get a FREE TRIAL of a Thawte Server Certificate: > http://www.gothawte.com/rd522.html > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new forums for development
this is one of the features we are working on for the rewrite marc f > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net] On > Behalf Of Lennart Petersson > Sent: Wednesday, November 13, 2002 2:57 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] new forums for development > > > Looks good. Any news about nntp gateway? > > /Love mail and news - hate browsers :) > > tisdagen den 12 november 2002 kl 18.27 skrev marc fleury: > > > Guys, > > > > I just created a bunch of forums in the development forums. > > > > > > --- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] http deployer - 3.2 CVS
JBOSS 3.2 CVS (Last night) Linux 2.2 / JVM 1.3.1/Blackdown I am testing the http to deploy an ear. Deploy .. lynx -dump http://localhost:8082/InvokeAction//jboss.system:service=MainDeployer/action=deploy?java.lang.String%2Bjava.lang.String=file:/home/dave/import/rns/..//rns/tests/dist/rnsTest.ear Then undeploy lynx -dump http://localhost:8082/InvokeAction//jboss.system:service=MainDeployer/action=undeploy?java.lang.String%2Bjava.lang.String=file:/home/dave/import/rns/..//rns/tests/dist/rnsTest.ear When I undeploy I get the following WARNINGS in the container 12:56:04,585 INFO [EARDeployer] Undeploying J2EE application, destroy step: file:///home/dave/import/rns/..//rns/tests/dist/rnsTest.ear 12:56:04,604 WARN [DeploymentInfo] Not deleting localUrl, it is null or not a copy: file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/rnsTest.war 12:56:04,615 INFO [MainDeployer] Undeployed file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/rnsTest.war 12:56:04,629 WARN [DeploymentInfo] Not deleting localUrl, it is null or not a copy: file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/candata_test_util.jar 12:56:04,639 INFO [MainDeployer] Undeployed file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/candata_test_util.jar 12:56:04,654 WARN [DeploymentInfo] Not deleting localUrl, it is null or not a copy: file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/junit.jar 12:56:04,665 INFO [MainDeployer] Undeployed file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/junit.jar 12:56:04,678 WARN [DeploymentInfo] Not deleting localUrl, it is null or not a copy: file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/rns-test.jar 12:56:04,689 INFO [MainDeployer] Undeployed file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/rns-test.jar 12:56:04,696 WARN [DeploymentInfo] Not deleting localUrl, it is null or not a copy: file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/cactus.jar 12:56:04,698 INFO [MainDeployer] Undeployed file:/home/dave/ejb/server/default/tmp/deploy/home/dave/import/rns/../rns/tests/dist/rnsTest.ear/92.rnsTest.ear-contents/cactus.jar 12:56:04,702 INFO [DeploymentInfo] Cleaned Deployment: file:///home/dave/import/rns/..//rns/tests/dist/rnsTest.ear 12:56:04,703 INFO [MainDeployer] Undeployed file:///home/dave/import/rns/..//rns/tests/dist/rnsTest.ear And the tmp directory entries are not removed. So why does it think it is not a copy? I am also seeing a problem reading the jar enrty on deploy but I am still working on a test case, but it is intermittent and I am wondering if this is the same problem. PS. After looking at the URL I thought the ..// would be possibly causing the problem ... took it out and got the same thing. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MetaDataRepository Proposal
Matt Munz wrote: >> and the worst part is we have no control over it at runtime. It is >> way simpler. You'll see. > > > It sounds like you have a vision. Please continue to make the effort > to get the rest of us into the loop. I want to "see" also, but I'd > prefer to do so sooner rather than later (not after it's done and > finished). We can just throw away any code I add later. It won't take very long.. What I am suggesting is a fairly small change. You guys are just getting way to excited about repository implementation details. I just need a place to get information. I really don't care where it comes from. Until you guys decide on how to load the repository and keep it in sync with a physical store, I'll just write a very simple one that uses our current metadata code. I made the interface super simple so it can be replace later. Also the total size of the code will be a 3-4 small classes, so we can just toss the entire idea if needed later. >> The easiest case for me the read ahead configuration in entity >> beans. There is no reason for this to be static. In fact it should >> be manageable at runtime, and if I'm luck I'll be able to pull it >> off for 4.0. Scott tells me there is a similar need to manage >> security at > > > Great, now we're getting somewhere. Can you pick one of these > (perhaps the read ahead), and provide some details? What does the > server admin have to do that is particularly time consuming? It may > be obvious to you, but I'd love to hear the details on this one. I'm saying that it is currently not possible to changes this type of information, and if we could the metadata is scattered across the interceptor and plugins. There is no regular usage, storage, or management of the current data. I am only proposing a clean separation between the data and the users (Interceptors) and nothing more. >> runtime. There really is no need to shut down an application in >> production just to change some configuration data. > > > This is *exactly* what MBean Persistence is supposed to do, IMO. > Feel free to reread that last sentence for added emphasis. Why not > channel this energy into making MBean Persistence even better? > Shouldn't any and all server configuration be done through JMX > anyway? Isn't that the point of JMX in the first place? I only want a clean separation. I really don't care what the backing store is or how we actually managing it. I fully expect my lame repository to be tossed and replaced with several implementations (until we figure out the best way). >> Even if there is no real need the code is simpler. > > > Simple is the key word. I'm new and all, so feel free to ignore me, > but this whole thing just sets off my KISS alarm system -- it > actually sounds rather complicated. Go take a look at the TxInterceptors, SecurityInterceptors and the Containers. 90% of the code is getting data out of the metadata objects and caching it in an internal hashtable. I am just proposing we centralize that code into a single interceptor with a repository for caching. Simpler. -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MetaDataRepository Proposal
Peter Fagerlund wrote:
onsdagen den 13 november 2002 kl 23.56 skrev Dain Sundstrom:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
maybe add
void setJDBCBackend(url, u, p);
void serConf(path);
Implementation detail.
The final problem is how do we keep this repository in sync with the
physical store. For this I would guess we need some sort of listener
or notification system. This isn't one of my current problems so I
haven't thought about it too much.
hmmm ... me thinks hsqldb is way underused as a admin tool in jboss
today ... hehe ... i am biased ... yes ...
hsqldb has a pluggable listener called Trigger.class with one method
public void fire(String trigName, String tabName, Object row[]);
so when an jboss instance starts ... it would ofcource need some core
configuration either as a xml-file or class.ser ? then one could start a
"jdbc:hsqldb:hsql:." instance and go get configuration - also when db
changes it will notify other db's throughout *hsqldbr and there is our
"distributed metadata repository" ... all sql, all libs in there already
... cool ...
Sure, but to me this is just an implementation detail of whatever
repository the admin decides to use.
-dain
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MetaDataRepository Proposal
Bill Burke wrote: In all honesty Dain, I don't think this is a simplification. And Hiram's right. Attaching interfaces with the aspect framework should give you the functionality you want here of adding read-ahead apis. How would it get into the invocation? EasilyIts just another invocation on the invocation stack. A client interceptor intercepts the setReadAhead method, and stuff 500 into some variable. With regular calls, that same interceptor attaches the read-ahead value into the invocation object. CMP picks up the value from the invocation if it is there. Sure but where does the client put the info while it is waiting for an invocation? What about the server side? Where does the server store the defaults (assuming they did not come from the client) while waiting for the invocations? -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: chill on MetadataRepository
Bill Burke wrote: > Dain, > > Chill on the metadata repository. This is a significant change to > JBoss and you have not thought through all the issues. (Notification, > persistence, JMX integation, etc...) David is right, we really need > to flush out the usecases for this and how it will help the system > and effect it. Your use case of the read-ahead cache could be > implemented with attaching interfaces to the CMP proxy with the > Aspect framework. Whatever Bill. I need a place to put general information for the interceptors to get at. That is my use case. All this other stuff is a detail. In the end if you don't like my implementation, it is only one interceptor and one repository class. Just throw it all away. > Don't you have more important work to do anyways? Like the new cache > stuff for CMP 2.0, or CMP 2.0 rewrite? Focus dude. Focus. Yes, and until I have the ground work laid, I am dead in the water. > Besides... > > Also, I think we should investigate XmlBlaster (peter antman > suggested) which does exactly the magic I was talking about with > XPATHs. Others have suggested Jelly, JXpath...These also could help > tremedously. Sure it is one of the million possible implementations of the repository. I am not interested in the final implementation only my interface to it. > Here's some of the requirements I think the repository should have if > we go forward with it > > - layered config (you already have this idea with parents and such) > so that config info can be layerd across cluster, app server, > component, invocation as I discussed before. > > - Notifications on config changes. THis is really really important. > We want to be able to change config clusterwide and have it trickle > down to interested components. > > - JMX needs to be brought into this too. We need to figure out how > JMX fits in so there is no redundancy. > > - XML is the perfect format and API for the repository IMHO. I see > components wanting to iterate over a namespace (Element). XML also > provides us with the search capabilities and such. > > FYI, I've written centralized configuration repositories in the past > at Iona for Orbix2000, so I've seen this shit in action. Agreed. But all of these details should be hidden from the general users (i.e., me). -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.net email transport
Jason, You rock. Thanks. I have a much better understanding now of why it helps to have this tool in the toolbox. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jason Essington Sent: Thursday, November 14, 2002 12:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jboss.net email transport On Thursday, November 14, 2002, at 08:55 AM, Matt Munz wrote: > Jason, > > Well, you've peaked my interest... > >> This method(with digital signatures/encryption) would be more secure >> than the Http(s) transport, > > Really? Any articles on the subject? Using digital signatures / xml encryption would make the soap message more secure over any transport http://www.xml.com/pub/a/2001/08/08/xmldsig.html Here are two from JavaWorld about Securing web services in general. http://www.javaworld.com/javaworld/jw-08-2002/jw-0823-securexml.html http://www.javaworld.com/javaworld/jw-10-2002/jw-1011-securexml.html And two from developerworks on xml encryption in general http://www-106.ibm.com/developerworks/library/x-encrypt/index.html http://www-106.ibm.com/developerworks/library/x-encrypt2/index.html >> Authentication would be near definite >> (rather hard to fake), > > Is there something in the mail protocol that facilitates this? I'd > love to > see a strong argument for "email is more secure than https"... Email has really NO good authentication system, so rather than depend on the smtp (or whatever) protocal for security and authentication, we use XML-Signature and XML-Encryption to secure the SOAP message. This method will add additional security to any transport. http://www.w3.org/TR/SOAP-dsig/ http://www.w3.org/TR/xmldsig-core/ http://www.w3.org/TR/xmlenc-core/ > >> the server would not be exposed to the big bad >> internet, > > Hmmm. Email attacks are fairly common. Email is, by definition, a > part of > the internet. I'm not sure where you're going with this... The app server itself would not be exposed, it would still have an indirect connection via email (mail server), but the email transport only handles a very small subset of email types and discards the rest. > >> and the company's IT guys don't have to set up a VPN to every >> outside source that needs to update data in the server. > > VPNs are bad ;) What's wrong with the tried and true "poking a hole > in the > firewall" technique? What about https? Some companies are rather picky about what gets poked through their firewall, and in some companies certain departments fear the IT group and would rather not bother them to do such things. This just gives another option that doesn't require the poking of holes in the firewall. > Is the idea that "they have to have email anyway, so let's just tunnel > over > that"? Wasn't this same argument used for HTTP tunnelling? HTTP(S) is nice, and would be completely sufficient if incoming packets were allowed in every environment, but since there are situations where this is not possible there is a need for another method. Since the email transport initiates the transaction (contacts the email server to collect messages) it is capable of if performing in situations where http could not. And yes, since the app server already has it's own email account, this is a ready made path to follow. I am in no way saying that the http transport is bad, I am just trying to create an option for situations where http is not feasible. Email has it's inherent shortcomings that the implementation of xml-security would help alleviate. So really what we have here is two-fold, a security infrastructure that allows soap messages to be digitally signed and possibly encrypted and an additional transport that depends on that infrastructure to allow for the secure transmission and authentication of data. -jason --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.net email transport
On Thursday, November 14, 2002, at 08:55 AM, Matt Munz wrote: Jason, Well, you've peaked my interest... This method(with digital signatures/encryption) would be more secure than the Http(s) transport, Really? Any articles on the subject? Using digital signatures / xml encryption would make the soap message more secure over any transport http://www.xml.com/pub/a/2001/08/08/xmldsig.html Here are two from JavaWorld about Securing web services in general. http://www.javaworld.com/javaworld/jw-08-2002/jw-0823-securexml.html http://www.javaworld.com/javaworld/jw-10-2002/jw-1011-securexml.html And two from developerworks on xml encryption in general http://www-106.ibm.com/developerworks/library/x-encrypt/index.html http://www-106.ibm.com/developerworks/library/x-encrypt2/index.html Authentication would be near definite (rather hard to fake), Is there something in the mail protocol that facilitates this? I'd love to see a strong argument for "email is more secure than https"... Email has really NO good authentication system, so rather than depend on the smtp (or whatever) protocal for security and authentication, we use XML-Signature and XML-Encryption to secure the SOAP message. This method will add additional security to any transport. http://www.w3.org/TR/SOAP-dsig/ http://www.w3.org/TR/xmldsig-core/ http://www.w3.org/TR/xmlenc-core/ the server would not be exposed to the big bad internet, Hmmm. Email attacks are fairly common. Email is, by definition, a part of the internet. I'm not sure where you're going with this... The app server itself would not be exposed, it would still have an indirect connection via email (mail server), but the email transport only handles a very small subset of email types and discards the rest. and the company's IT guys don't have to set up a VPN to every outside source that needs to update data in the server. VPNs are bad ;) What's wrong with the tried and true "poking a hole in the firewall" technique? What about https? Some companies are rather picky about what gets poked through their firewall, and in some companies certain departments fear the IT group and would rather not bother them to do such things. This just gives another option that doesn't require the poking of holes in the firewall. Is the idea that "they have to have email anyway, so let's just tunnel over that"? Wasn't this same argument used for HTTP tunnelling? HTTP(S) is nice, and would be completely sufficient if incoming packets were allowed in every environment, but since there are situations where this is not possible there is a need for another method. Since the email transport initiates the transaction (contacts the email server to collect messages) it is capable of if performing in situations where http could not. And yes, since the app server already has it's own email account, this is a ready made path to follow. I am in no way saying that the http transport is bad, I am just trying to create an option for situations where http is not feasible. Email has it's inherent shortcomings that the implementation of xml-security would help alleviate. So really what we have here is two-fold, a security infrastructure that allows soap messages to be digitally signed and possibly encrypted and an additional transport that depends on that infrastructure to allow for the secure transmission and authentication of data. -jason --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] new PooledInvoker: speeds up invocations
Ok, when I was doing ECPerf tests, I was trying anything to squeak out better performance. Here's where the PooledInvoker came in. The idea is to pool connections at the remote client as well as pool threads/connections on the server side. So, when a remote client first connects, the server will create a dedicated thread/connection for that client. The client will pool the connection locally for re-use by ANY proxy on the client. If the client goes away, or the connection times out, the server will throw away and close the socket, but pool the thread for later use. Also, the server's pool is LRU so that it can manage the size of the pool. Please check out the code for more info. Code is in 3.2 and head under server/src/main/org/jboss/invocation/pooled. If you want to know how to use this, look at the testsuite under pooled/ test. Now the numbers: The testsuite spawns 300 threads under 2 scenarios: 1st scenario: Each thread loops 10 times with the following: SLSB slsb = home.create(); slsb.noop(); So a new proxy is obtained for each invocation. In this scenario. The PooledInvoker is 300% faster than the default RMI Invoker. 2nd scenario: home.create() is called before launching the benchmark and the SLSB proxy is passed to each thread. Each thread loops 10 times calling the noop(). In this scenario the pooled invokor is 30% faster than the default RMI based invoker. Dain has a customer that is potentially using this new invoker I wrote and he has suggested that it because the default invoker for 3.2 and higher. Let me know if you think this is a possibility. Thanks, Bill P.S. This code is extremely more simple than the Trunk Invoker and I've been told that the Trunk Invoker provides no performance boost. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-638520 ] Fix for 638488: OR with IS NOT EMPTY
Patches item #638520, was opened at 2002-11-14 08:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=638520&group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Boynes (jboynes) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 638488: OR with IS NOT EMPTY Initial Comment: Patch changing the SQL generated for IS [NOT] EMPTY clause. If subqueries are supported, this always generates an EXISTS clause. This is safe. If subqueries are not supported (mySQL), it always generates a LEFT JOIN and checks emptiness by seeing if the PK from the child is NULL. This requires that DISTINCT is specified for the select otherwise one row will be returned for each child. This may mean there are still some scenarios that don't work (I'm worried about a ejbSelect that is supposed to return duplicate rows and uses an IS [NOT] EMPTY clause) but they seem more contrived than the bug this is fixing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=638520&group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-638488 ] Incorrect SQL with OR and IS NOT EMPTY
Bugs item #638488, was opened at 2002-11-14 08:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638488&group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Boynes (jboynes) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect SQL with OR and IS NOT EMPTY Initial Comment: Opening this as 621270 has been closed. Incorrect SQL is generated for EJB-QL where IS NOT EMPTY is used in a OR condition such as: SELECT OBJECT(p) FROM parent p WHERE p.children IS NOT EMPTY OR p.value = ?1 generates SELECT t0_p.id FROM Parent t0_p, Child t1_p_children WHERE ((1=1) OR t0_p.value = ?) -- < oops AND (t0_p.id=t1_p_children.parent) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638488&group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Metadata Service
On 14 Nov, Bill Burke wrote: > Wow Peter! This is exactly what I was thinking of. Any JMX guys have any > ideas how we could integrate this? The server is already integrated: http://www.xmlBlaster.org/xmlBlaster/doc/requirements/j2ee.jmx.html There is also an JCA RA adaper if one want's to use it. http://www.xmlBlaster.org/xmlBlaster/doc/requirements/j2ee.k2.html Both developed by yours truly ;-) I also have a connection/subscriber pool MBean thingy, where you add subscribers through the MBean interface and get the callback/messages through JMX notifications. If someone is interested to take a look at it, fine. It uses some stuff I can not release, but the pool stuff and concepts around it I could share, if you will continue to like XmlBlaster after som more looks into it. I must say I have personally had verry good experiences from it. I have been woring with it for almost 2 years now, on and of, and it has worked great. It has high throughput (1600 XML messages/second), and has been running fine in a production environment for the last 6 month. A real gem. //Peter > > Bill > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Peter >> Antman >> Sent: Thursday, November 14, 2002 4:12 AM >> To: [EMAIL PROTECTED] >> Subject: Re: [JBoss-dev] Metadata Service >> >> >> Hi, >> have any one of you looked at XmlBlaster? (www.xmlBlaster.org). >> >> I guess it could really work as a central XmlRepository. XmlBlaster is >> an XML based MOM. You publish your XML to it and it will save it in an >> Xml DOM tree, even persist it a RDMB or Xincice. >> >> You can then subscribe to event with an XPath expression (or do a >> synchronous get (with an XPath). >> >> Ok. You can not just subsribe to one element, thats true, but you can >> subscribe on a "domain" or "config", say MyMessageDrivenBean and get any >> update notifications for that XML config. Or you could do a >> get(//x/y/port) (pseudocode!) and get all configs wich contains that >> element. There are a lot more to XmlBlaster (I have done the JBoss >> integration thats currently is available in XmlBlaster ;.)) >> >> Well, just a thought. >> >> //Peter >> >> On 13 Nov, Bill Burke wrote: >> > 1. I'm not talking about a central config file...Components >> register their >> > XML with this service. MBean, EJB, whatever... >> > >> > 2. You know what XPATHs are right? If not, look them up. They >> are really >> > cool. Xerces/Xalan (forget which) support looking up Elements >> via XPATHS. >> > What's not supported, which we would have to write, would be >> the ability to >> > register for change notifications via an XPATH. >> > >> > Other ideas: >> > - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. >> > Services/components registered as listening for changes, recieve >> > notification. >> > >> > - JMX console needs an additional XML editor for MBean >> attributes that are >> > XML elements. >> > >> > - This sort of centralized service allows you to query, via >> XPATHS, for all >> > components that have a "port" attribute for instance. Allows you to do >> > global things on configuration when you don't know the actual components >> > that have that type of attribute >> > >> > Another thing about configuration I wanted to have is the concept of >> > Configuration Domains. A component would get configuration by >> searching a >> > set of chained configuration domains. >> > >> > invocation domain->instance domain->component domain->app server >> > domain->cluster domain etc... >> > >> > So, when a component needs config information, it looks it up >> via the chain. >> > Any domain in the chain can override a config value. As the chain is >> > traversed, if the config info is not there, it searches farther up the >> > chain. >> > >> > This would allow us to have a layered way of obtaining default config >> > information, or overriding existing configuration at different levels at >> > different times. >> > >> > Bill >> > >> > >> > >> >> -Original Message- >> >> From: [EMAIL PROTECTED] >> >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt >> >> Munz >> >> Sent: Wednesday, November 13, 2002 1:26 PM >> >> To: [EMAIL PROTECTED] >> >> Subject: RE: [JBoss-dev] Metadata Service >> >> >> >> >> >> Dain, >> >> >> >> > Meta data for an invocation. >> >> >> >> I assume you refer here to EJB/servlet invocations. >> >> >> >> Just out of curiosity, how is that metadata currently stored? >> >> >> >> - Matt >> >> >> >> -Original Message- >> >> From: [EMAIL PROTECTED] >> >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain >> >> Sundstrom >> >> Sent: Wednesday, November 13, 2002 1:13 PM >> >> To: [EMAIL PROTECTED] >> >> Subject: Re: [JBoss-dev] Metadata Service >> >> >> >> >> >> Meta data for an invocation. What are the tx attributes? What is the >> >> security manager? What are the required roles? Wha
RE: [JBoss-dev] jboss.net email transport
Jason, Well, you've peaked my interest... > This method(with digital signatures/encryption) would be more secure > than the Http(s) transport, Really? Any articles on the subject? > Authentication would be near definite > (rather hard to fake), Is there something in the mail protocol that facilitates this? I'd love to see a strong argument for "email is more secure than https"... > the server would not be exposed to the big bad > internet, Hmmm. Email attacks are fairly common. Email is, by definition, a part of the internet. I'm not sure where you're going with this... > and the company's IT guys don't have to set up a VPN to every > outside source that needs to update data in the server. VPNs are bad ;) What's wrong with the tried and true "poking a hole in the firewall" technique? What about https? Is the idea that "they have to have email anyway, so let's just tunnel over that"? Wasn't this same argument used for HTTP tunnelling? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jason Essington Sent: Thursday, November 14, 2002 10:33 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jboss.net email transport Hi Matt, Given an instance where a company would place a server on its intranet (behind a firewall that does not allow incoming connections from the internet). Now, If this company wanted to receive periodic updates to some semi-static data (iso country codes for instance) from a source on the internet. This source would need a VPN to get through the companies firewall (major hassle if this source has to update many servers, or if the company needs data updated from many different sources) or it could send a Signed and possibly Encrypted email to a mail account the company has set up for the server. The server checks it's email at a configured interval and processes any soap messages it finds there. The digital signature is used for message verification and authentication, while encryption could be used to protect sensitive parts of the message. The message is processed and it's response (or fault) is returned to the original sender via the mail server. This method(with digital signatures/encryption) would be more secure than the Http(s) transport, Authentication would be near definite (rather hard to fake), the server would not be exposed to the big bad internet, and the company's IT guys don't have to set up a VPN to every outside source that needs to update data in the server. All in all, and email transport with digital signatures and encryption has quite a bit of promise as a secure way to allow data to pass through/around a firewall without too much extra hassle. There would need to be a mechanism for key exchange, but no work on the part of IT. -jason On Thursday, November 14, 2002, at 07:21 AM, Matt Munz wrote: > Jason, > > Just out of curiosity, what would you use this for? > > - Matt > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > Jason > Essington > Sent: Wednesday, November 13, 2002 5:48 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] jboss.net email transport > > > Hi all > > I have managed to get a fairly crude email transport working in > jboss.net (It is lurking in head). I would appreciate any comments / > design ideas from folks who are interested. > > Check the javadocs in org.jboss.net.axis.mail.MailTransportService to > see how to set it up. > > It will currently process emails with simple soap messages (no > attachments). It requires the content type to be application/soap+xml > with the action attribute set to the desired service. > > i.e. content-type: application/soap+xml; action=SomeService > > The response message is returned to the sender via email. > > Since email doesn't really have any type of authentication framework > the transport will only work with ejb's / ejb methods's that have > unchecked permissions. > > I have been able to sign (DSA) a soap message using apache's > xml-security library and have jboss.net verify the signature (I haven't > submitted this handler yet, as it depends on the apache xml-security > library that would have to be added to the thirdparty libs). > > I think this is the first step to some sort of authentication via email > (and cryptographic authentication by other transports as well). but . . > . > I haven't figured out how to go about trusting a given signature and > mapping it to a Subject. This is where I could use the help of someone > with a better knowledge of jaas and JBossSX than myself. > > Thanks for any feedback > > -jason > > > > --- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > __
RE: [JBoss-dev] MetaDataRepository Proposal
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > Sundstrom > Sent: Thursday, November 14, 2002 12:55 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] MetaDataRepository Proposal > > > Hiram Chirino wrote: > >>David, > >> > >>Actually it simplifies the code. If you take a look at our interceptor > >>stack most have a ton of code just to load and maintain the metadata, > > > > > > Yes there is alot of Metadata now. 1/2 the ton of code that we > have there > > is just taking XML and creating a metadata objects. I think > that something > > like Jelly (http://jakarta.apache.org/commons/sandbox/jelly/) > should be able > > eliminate that code. A tool that will take XML config and generate the > > Metadata objects that our interceptors can use directly. > > Sure. It is just a detail. I want to put in an interface between the > interceptor and the metadata repository. > > >>and the worst part is we have no control over it at runtime. It is way > >>simpler. You'll see. > >> > > > > > > I agree there. But wouldn't it be simpler if we just exposed > an API to the > > client that would allow him to modify the metadata (thus > turning something > > that is static now, into something dynamic)? > > > > For example. Say you have a CMP bean x, and the configuration API is > > exposed via an aspect, then on the client side you would do: > > > > CMPConfiguration c = (CMPConfiguration)x; > > c.setReadAhead( 500 ); > > > > And the would in turn create a Invocation with > method=setReadAhead that the > > CMP interceptor would handle by updating the metadata > configuration for the > > bean. > > > > Does this make sense? Are you trying to achieve something > similar but in a > > more automated way? > > This could easily happen but is not my motivation. I really just want > simplify the containers and interceptors. Anyway, where would this data > live? How would it get into the invocation? My guess is that the same > repository code could be used on the client side for client specific > configuration, but maybe it won't work for that. > In all honesty Dain, I don't think this is a simplification. And Hiram's right. Attaching interfaces with the aspect framework should give you the functionality you want here of adding read-ahead apis. How would it get into the invocation? EasilyIts just another invocation on the invocation stack. A client interceptor intercepts the setReadAhead method, and stuff 500 into some variable. With regular calls, that same interceptor attaches the read-ahead value into the invocation object. CMP picks up the value from the invocation if it is there. > -dain > > > > --- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] chill on MetadataRepository
Dain, Chill on the metadata repository. This is a significant change to JBoss and you have not thought through all the issues. (Notification, persistence, JMX integation, etc...) David is right, we really need to flush out the usecases for this and how it will help the system and effect it. Your use case of the read-ahead cache could be implemented with attaching interfaces to the CMP proxy with the Aspect framework. Don't you have more important work to do anyways? Like the new cache stuff for CMP 2.0, or CMP 2.0 rewrite? Focus dude. Focus. Besides... Also, I think we should investigate XmlBlaster (peter antman suggested) which does exactly the magic I was talking about with XPATHs. Others have suggested Jelly, JXpath...These also could help tremedously. Here's some of the requirements I think the repository should have if we go forward with it - layered config (you already have this idea with parents and such) so that config info can be layerd across cluster, app server, component, invocation as I discussed before. - Notifications on config changes. THis is really really important. We want to be able to change config clusterwide and have it trickle down to interested components. - JMX needs to be brought into this too. We need to figure out how JMX fits in so there is no redundancy. - XML is the perfect format and API for the repository IMHO. I see components wanting to iterate over a namespace (Element). XML also provides us with the search capabilities and such. FYI, I've written centralized configuration repositories in the past at Iona for Orbix2000, so I've seen this shit in action. Bill --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.net email transport
Hi Matt, Given an instance where a company would place a server on its intranet (behind a firewall that does not allow incoming connections from the internet). Now, If this company wanted to receive periodic updates to some semi-static data (iso country codes for instance) from a source on the internet. This source would need a VPN to get through the companies firewall (major hassle if this source has to update many servers, or if the company needs data updated from many different sources) or it could send a Signed and possibly Encrypted email to a mail account the company has set up for the server. The server checks it's email at a configured interval and processes any soap messages it finds there. The digital signature is used for message verification and authentication, while encryption could be used to protect sensitive parts of the message. The message is processed and it's response (or fault) is returned to the original sender via the mail server. This method(with digital signatures/encryption) would be more secure than the Http(s) transport, Authentication would be near definite (rather hard to fake), the server would not be exposed to the big bad internet, and the company's IT guys don't have to set up a VPN to every outside source that needs to update data in the server. All in all, and email transport with digital signatures and encryption has quite a bit of promise as a secure way to allow data to pass through/around a firewall without too much extra hassle. There would need to be a mechanism for key exchange, but no work on the part of IT. -jason On Thursday, November 14, 2002, at 07:21 AM, Matt Munz wrote: Jason, Just out of curiosity, what would you use this for? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jason Essington Sent: Wednesday, November 13, 2002 5:48 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] jboss.net email transport Hi all I have managed to get a fairly crude email transport working in jboss.net (It is lurking in head). I would appreciate any comments / design ideas from folks who are interested. Check the javadocs in org.jboss.net.axis.mail.MailTransportService to see how to set it up. It will currently process emails with simple soap messages (no attachments). It requires the content type to be application/soap+xml with the action attribute set to the desired service. i.e. content-type: application/soap+xml; action=SomeService The response message is returned to the sender via email. Since email doesn't really have any type of authentication framework the transport will only work with ejb's / ejb methods's that have unchecked permissions. I have been able to sign (DSA) a soap message using apache's xml-security library and have jboss.net verify the signature (I haven't submitted this handler yet, as it depends on the apache xml-security library that would have to be added to the thirdparty libs). I think this is the first step to some sort of authentication via email (and cryptographic authentication by other transports as well). but . . . I haven't figured out how to go about trusting a given signature and mapping it to a Subject. This is where I could use the help of someone with a better knowledge of jaas and JBossSX than myself. Thanks for any feedback -jason --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -jason --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Jason, we're not talking about one file on disk. We're talking about in memory...(well that's at least what I'm talking about). Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > Sundstrom > Sent: Wednesday, November 13, 2002 5:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Metadata Service > > > One huge file is better than a million little files scattered across my > hard drive, but that's not saying a lot. > > -dain > > Jason Dillon wrote: > > I would be careful about going with a huge file, these tend to become > > unnamable fast. > > > > --jason > > > > > > On Wednesday, November 13, 2002, at 09:07 AM, Bill Burke wrote: > > > >> Dain and I were IMing. He said Scott was thinking about a MetaData > >> service... > >> > >> My idea for a MetaData/Configuration service would be the ability to > >> register for callbacks based on XPATHS. So, all config of > jboss would be > >> stored in one big XML Document. Components insert their config there, > >> and > >> register for callbacks on this config via XPATHS. So, this > config can be > >> managed centrally, yet, components can easily be notified with changes > >> via a > >> simple mechanism. > >> > >> Bill > >> > >> > >> > >> --- > >> This sf.net email is sponsored by: Are you worried about > >> your web server security? Click here for a FREE Thawte > >> Apache SSL Guide and answer your Apache SSL security > >> needs: http://www.gothawte.com/rd523.html > >> ___ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > --- > > This sf.net email is sponsored by: Are you worried about your > web server > > security? Click here for a FREE Thawte Apache SSL Guide and answer your > > Apache SSL security needs: http://www.gothawte.com/rd523.html > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > -- > > Dain Sundstrom > Chief Architect JBossCMP > JBoss Group, LLC > > > > > --- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Wow Peter! This is exactly what I was thinking of. Any JMX guys have any ideas how we could integrate this? Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Peter > Antman > Sent: Thursday, November 14, 2002 4:12 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Metadata Service > > > Hi, > have any one of you looked at XmlBlaster? (www.xmlBlaster.org). > > I guess it could really work as a central XmlRepository. XmlBlaster is > an XML based MOM. You publish your XML to it and it will save it in an > Xml DOM tree, even persist it a RDMB or Xincice. > > You can then subscribe to event with an XPath expression (or do a > synchronous get (with an XPath). > > Ok. You can not just subsribe to one element, thats true, but you can > subscribe on a "domain" or "config", say MyMessageDrivenBean and get any > update notifications for that XML config. Or you could do a > get(//x/y/port) (pseudocode!) and get all configs wich contains that > element. There are a lot more to XmlBlaster (I have done the JBoss > integration thats currently is available in XmlBlaster ;.)) > > Well, just a thought. > > //Peter > > On 13 Nov, Bill Burke wrote: > > 1. I'm not talking about a central config file...Components > register their > > XML with this service. MBean, EJB, whatever... > > > > 2. You know what XPATHs are right? If not, look them up. They > are really > > cool. Xerces/Xalan (forget which) support looking up Elements > via XPATHS. > > What's not supported, which we would have to write, would be > the ability to > > register for change notifications via an XPATH. > > > > Other ideas: > > - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. > > Services/components registered as listening for changes, recieve > > notification. > > > > - JMX console needs an additional XML editor for MBean > attributes that are > > XML elements. > > > > - This sort of centralized service allows you to query, via > XPATHS, for all > > components that have a "port" attribute for instance. Allows you to do > > global things on configuration when you don't know the actual components > > that have that type of attribute > > > > Another thing about configuration I wanted to have is the concept of > > Configuration Domains. A component would get configuration by > searching a > > set of chained configuration domains. > > > > invocation domain->instance domain->component domain->app server > > domain->cluster domain etc... > > > > So, when a component needs config information, it looks it up > via the chain. > > Any domain in the chain can override a config value. As the chain is > > traversed, if the config info is not there, it searches farther up the > > chain. > > > > This would allow us to have a layered way of obtaining default config > > information, or overriding existing configuration at different levels at > > different times. > > > > Bill > > > > > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt > >> Munz > >> Sent: Wednesday, November 13, 2002 1:26 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] Metadata Service > >> > >> > >> Dain, > >> > >> > Meta data for an invocation. > >> > >> I assume you refer here to EJB/servlet invocations. > >> > >> Just out of curiosity, how is that metadata currently stored? > >> > >> - Matt > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > >> Sundstrom > >> Sent: Wednesday, November 13, 2002 1:13 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [JBoss-dev] Metadata Service > >> > >> > >> Meta data for an invocation. What are the tx attributes? What is the > >> security manager? What are the required roles? What is the readahead > >> configuration? That kind of data. > >> > >> -dain > >> > >> Matt Munz wrote: > >> > Dain/Bill/Scott, > >> > > >> > Could you clarify this? Metadata for what data? Are you > referring to > >> > MBeanInfo, or something else? > >> > > >> > - Matt > >> > > >> > -Original Message- > >> > From: [EMAIL PROTECTED] > >> > [mailto:jboss-development-admin@;lists.sourceforge.net]On > Behalf Of Dain > >> > Sundstrom > >> > Sent: Wednesday, November 13, 2002 12:52 PM > >> > To: [EMAIL PROTECTED] > >> > Subject: Re: [JBoss-dev] Metadata Service > >> > > >> > > >> > Bill Burke wrote: > >> > > >> >>Dain and I were IMing. He said Scott was thinking about a MetaData > >> >>service... > >> >> > >> >>My idea for a MetaData/Configuration service would be the ability to > >> >>register for callbacks based on XPATHS. So, all config of > >> jboss would be > >> >>stored in one big XML Document. Components insert their config > >> there, and > >> >>register for callbacks on this config via XPATHS. So, this > >> config can be > >> >>managed centrally, yet, components ca
RE: [JBoss-dev] MetaDataRepository Proposal
Dain, > and the worst part is we have no control over it at runtime. It is way > simpler. You'll see. It sounds like you have a vision. Please continue to make the effort to get the rest of us into the loop. I want to "see" also, but I'd prefer to do so sooner rather than later (not after it's done and finished). > The easiest case for me the read ahead configuration in entity beans. > There is no reason for this to be static. In fact it should be > manageable at runtime, and if I'm luck I'll be able to pull it off for > 4.0. Scott tells me there is a similar need to manage security at Great, now we're getting somewhere. Can you pick one of these (perhaps the read ahead), and provide some details? What does the server admin have to do that is particularly time consuming? It may be obvious to you, but I'd love to hear the details on this one. > runtime. There really is no need to shut down an application in > production just to change some configuration data. This is *exactly* what MBean Persistence is supposed to do, IMO. Feel free to reread that last sentence for added emphasis. Why not channel this energy into making MBean Persistence even better? Shouldn't any and all server configuration be done through JMX anyway? Isn't that the point of JMX in the first place? > Even if there is no real need the code is simpler. Simple is the key word. I'm new and all, so feel free to ignore me, but this whole thing just sets off my KISS alarm system -- it actually sounds rather complicated. - Matt --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Metadata Service
--- Christian Riege <[EMAIL PROTECTED]> wrote: > hi, > > On Wed, 2002-11-13 at 22:36, Dain Sundstrom wrote: > > > (Don't know much about XML Schemasmaybe they > address these issues?) > > > > This is what XML name spaces are for. If in ISV > wants to add more > > config options to jboss, if jboss wants to add new > options to the spec > > ejb-jar.xml file, we just put it in a different > name space. Of course > > this only works with a schema because dtd don't > understand name spaces. > > hu? it has always been my understanding ( i might be > completely > wrong/off track of course :), that a namespace is > tied to a specific DTD > - so that you can have an XML document which > contains more than 1 DTD > that are referenced by the namespace of the > elements. > > from my current understanding, XML Schema is only a > more specific way to > describe element/attribute content than a DTD (e.g. > you can say "this > element is a string of 3 characters" in a schema > whereas a DTD only > specifies "this element has some content"). > No, in addition to the concept of datatypes and native support for namespaces (and of course the very nice attribute that schemas are themselves XML, where DTDs are not), XML has much nicer extension mechanisms. Whereas DTD extension was done through the kludgy mechanism of entities, XML Schemas use allow you to define complex types using methods analogous to object composition and sub-typing. So, for example, you could have a type defined which contained some bare minimum amount of config info for any jboss service, and ISVs could define their own schema which extended that datatype and added config info specific to their own service. Namespaces provide a mechanism for "protecting" your type definitions, and it's possible to use the directive to add or change info for element types defined in the same namespace (for the "jboss group adds capabilities" case mentioned above). And someone mentioned an "include" mechanism: XML schemas have the directive. So for a given set of modules you could have the configuration in one big file, or split out however you like. XML Schemas are very powerful, and I think they're a big win for *specifiying* config info (whether or not the in-memory representation is DOM or something else). Dave __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.net email transport
Jason, Just out of curiosity, what would you use this for? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Jason Essington Sent: Wednesday, November 13, 2002 5:48 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] jboss.net email transport Hi all I have managed to get a fairly crude email transport working in jboss.net (It is lurking in head). I would appreciate any comments / design ideas from folks who are interested. Check the javadocs in org.jboss.net.axis.mail.MailTransportService to see how to set it up. It will currently process emails with simple soap messages (no attachments). It requires the content type to be application/soap+xml with the action attribute set to the desired service. i.e. content-type: application/soap+xml; action=SomeService The response message is returned to the sender via email. Since email doesn't really have any type of authentication framework the transport will only work with ejb's / ejb methods's that have unchecked permissions. I have been able to sign (DSA) a soap message using apache's xml-security library and have jboss.net verify the signature (I haven't submitted this handler yet, as it depends on the apache xml-security library that would have to be added to the thirdparty libs). I think this is the first step to some sort of authentication via email (and cryptographic authentication by other transports as well). but . . . I haven't figured out how to go about trusting a given signature and mapping it to a Subject. This is where I could use the help of someone with a better knowledge of jaas and JBossSX than myself. Thanks for any feedback -jason --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug in TxCapsule.java for JBoss 3.0.4
On Wednesday 13 November 2002 08:10 pm, David Jencks wrote: > What is the bug and why does this patch change anything? Why do you think > it won't cause equal and opposite bugs with other drivers? > > I haven't tested actual drivers extensively but have always assumed > isSameRM was intended to be symmetric.. > > (for all a) (for all b) (a.isSameRM(b) == b.isSameRM(a)) > > The efficacy of your patch appears to depend on this identity failing: if > other drivers have opposite failings won't this patch break them? > > > thanks > david jencks David, calling xaRes.isSameRM() for my Informix driver threw a class cast exception. I'm sorry, but I think that I no longer have this trace around. Changing it to be resources[i].isSameRM(xaRes) matches the other calls to it in TxCapsule.java. Changing it to be resources[i].isSameRM(xaRes) made it stop with the class cast exceptions. Beyond that, I have little knowledge of what actually may or may not be broken. If you or someone else would like me to help track down this problem further, I'm willing to do that. Just let me know what I should do. I can regenerate the class cast exception trace if need be. -Dan -- Dan A. Dickey [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-633876 ] Wrong Read-ahead with CMR fields
Bugs item #633876, was opened at 2002-11-05 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633876&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: Infogest (infogest) >Assigned to: Ceki Gulcu (cgu) Summary: Wrong Read-ahead with CMR fields Initial Comment: When a CMR fieds get preloaded the primkeys of the other side entity get preloaded with the same preload-group name of its corelated entity. When jboss tries to load those entities will raise an exception : unknown load group. The problem is around line 172 of JDBCLoadRelationCommand.java . It is now : relatedReadAheadCache.addFinderResults(results, readAhead); but sould be something like (improvvisation follows): relatedReadAheadCache.addFinderResults(results, cmrField.getRelatedCMRField().getReadAhead()); But I'm not sure this is the right thing to do. It can make sense to use the same read-ahead group but in that case I think this should checked during deploying (all related entity should have the same preload groups...). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=633876&group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-636920 ] JSP INCLUDE
Bugs item #636920, was opened at 2002-11-12 02:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636920&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Jeff Miner (jeff_miner) Assigned to: Nobody/Anonymous (nobody) Summary: JSP INCLUDE Initial Comment: v 3.0.4 See my previous #594563 which starksm closed. Inclusion of JSP using RequestDispatcher causes included content to jump to top of page. He claims this was fixed, yet the latest, greatest download (v 3.0.4) exhibits the same behavior. Do I need to upgrade Jetty separately? One can flush the out buffer in the JSP before including, but I need to do this in the object, not in the JSP. Why doesn't the RequestDispatcher know how to do this? -- >Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 10:58 Message: Logged In: YES user_id=592596 OK - Sorry I got hot under the collar - I'm having roughly the same discussion with Macromedia over JRun and they out and out said "it is not a bug, this is according to spec" which is just foolish. I guess I can sort of envision how the problem arises from not integrating the JSPs into the ServletEngine, but I still don't understand how the servlet can do ANY include properly if this doesn't work - that is, if the JSP servlet is up to spec, because any servlet's output would have to be properly inserted in the buffer. Why should the JSP servlet be different? I can use the workarounds, but it means an extensive rewrite. The reason things need to be done this way (in brief) is that the getOutput() method exists on many objects polymorphically and may not do an include at all, so I don't want to mess with buffers etc. and would rather not have to add params to all my method calls. FYI - This is actually a small part of a nested MVC design -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-11-14 10:27 Message: Logged In: YES user_id=44062 Hey Jeff - keep it cool OK. We are not ignoring your problem. We have analyzed it and given you some suggestions. Pretty good service for free! I agree - that it the include SHOULD work the same either way. It works for weblogic, because their JSP engine is integrated into their servlet engine. But many containers such as Jetty and Tomcat implement JSPs simply as a servlet within the container. It is not possible to simply resolve this problem with such an implementation of JSPs. The mood on the servlet JSR is that integrating JSPs with the servlet spec was a mistake and JSPs should no longer given special status within servlet containers. Why are JSPs favoured over webmacros, velocity, cocoon, etc. etc.? Hence future versions of the spec are moving away from tight integration of JSPs.If this was not the case, then I might be more inclined to jump hurdles to fix this problem. The root of the problem is a bad spec. It's not a bug, just poorly defined integration of several features. So the reality of the situation is that I think it VERY unlikey that this "bug" will be fixed by either the developers of jasper, tomcat or jetty. But, it is open source and you are free to give it a go yourself! PS. Servlets don't normally "have to know about JSP buggering, etc. in order to include them properly". You are using servlet code within a JSP and that is not normal. There are plenty of things you can break in JSPs if you start playing with the full servlet API - these are not bugs, just dangers inherent in the design of JSPs. I strongly suggest that once you have invoked a JSP, that you use JSP techniques for include etc. If you want to do servlet stuff, then do it in a servlet - not via a JSP. Better yet, get a propper MVC design going, where the servlets do the Control and JSPs to the View. regards -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 10:01 Message: Logged In: YES user_id=592596 Mr. Wilkins, I don't want to get snippy here, but I do not think there is any problem with MY code. A RequestDispatcher that dispatches to a JSP should do exactly what the tag does -- no more, no less. Servlets shouldn't have to know about JSP buffering, etc. in order to include them properly. Certainly I could pass the writer around, I can pass the PageContex around, I can flush the buffers, but these are workarounds. These are ways for me to avoid the bug. It is still a bug and should be fixed, not ignored. FYI - Weblogic has handled this properly since at least Version 4.5 -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-11-14 01:31 Message: Logged In: YES user_id=44062 OK - the problem with your code is that you have d
[JBoss-dev] [ jboss-Bugs-636920 ] JSP INCLUDE
Bugs item #636920, was opened at 2002-11-12 02:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636920&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Jeff Miner (jeff_miner) Assigned to: Nobody/Anonymous (nobody) Summary: JSP INCLUDE Initial Comment: v 3.0.4 See my previous #594563 which starksm closed. Inclusion of JSP using RequestDispatcher causes included content to jump to top of page. He claims this was fixed, yet the latest, greatest download (v 3.0.4) exhibits the same behavior. Do I need to upgrade Jetty separately? One can flush the out buffer in the JSP before including, but I need to do this in the object, not in the JSP. Why doesn't the RequestDispatcher know how to do this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-11-14 10:27 Message: Logged In: YES user_id=44062 Hey Jeff - keep it cool OK. We are not ignoring your problem. We have analyzed it and given you some suggestions. Pretty good service for free! I agree - that it the include SHOULD work the same either way. It works for weblogic, because their JSP engine is integrated into their servlet engine. But many containers such as Jetty and Tomcat implement JSPs simply as a servlet within the container. It is not possible to simply resolve this problem with such an implementation of JSPs. The mood on the servlet JSR is that integrating JSPs with the servlet spec was a mistake and JSPs should no longer given special status within servlet containers. Why are JSPs favoured over webmacros, velocity, cocoon, etc. etc.? Hence future versions of the spec are moving away from tight integration of JSPs.If this was not the case, then I might be more inclined to jump hurdles to fix this problem. The root of the problem is a bad spec. It's not a bug, just poorly defined integration of several features. So the reality of the situation is that I think it VERY unlikey that this "bug" will be fixed by either the developers of jasper, tomcat or jetty. But, it is open source and you are free to give it a go yourself! PS. Servlets don't normally "have to know about JSP buggering, etc. in order to include them properly". You are using servlet code within a JSP and that is not normal. There are plenty of things you can break in JSPs if you start playing with the full servlet API - these are not bugs, just dangers inherent in the design of JSPs. I strongly suggest that once you have invoked a JSP, that you use JSP techniques for include etc. If you want to do servlet stuff, then do it in a servlet - not via a JSP. Better yet, get a propper MVC design going, where the servlets do the Control and JSPs to the View. regards -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-14 10:01 Message: Logged In: YES user_id=592596 Mr. Wilkins, I don't want to get snippy here, but I do not think there is any problem with MY code. A RequestDispatcher that dispatches to a JSP should do exactly what the tag does -- no more, no less. Servlets shouldn't have to know about JSP buffering, etc. in order to include them properly. Certainly I could pass the writer around, I can pass the PageContex around, I can flush the buffers, but these are workarounds. These are ways for me to avoid the bug. It is still a bug and should be fixed, not ignored. FYI - Weblogic has handled this properly since at least Version 4.5 -- Comment By: Greg Wilkins (gregwilkins) Date: 2002-11-14 01:31 Message: Logged In: YES user_id=44062 OK - the problem with your code is that you have decended back into servlet land to do your include. Poor old servlets have no idea about what ever wrappers your JSP (or JSP Engine) has put around the output stream and/or writer. So the servlets are do the dispatch and the new jsp gets the outputstream and/or writer again from the response and wraps them again, without knowing about any buffering already done by your last JSP. I think that is why works, because it knows about JSP buffering & writers. You can simply do a flush before your getOutput call, or I think you can configure JSPs to do that for you (or not to buffer or something). Alternately, you could pass in the JSPs writer to your getOutput call, it could wrap the response object and it could return the writer from it's getWriter call. cheers -- Comment By: Jeff Miner (jeff_miner) Date: 2002-11-13 20:17 Message: Logged In: YES user_id=592596 Here is the basic layout of the problem **Containing Page*** <%= myObject.getOutput(request, response) %> ... *** Object public String getOutput(HttpServletRequ
[JBoss-dev] [ jboss-Bugs-636920 ] JSP INCLUDE
Bugs item #636920, was opened at 2002-11-12 02:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636920&group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Miner (jeff_miner)
Assigned to: Nobody/Anonymous (nobody)
Summary: JSP INCLUDE
Initial Comment:
v 3.0.4
See my previous #594563 which starksm closed.
Inclusion of JSP using RequestDispatcher causes
included content to jump to top of page.
He claims this was fixed, yet the latest, greatest
download (v 3.0.4) exhibits the same behavior.
Do I need to upgrade Jetty separately?
One can flush the out buffer in the JSP before
including, but I need to do this in the object, not in
the JSP. Why doesn't the RequestDispatcher know
how to do this?
--
>Comment By: Jeff Miner (jeff_miner)
Date: 2002-11-14 10:01
Message:
Logged In: YES
user_id=592596
Mr. Wilkins,
I don't want to get snippy here, but I do not think there is
any problem with MY code.
A RequestDispatcher that dispatches to a JSP should do
exactly what the tag does -- no more, no less.
Servlets shouldn't have to know about JSP buffering, etc.
in order to include them properly.
Certainly I could pass the writer around, I can pass the
PageContex around, I can flush the buffers, but these are
workarounds. These are ways for me to avoid the bug.
It is still a bug and should be fixed, not ignored.
FYI - Weblogic has handled this properly since at least
Version 4.5
--
Comment By: Greg Wilkins (gregwilkins)
Date: 2002-11-14 01:31
Message:
Logged In: YES
user_id=44062
OK - the problem with your code is that you have decended
back into servlet land to do your include. Poor old
servlets have no idea about what ever
wrappers your JSP (or JSP Engine) has put around the output
stream
and/or writer.
So the servlets are do the dispatch and the new jsp gets the
outputstream and/or writer again from the response and wraps
them
again, without knowing about any buffering already done by
your last JSP.
I think that is why works, because it knows
about JSP buffering & writers.
You can simply do a flush before your getOutput call, or I
think you can
configure JSPs to do that for you (or not to buffer or
something).
Alternately, you could pass in the JSPs writer to your
getOutput call,
it could wrap the response object and it could return the
writer from
it's getWriter call.
cheers
--
Comment By: Jeff Miner (jeff_miner)
Date: 2002-11-13 20:17
Message:
Logged In: YES
user_id=592596
Here is the basic layout of the problem
**Containing Page***
<%= myObject.getOutput(request, response) %>
...
*** Object
public String getOutput(HttpServletRequest request,
HttpServletResponse response) {
RequestDispatcher dispatch =
context.getRequestDispatcher("someJSP.jsp");
try {
dispatch.include(request, response);
} catch(Exception e){}
return "";
*
I am beginning to understand the extent of the
mishmosh of writers, etc. but it seems to me that the
encapsulating objects should handle these issues.
My point is essentially that a call to
RequestDispatcher.include() really ought to do exactly
the same thing as a . It doesn't, though.
--
Comment By: Greg Wilkins (gregwilkins)
Date: 2002-11-13 00:20
Message:
Logged In: YES
user_id=44062
Can you give us a pair of JSPs that exhibit this problem?
The following URL to the jetty demo site shows that it does
work at least for all the examples that I have.
http://jetty.mortbay.org/jetty/dispatch/include/snoop.jsp
Remember that request dispatching, JSPs, writers and
outputstreams all form a complex little mishmash of
buffering vs flushing (which slows
down performance a lot). You may have some content that
you think has been written to the response before the
include, but it is actually still in a JSP or writer buffer
somewhere (outside the control of Jetty!). I think JSPs do
have some mechanisms for controlling this.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=636920&group_id=22866
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Metadata Service
Hi, have any one of you looked at XmlBlaster? (www.xmlBlaster.org). I guess it could really work as a central XmlRepository. XmlBlaster is an XML based MOM. You publish your XML to it and it will save it in an Xml DOM tree, even persist it a RDMB or Xincice. You can then subscribe to event with an XPath expression (or do a synchronous get (with an XPath). Ok. You can not just subsribe to one element, thats true, but you can subscribe on a "domain" or "config", say MyMessageDrivenBean and get any update notifications for that XML config. Or you could do a get(//x/y/port) (pseudocode!) and get all configs wich contains that element. There are a lot more to XmlBlaster (I have done the JBoss integration thats currently is available in XmlBlaster ;.)) Well, just a thought. //Peter On 13 Nov, Bill Burke wrote: > 1. I'm not talking about a central config file...Components register their > XML with this service. MBean, EJB, whatever... > > 2. You know what XPATHs are right? If not, look them up. They are really > cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. > What's not supported, which we would have to write, would be the ability to > register for change notifications via an XPATH. > > Other ideas: > - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. > Services/components registered as listening for changes, recieve > notification. > > - JMX console needs an additional XML editor for MBean attributes that are > XML elements. > > - This sort of centralized service allows you to query, via XPATHS, for all > components that have a "port" attribute for instance. Allows you to do > global things on configuration when you don't know the actual components > that have that type of attribute > > Another thing about configuration I wanted to have is the concept of > Configuration Domains. A component would get configuration by searching a > set of chained configuration domains. > > invocation domain->instance domain->component domain->app server > domain->cluster domain etc... > > So, when a component needs config information, it looks it up via the chain. > Any domain in the chain can override a config value. As the chain is > traversed, if the config info is not there, it searches farther up the > chain. > > This would allow us to have a layered way of obtaining default config > information, or overriding existing configuration at different levels at > different times. > > Bill > > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Matt >> Munz >> Sent: Wednesday, November 13, 2002 1:26 PM >> To: [EMAIL PROTECTED] >> Subject: RE: [JBoss-dev] Metadata Service >> >> >> Dain, >> >> > Meta data for an invocation. >> >> I assume you refer here to EJB/servlet invocations. >> >> Just out of curiosity, how is that metadata currently stored? >> >> - Matt >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain >> Sundstrom >> Sent: Wednesday, November 13, 2002 1:13 PM >> To: [EMAIL PROTECTED] >> Subject: Re: [JBoss-dev] Metadata Service >> >> >> Meta data for an invocation. What are the tx attributes? What is the >> security manager? What are the required roles? What is the readahead >> configuration? That kind of data. >> >> -dain >> >> Matt Munz wrote: >> > Dain/Bill/Scott, >> > >> > Could you clarify this? Metadata for what data? Are you referring to >> > MBeanInfo, or something else? >> > >> > - Matt >> > >> > -Original Message- >> > From: [EMAIL PROTECTED] >> > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain >> > Sundstrom >> > Sent: Wednesday, November 13, 2002 12:52 PM >> > To: [EMAIL PROTECTED] >> > Subject: Re: [JBoss-dev] Metadata Service >> > >> > >> > Bill Burke wrote: >> > >> >>Dain and I were IMing. He said Scott was thinking about a MetaData >> >>service... >> >> >> >>My idea for a MetaData/Configuration service would be the ability to >> >>register for callbacks based on XPATHS. So, all config of >> jboss would be >> >>stored in one big XML Document. Components insert their config >> there, and >> >>register for callbacks on this config via XPATHS. So, this >> config can be >> >>managed centrally, yet, components can easily be notified with >> changes via >> > >> > a >> > >> >>simple mechanism. >> > >> > >> > I didn't know you could do that. What spec/library is this in? I want >> > to read it. >> > >> > Scott and I were really only talking about use. We need something like >> > this for component, application, and domain data, but we didn't get into >> > the actually implementation. We just decided to have an metadata loader >> > interceptor and a metadata loader interface for the interceptor to call. >> > The goal is to create a place to put a good metadata service, but >> > those details are for another day (one step at a t
[JBoss-dev] Re: [jetty-discuss] 404 Prevention
one more thought
This is a little complicated by session state and sticky load-balancing.
I guess in this case, if a redeployment is occurring the LB will either
end up waiting on the context to reappear and all it's sticky requests
will be queued, or the context will remain listed in the management page
and so the LB will continue to route requests to the same node and they
will be queued. This would only be useful if session state is preserved
on this node. If it has already been migrated to another then you would
want the context to dissappear and no requests buffered.
So, it looks like we need both, request buffering via some sort of
invocation valve AND more intelligent load-balancing, along with the
redeployment thing.
Jules
Jules Gosnell wrote:
Hi Dennis,
I've thought about this too.
I thought about "invocation valves" (buffering up requests until you are
ready to process them - an idea from the JBoss camp), but then ended up
thinking more like you.
Invocation valves are probably the natural way to go in e.g. standalone
Jetty. However, in a clustered situation, I see no reason to hold up the
request is another node can process it.
Firstly, a Listener should only be started if there is something to
serve - this means that the load-balancer will look elsewhere whilst
there is nothing available on a node. Taken to the logical conclusion
this would mean starting the listener after the first app is deployed,
stopping it if the number of apps ever falls below one and starting it
again when the number rises above 0.
Secondly, as you suggest, the load-balancer should be able to check for
the availability of an individual context. Thus, when the Listener is
active, and more than one app deployed, it will only forward requests
for which it knows an application is waiting. (I believe BIGIP can be
configured to look for a particular string in a particular page - this
would be perfect, as it could either look for e.g. your apps front page,
or a mention of a particular context in an admin page which listed all
current deployments).
There is one further issue, which I think JSR88 (or 77, I always get
them muddled) suggests as an option - the distinction between
{undeploy();deploy();} and redeploy(). If requests are going to be
stored up during a redeployment then the container needs to know that a
redeployment is occurring and not simply that a webapp is being
undeployed, with no guarantee that it will ever be deployed again.
I have discussed this with Greg, and I think Jetty is moving in that
direction although I am not sure about specifics.
How does that sound ?
Jules
Dennis Cartier wrote:
Hello Everyone,
I recently asked about preventing 404's when a webapp is being redeployed,
or JBoss is being booted. You can read my original post at:
http://www.jboss.org/forums/thread.jsp?forum=64&thread=24532
Sacha, suggested I discuss it on the Jetty list.
I have given this a fair bit of thought recently. I see this as 2 seperate
yet related situations. When a webapp is being redeployed, or when it (or
JBoss) is not running.
The best possbile solution I could come up with, is to modify the AJP13 code
to add a method of querying the availability of a particular context/URI of
a running Jetty instance. In my situation, my loadbalancer (mod_Backhand),
allows me to select a candidate server based on custom candidacy functions.
So if I were able to query Jetty and ask each node if it could serve a
particular URI, that would allow me to eliminate the nodes that will 404
becasue of a redeploy or missing webapp.
This is how I currently make sure JBoss is running before sending a request
to the AJP port. I have a function that connects to the 8009 port and skips
any servers that do no have that port open.
What Sacha said got me to thinking this might be solvable another way, and
work out better in the long run. If altering the "invocation-valve" could
fix the 404 on redeploy, then all that would be left is the ~30 seconds or
so while the AJP port is open (so mod_backhand starts forwarding request
here), but the webapps are not deployed yet. If the order could be altered,
so that the webapps were deployed first, then the AJP listener, this would
work for me.
Hmmm, what about removing the AJP listener config from the jboss-service.xml
file and having a webapp (the last one to load), activate it. Could this be
done? If so how?
Thanks
Dennis Cartier
---
The man with tremendous wealth is a paradox: he has to be smart enough to
get it, yet stupid enough to want it. - Chesterton
For the latest information about Jetty, please see http://jetty.mortbay.org
To alter your subscription to this list goto http://groups.yahoo.com/group/jetty-discuss
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This email has been scanned for all viruses by the MessageLabs SkyScan
service. Fo
[JBoss-dev] Re: [jetty-discuss] 404 Prevention
Hi Dennis,
I've thought about this too.
I thought about "invocation valves" (buffering up requests until you are
ready to process them - an idea from the JBoss camp), but then ended up
thinking more like you.
Invocation valves are probably the natural way to go in e.g. standalone
Jetty. However, in a clustered situation, I see no reason to hold up the
request is another node can process it.
Firstly, a Listener should only be started if there is something to
serve - this means that the load-balancer will look elsewhere whilst
there is nothing available on a node. Taken to the logical conclusion
this would mean starting the listener after the first app is deployed,
stopping it if the number of apps ever falls below one and starting it
again when the number rises above 0.
Secondly, as you suggest, the load-balancer should be able to check for
the availability of an individual context. Thus, when the Listener is
active, and more than one app deployed, it will only forward requests
for which it knows an application is waiting. (I believe BIGIP can be
configured to look for a particular string in a particular page - this
would be perfect, as it could either look for e.g. your apps front page,
or a mention of a particular context in an admin page which listed all
current deployments).
There is one further issue, which I think JSR88 (or 77, I always get
them muddled) suggests as an option - the distinction between
{undeploy();deploy();} and redeploy(). If requests are going to be
stored up during a redeployment then the container needs to know that a
redeployment is occurring and not simply that a webapp is being
undeployed, with no guarantee that it will ever be deployed again.
I have discussed this with Greg, and I think Jetty is moving in that
direction although I am not sure about specifics.
How does that sound ?
Jules
Dennis Cartier wrote:
Hello Everyone,
I recently asked about preventing 404's when a webapp is being redeployed,
or JBoss is being booted. You can read my original post at:
http://www.jboss.org/forums/thread.jsp?forum=64&thread=24532
Sacha, suggested I discuss it on the Jetty list.
I have given this a fair bit of thought recently. I see this as 2 seperate
yet related situations. When a webapp is being redeployed, or when it (or
JBoss) is not running.
The best possbile solution I could come up with, is to modify the AJP13 code
to add a method of querying the availability of a particular context/URI of
a running Jetty instance. In my situation, my loadbalancer (mod_Backhand),
allows me to select a candidate server based on custom candidacy functions.
So if I were able to query Jetty and ask each node if it could serve a
particular URI, that would allow me to eliminate the nodes that will 404
becasue of a redeploy or missing webapp.
This is how I currently make sure JBoss is running before sending a request
to the AJP port. I have a function that connects to the 8009 port and skips
any servers that do no have that port open.
What Sacha said got me to thinking this might be solvable another way, and
work out better in the long run. If altering the "invocation-valve" could
fix the 404 on redeploy, then all that would be left is the ~30 seconds or
so while the AJP port is open (so mod_backhand starts forwarding request
here), but the webapps are not deployed yet. If the order could be altered,
so that the webapps were deployed first, then the AJP listener, this would
work for me.
Hmmm, what about removing the AJP listener config from the jboss-service.xml
file and having a webapp (the last one to load), activate it. Could this be
done? If so how?
Thanks
Dennis Cartier
---
The man with tremendous wealth is a paradox: he has to be smart enough to
get it, yet stupid enough to want it. - Chesterton
For the latest information about Jetty, please see http://jetty.mortbay.org
To alter your subscription to this list goto http://groups.yahoo.com/group/jetty-discuss
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MetaDataRepository Proposal
onsdagen den 13 november 2002 kl 23.56 skrev Dain Sundstrom:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
maybe add
void setJDBCBackend(url, u, p);
void serConf(path);
Basically this is a plain old map with a possible parent. Exactly how
this is implemented, I really don't care; it is a detail. I'm going
to write one backed by a HashMap, and we can throw it away later.
For attribute keys, I'm thinking of things like MethodTxAttribute that
has a method object inside of it. Alternatively, we could lookup by
method and get another map back. I don't like that one because it
would be too hard to manage with any user interface. There are a
million ways to skin this cat. Does anyone have any ideas on how to
organize the keys?
The final problem is how do we keep this repository in sync with the
physical store. For this I would guess we need some sort of listener
or notification system. This isn't one of my current problems so I
haven't thought about it too much.
hmmm ... me thinks hsqldb is way underused as a admin tool in jboss
today ... hehe ... i am biased ... yes ...
hsqldb has a pluggable listener called Trigger.class with one method
public void fire(String trigName, String tabName, Object row[]);
so when an jboss instance starts ... it would ofcource need some core
configuration either as a xml-file or class.ser ? then one could start
a "jdbc:hsqldb:hsql:." instance and go get configuration - also when db
changes it will notify other db's throughout *hsqldbr and there is our
"distributed metadata repository" ... all sql, all libs in there
already ... cool ...
/peter_f
*hsqldbr(eplicated)
http://www.javagroups.com/javagroupsnew/docs/hsqldbr/design.htm
***
/**
* Sample code for use of triggers in hsqldb.
*
* SQL to invoke is:
* CREATE TRIGGER triggerSample BEFORE|AFTER INSERT|UPDATE|DELETE
* ON myTable [FOR EACH ROW] [QUEUE n] [NOWAIT] CALL
"myPackage.trigClass"
*
* This will create a thread that will wait for its firing event to
occur;
* when this happens, the trigger's thread runs the 'trigClass.fire'
* Note that this is still in the same Java Virtual Machine as the
* database, so make sure the fired method does not hang.
*
* There is a queue of events waiting to be run by each trigger thread.
* This is particularly useful for 'FOR EACH ROW' triggers, when a large
* number of trigger events occur in rapid succession, without the
trigger
* thread getting a chance to run. If the queue becomes full, subsequent
* additions to it cause the database engine to suspend awaiting space
* in the queue. Take great care to avoid this situation if the trigger
* action involves accessing the database, as deadlock will occur.
* This can be avoided either by ensuring the QUEUE parameter makes a
large
* enough queue, or by using the NOWAIT parameter, which causes a new
* trigger event to overwrite the most recent event in the queue.
* The default queue size is 1024.
*
* Ensure that "myPackage.trigClass" is present in the classpath which
* you use to start hsql.
*
* If the method wants to access the database, it must establish
* a JDBC connection.
*
* When the 'fire' method is called, it is passed the following
arguments:
* fire (String trigName, String tabName, Object row[])
*
* where 'row' represents the row acted on, with each column being
* a member of the array. The mapping of row classes to database
* types is specified in /doc/hsqlSyntax.html#Datatypes
*
*
* For implementation at a later date:
* 1. jdbc:default:connection: URL for JDBC trigger method
connections to
* the database.
* 2. arguments to the trigger method.
* 3. Because they run in different threads, it is possible for an
* 'after' trigger to run before its corresponding 'before' trigger;
* the acceptability of this needs to be investigated.
*
* @author Peter Hudson
* @version 1.7.0
*/
public class TriggerSample implements org.hsqldb.Trigger {
/**
* fire method declaration
* This is a sample implementation that simply prints
information
* about the trigger firing.
*
* @param trigName
* @param tabName
* @param row
*/
public void fire(String trigName, String tabName, Object row[]) {
System.out.println(trigName + " trigger fired on " + tabName);
System.out.print("col 0 value <");
System.out.print(row[0]);
System.out.println(">");
// you can cast row[i] given your knowledge of what the table
// format is.
}
}
/**
*
*
* test SQL
* CREATE CACHED TABLE trig_test (int_field integer)
* CREATE TRIGGER ins_before BEFORE INSERT ON trig_test CALL
"org.hsqldb.sample.TriggerSample"
* CREATE TRIGGER ins_after AFTER INSERT ON trig_test CALL
"org.hsqldb.sample.TriggerSample"
* CREATE TRIGGER upd_before
Re: [JBoss-dev] Metadata Service
hi, On Wed, 2002-11-13 at 22:36, Dain Sundstrom wrote: > > (Don't know much about XML Schemasmaybe they address these issues?) > > This is what XML name spaces are for. If in ISV wants to add more > config options to jboss, if jboss wants to add new options to the spec > ejb-jar.xml file, we just put it in a different name space. Of course > this only works with a schema because dtd don't understand name spaces. hu? it has always been my understanding ( i might be completely wrong/off track of course :), that a namespace is tied to a specific DTD - so that you can have an XML document which contains more than 1 DTD that are referenced by the namespace of the elements. from my current understanding, XML Schema is only a more specific way to describe element/attribute content than a DTD (e.g. you can say "this element is a string of 3 characters" in a schema whereas a DTD only specifies "this element has some content"). Regards, Christian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-630665 ] CMR within one transaction
Bugs item #630665, was opened at 2002-10-29 21:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630665&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Leon Doud (ldoud) Assigned to: Alexey Loubyansky (loubyansky) Summary: CMR within one transaction Initial Comment: When two objects are created in the same transaction setting a relation between these objects fails. There is no exception given, but the foreign key is NULL. The test case submitted uses one session bean with two almost identical methods. The only difference is that one method has the transaction type of "Required" and the other has a type of "NotSupported". The test case for the required transaction fails, while the other test case passes. This test only covers one-to-many bidirectional relationships. It was tested against the latest CVS code for Branch_3_0, using Windows 2000 and JDK 1.4.0. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-11-13 21:39 Message: Logged In: YES user_id=543482 This is fixed in HEAD, 3.2, 3.0. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-11-09 15:48 Message: Logged In: YES user_id=543482 Dain, sorry for confusion. The key is of type CustomerPK that just wraps the int id. So, it's ok according to the spec but zero values will be represented as null anyway. Also, for me, the test attached doesn't work with zero values for Required or NotSupported either. But works for both with non-zero values for id, though, I tested against HEAD on Win2K, jdk1.3.1. alex alex -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-09 00:20 Message: Logged In: YES user_id=251431 A primitive int is not allowed for a primary key. The spec requires an Object, as the primary key is returned from a method that returns an Object. The verifier should have thrown an error. Did you turn off the verifier? If not, this is a verifier bug. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-11-08 23:50 Message: Logged In: YES user_id=543482 I don't understand why it works for NotSupported. The problem is that, you are using 'int' for primary key with zero value. Currently, foreign keys can't be 'NOT NULL'. On the other hand, 'int' can't be null, so null equivalent is 0. Thus, relationships are not set. Try the following: 1. use int for pk but non-zero values; 2. use java.lang.Integer instead of int. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630665&group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
