[JBoss-dev] [ jboss-Bugs-636227 ] testsuite generally fails to complete
Bugs item #636227, was opened at 2002-11-10 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=636227group_id=22866 Category: JBossTest Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Chris Kimpton (kimptoc) Assigned to: Adrian Brock (ejort) Summary: testsuite generally fails to complete Initial Comment: Hi, I have run the full testsuite (testsuite/build.xml, target test) several times but it rarely completes. The machine is doing nothing else - 2 x 1.3GHZ cpu, 1GB ram - left run for 15 hours plus. Redhat 7.2, sun jdk1.3.1_06 Tried using kill -SIGHUP, but it seemed to kill the JVM rathing giving a thread dump. Regards, Chris -- Comment By: Chris Kimpton (kimptoc) Date: 2002-11-13 08:57 Message: Logged In: YES user_id=39204 But, since it generally fails - I ran it again, with a fresh checkout and it hung! Here are the thread dumps: http://jboss.kimptoc.net/jboss-all/build/cronjob_test.log http://jboss.kimptoc.net/jboss- all/build/output/testbuild/server/default/server_thread_dump.log Hope this helps, Chris -- Comment By: Chris Kimpton (kimptoc) Date: 2002-11-12 20:12 Message: Logged In: YES user_id=39204 and then the testsuite completed ok - doh... -- Comment By: Chris Kimpton (kimptoc) Date: 2002-11-12 19:38 Message: Logged In: YES user_id=39204 [I had to restart it and run them manually] Here is the server thread dump: Full thread dump: Thread-111 prio=1 tid=0x549948e0 nid=0x769d runnable [0x562ff000..0x562ff870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-110 prio=1 tid=0x4f365980 nid=0x769c runnable [0x55eff000..0x55eff870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-109 prio=1 tid=0x4e28d318 nid=0x769b runnable [0x55427000..0x55427870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-108 prio=1 tid=0x4d0b64f0 nid=0x769a runnable [0x54e4f000..0x54e4f870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-107 prio=1 tid=0x4d09baa8 nid=0x7699 runnable [0x4f062000..0x4f062870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) UIL Worker-18 prio=1 tid=0x8a61c88 nid=0x7666 runnable [0x56eff000..0x56eff870 ] at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:463) at java.net.ServerSocket.implAccept(ServerSocket.java:238) at java.net.ServerSocket.accept(ServerSocket.java:217) at org.jboss.mq.il.uil.UILServerILService.run(UILServerILService.java:16 8) at java.lang.Thread.run(Thread.java:479) UIL Worker-17 prio=1 tid=0x8a47c48 nid=0x7664 runnable [0x56cff000..0x56cff870 ] at
[JBoss-dev] [ jboss-Bugs-636227 ] testsuite generally fails to complete
Bugs item #636227, was opened at 2002-11-10 16:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=636227group_id=22866 Category: JBossTest Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Chris Kimpton (kimptoc) Assigned to: Adrian Brock (ejort) Summary: testsuite generally fails to complete Initial Comment: Hi, I have run the full testsuite (testsuite/build.xml, target test) several times but it rarely completes. The machine is doing nothing else - 2 x 1.3GHZ cpu, 1GB ram - left run for 15 hours plus. Redhat 7.2, sun jdk1.3.1_06 Tried using kill -SIGHUP, but it seemed to kill the JVM rathing giving a thread dump. Regards, Chris -- Comment By: Adrian Brock (ejort) Date: 2002-11-13 11:03 Message: Logged In: YES user_id=9459 Hi Chris, Ant is asleep waiting for the test to complete. The server looks asleep as well. So that only leaves the test itself. Can you take a threaddump of that. Also, on 1.3 you have to add -Xdebug to the java command to show what objects are locked. The part I don't understand is that JUnit should time-out the test and kill the process? Regards, Adrian -- Comment By: Chris Kimpton (kimptoc) Date: 2002-11-13 08:57 Message: Logged In: YES user_id=39204 But, since it generally fails - I ran it again, with a fresh checkout and it hung! Here are the thread dumps: http://jboss.kimptoc.net/jboss-all/build/cronjob_test.log http://jboss.kimptoc.net/jboss- all/build/output/testbuild/server/default/server_thread_dump.log Hope this helps, Chris -- Comment By: Chris Kimpton (kimptoc) Date: 2002-11-12 20:12 Message: Logged In: YES user_id=39204 and then the testsuite completed ok - doh... -- Comment By: Chris Kimpton (kimptoc) Date: 2002-11-12 19:38 Message: Logged In: YES user_id=39204 [I had to restart it and run them manually] Here is the server thread dump: Full thread dump: Thread-111 prio=1 tid=0x549948e0 nid=0x769d runnable [0x562ff000..0x562ff870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-110 prio=1 tid=0x4f365980 nid=0x769c runnable [0x55eff000..0x55eff870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-109 prio=1 tid=0x4e28d318 nid=0x769b runnable [0x55427000..0x55427870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-108 prio=1 tid=0x4d0b64f0 nid=0x769a runnable [0x54e4f000..0x54e4f870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) Thread-107 prio=1 tid=0x4d09baa8 nid=0x7699 runnable [0x4f062000..0x4f062870] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at java.io.BufferedInputStream.fill(BufferedInputStream.java:181) at java.io.BufferedInputStream.read(BufferedInputStream.java:199) at java.io.DataInputStream.readInt(DataInputStream.java:333) at org.hsqldb.ServerConnection.run(Unknown Source) at java.lang.Thread.run(Thread.java:479) UIL Worker-18 prio=1 tid=0x8a61c88 nid=0x7666 runnable
[JBoss-dev] [ jboss-Bugs-637730 ] client-server JNDI lookup fails
Bugs item #637730, was opened at 2002-11-13 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637730group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marko Strukelj (mstruk) Assigned to: Nobody/Anonymous (nobody) Summary: client-server JNDI lookup fails Initial Comment: This is an issue on JBoss 3.0.4 only. JBoss 3.0.3 works fine. If jboss is restarted all remote objects become invalid - this is perfectly normal. Any automatic recovery of remote objects would then have to do something like: InitialContext ctx = new InitialContext(); MyServiceHome home = (MyServiceHome)ctx.lookup (MyService); sess = home.create(); The problem is that ctx.lookup returns null if jboss has been restarted. It can return null several times and then suddenly return home interface. Or sometimes it will always return null no matter how many times you try. It does not throw any exception it just returns null. Only restart of the client application helps. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637730group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-637759 ] NPE attempting to re-deploy war file
Bugs item #637759, was opened at 2002-11-13 13:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637759group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: david (davidregan) Assigned to: Scott M Stark (starksm) Summary: NPE attempting to re-deploy war file Initial Comment: OS: Windows 2000 JDK: 1.4.0 Jboss version V3.0.3 Running jboss from eclipse. Edit any file and deploy. jboss attempts to perform hot redeploy and fails. Fails every time. I would say this line from the log file says it all: Deleting catalina work dir: null Trace from log: 2002-11-08 14:26:18,687 INFO [org.jboss.web.localhost.Engine] StandardHost [localhost]: Removing web application at context path /microsites 2002-11-08 14:26:18,687 DEBUG [org.jboss.web.catalina.EmbeddedCatalinaService41] Deleting catalina work dir: null 2002-11-08 14:26:18,687 ERROR [org.jboss.deployment.MainDeployer] Undeployment failed: file:/C:/Applications/jboss-3.0.3_tomcat- 4.1.12/server/default/deploy/microsites.war org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (java.lang.NullPointerException) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:355) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:469) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:443) at org.jboss.deployment.MainDeployer.shutdown (MainDeployer.java:331) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl$ShutdownHook.shut downDeployments(ServerImpl.java:717) at org.jboss.system.server.ServerImpl$ShutdownHook.shut down(ServerImpl.java:700) at org.jboss.system.server.ServerImpl$ShutdownHook.run (ServerImpl.java:688) Caused by: java.lang.NullPointerException at org.jboss.util.file.Files.delete(Files.java:39) at org.jboss.web.catalina.EmbeddedCatalinaService41.perfo rmUndeploy(EmbeddedCatalinaService41.java:330) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:345) ... 12 more Trace from console: 13:09:29,906 INFO [Engine] StandardHost[localhost]: Removing web application at context path /microsites 13:09:30,406 ERROR [MainDeployer] Undeployment failed: file:/C:/Applications/jboss-3.0.3_tomcat- 4.1.12/server/default/deploy/microsites.war org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (java.lang.NullPointerException) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:355) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:469) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:443) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:438) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.undeploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner. undeploy(URLDeploymentScanner.java:457) at org.jboss.deployment.scanner.URLDeploymentScanner. scan(URLDeploymentScanner.java:552) at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.doScan (AbstractDeploymentScanner.java:212) at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.loop (AbstractDeploymentScanner.java:225) at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.run (AbstractDeploymentScanner.java:202) Caused by: java.lang.NullPointerException at org.jboss.util.file.Files.delete(Files.java:39) at org.jboss.web.catalina.EmbeddedCatalinaService41.perfo rmUndeploy(EmbeddedCatalinaService41.java:330) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:345) ... 17 more
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_articleid=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
RE: [JBoss-dev] Metadata Service
Is this ala the Weblogic central config file, or just a secondary file created as the kernel accepts new components and started from scratch on each startup (I hope)? -Original Message- From: Bill Burke [mailto:bill;jboss.org] Sent: Wednesday, November 13, 2002 11:08 AM To: Jboss-Dev Subject: [JBoss-dev] Metadata Service 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
[JBoss-dev] [ jboss-Bugs-621270 ] invalid SQL is generated for MSSQL
Bugs item #621270, was opened at 2002-10-10 07:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=621270group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 8 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: invalid SQL is generated for MSSQL Initial Comment: I have the following EJBQL expression: SELECT DISTINCT OBJECT(c) FROM StoreCategory c, IN (c.locales) l WHERE l.code=?1 AND c.images IS NOT EMPTY which for postgresql translates into: Executing SQL: SELECT DISTINCT t0_c.id FROM storecategory t0_c, mmslocale t1_l, storecategory_locales_m_18q3els t2_c_locales_RELATION_TABLE, mmsimage t3_c_images, mmsimage_storecategorie_1diogue t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND TRUE) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) and executes normally. But for MSSQL I get: SELECT DISTINCT t0_c.id FROM StoreCategory t0_c, MMSLocale t1_l, StoreCategory_locales_MMSLocale_storeCategories t2_c_locales_RELATION_TABLE, MMSImage t3_c_images, MMSImage_storeCategories_StoreCategory_images t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND 1) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) which leads to java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Line 1: Incorrect syntax near ')'. Why not using AND 1=1 instead of AND 1? -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 11:26 Message: Logged In: YES user_id=251431 You're right. Alex is going to put in '(1=1)' instead of the true mapping for IS NOT EMPTY. I think this will work for a temporary solution, but I now believe more than ever that the current IS NOT EMPTY generated SQL is broken. I bet the following query will not generate the expected results: SELECT OBJECT(o) FROM order o WHERE o.lineItems IS NOT EMPTY OR o.total 0 I bet the current implementation will generate something that works more like an AND instead of an OR. The IS EMPTY operator was really designed for a sub query and the default should be to generate a sub query regardless of the presence of a NOT. Of course this creates a problem for mySQL, so we'll have to code around that. -- Comment By: Jeremy Boynes (jboynes) Date: 2002-10-31 13:16 Message: Logged In: YES user_id=378919 I might be confused here but I don't think the IS NOT EMPTY clause should be using the value from true-mapping The root of this seems to be the lack of a boolean datatype in standard SQL allowing vendors to implement it differently (e.g. as NUMBER(1) in Oracle, BIT in MS SQL, BOOLEAN in PostgreSQL). The true-mapping parameter is needed to map Java Boolean values to a literal of whatever datatype is being used in the db. SQL does define boolean operators but they take boolean expressions and as there are no standard boolean literals you can't write AND TRUE. The current JDBCEJBQLCompiler needs to do this for the IS NOT EMPTY clause. This can't be the value defined by true-mapping for assignment as, strictly, that is not a boolean expression (except for db's like PostgreSQL that have such an extension). Instead it should be a SQL boolean expression e.g. (1=1) Three solutions come to mind: * Make the JDBCEJBQLCompiler smarter so it doesn't generate the AND clause at all for IS NOT EMPTY * Add a new entry to the metadata allowing a boolean expression evaluating to true to be defined per database. * Have JDBCEJBQLCompiler emit a constant SQL expression for the IS NOT EMPTY case: (1=1) works for any database I can think of even if it looks ugly. This seems simplest (one line change to JDBCEJBQLCompiler) With any of these, the true-mapping for MS SQL should remain as 1 for compatibility with BIT columns. Unlike MySQL, in MS SQL BIT is not comptible with boolean expressions so select * from x where aBitColumn = (1=1) insert x values((1=1)) update x set aBitColumn = (1=1) all fail -- Comment By: Dirk M. Sohn (dsohn) Date: 2002-10-21 15:03 Message: Logged In: YES user_id=595100 He was right due to my tests. I had the same problem with a NOT EMPTY over a relation and MS SQLSERVER 2000. JBoss-3.0.0 generated AND (TRUE) JBoss-3.0.3 genetared AND (1) but AND (1=1) does the work. I changed true-mappping in standardjbosscmp-jdbc.xml to type-mapping nameMS SQLSERVER2000/name true-mapping(1=1)/true-mapping and it works
[JBoss-dev] [ jboss-Bugs-637759 ] NPE attempting to re-deploy war file
Bugs item #637759, was opened at 2002-11-13 05:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637759group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole Status: Closed Resolution: Duplicate Priority: 5 Submitted By: david (davidregan) Assigned to: Scott M Stark (starksm) Summary: NPE attempting to re-deploy war file Initial Comment: OS: Windows 2000 JDK: 1.4.0 Jboss version V3.0.3 Running jboss from eclipse. Edit any file and deploy. jboss attempts to perform hot redeploy and fails. Fails every time. I would say this line from the log file says it all: Deleting catalina work dir: null Trace from log: 2002-11-08 14:26:18,687 INFO [org.jboss.web.localhost.Engine] StandardHost [localhost]: Removing web application at context path /microsites 2002-11-08 14:26:18,687 DEBUG [org.jboss.web.catalina.EmbeddedCatalinaService41] Deleting catalina work dir: null 2002-11-08 14:26:18,687 ERROR [org.jboss.deployment.MainDeployer] Undeployment failed: file:/C:/Applications/jboss-3.0.3_tomcat- 4.1.12/server/default/deploy/microsites.war org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (java.lang.NullPointerException) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:355) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:469) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:443) at org.jboss.deployment.MainDeployer.shutdown (MainDeployer.java:331) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl$ShutdownHook.shut downDeployments(ServerImpl.java:717) at org.jboss.system.server.ServerImpl$ShutdownHook.shut down(ServerImpl.java:700) at org.jboss.system.server.ServerImpl$ShutdownHook.run (ServerImpl.java:688) Caused by: java.lang.NullPointerException at org.jboss.util.file.Files.delete(Files.java:39) at org.jboss.web.catalina.EmbeddedCatalinaService41.perfo rmUndeploy(EmbeddedCatalinaService41.java:330) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:345) ... 12 more Trace from console: 13:09:29,906 INFO [Engine] StandardHost[localhost]: Removing web application at context path /microsites 13:09:30,406 ERROR [MainDeployer] Undeployment failed: file:/C:/Applications/jboss-3.0.3_tomcat- 4.1.12/server/default/deploy/microsites.war org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (java.lang.NullPointerException) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:355) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:469) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:443) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:438) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.undeploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner. undeploy(URLDeploymentScanner.java:457) at org.jboss.deployment.scanner.URLDeploymentScanner. scan(URLDeploymentScanner.java:552) at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.doScan (AbstractDeploymentScanner.java:212) at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.loop (AbstractDeploymentScanner.java:225) at org.jboss.deployment.scanner.AbstractDeploymentScan ner$ScannerThread.run (AbstractDeploymentScanner.java:202) Caused by: java.lang.NullPointerException at org.jboss.util.file.Files.delete(Files.java:39) at org.jboss.web.catalina.EmbeddedCatalinaService41.perfo rmUndeploy(EmbeddedCatalinaService41.java:330) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:345) ... 17 more
[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=detailatid=376685aid=637880group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None 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 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637880group_id=22866 --- 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
RE: [JBoss-dev] Metadata Service
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 time). -dain --- 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:
[JBoss-dev] [ jboss-Bugs-637934 ] CMR add overpopulates read ahead cache
Bugs item #637934, was opened at 2002-11-13 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Bonham (bonhamcm) Assigned to: Nobody/Anonymous (nobody) Summary: CMR add overpopulates read ahead cache Initial Comment: Using JBoss 3.2.0beta with Dain's Unidirectional performance patch, Sun JDK 1.3.1_03 on both Win2K and RedHat Linux 7.3. Given two local CMP entity beans in a CMR (unidirectional or bidirectional): Order (M) -- (1) Lineitem. When a new Lineitem is created with a relationship to an Order, all the Order's related Lineitems (siblings of the new one) are added to the read ahead cache without a limit. I've attached a testcase that can be integrated with the CMP2/Commerce Testsuite as well as an insert script for one Order and 1 related Lineitems. There are no asserts, but the log will show that all 1 siblings are loaded into the read ahead cache. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 --- 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
[JBoss-dev] [ jboss-Feature Requests-637933 ] INTERSECT-support
Feature Requests item #637933, was opened at 2002-11-13 20:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376688aid=637933group_id=22866 Category: JBossCMP Group: v4.0 Status: Open Resolution: None Priority: 5 Submitted By: Marius Kotsbak (mkotsbak) Assigned to: Nobody/Anonymous (nobody) Summary: INTERSECT-support Initial Comment: which postgresql, oracle, DB2 and sql-92 (intermed level) supports. UNION and EXCEPT should also be supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376688aid=637933group_id=22866 --- 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
RE: [JBoss-dev] Metadata Service
Dain, Please excuse my ignorance. I'm a bit JMX-centric at the moment. I see an org.jboss.mx.server.Invocation that doesn't seem to know about / relate to org.jboss.invocation.Invocation. Obviously the names are the same. Is there any deeper relationship? When I hear metadata JBoss in the same sentence, I think of JMX MBeanInfo. Since I recently wrote some code to facilitate MBeanInfo persistence, I'm interested in any changes to the way MBeanInfo is stored in the server. Is this related at all? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 2:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Matt Munz wrote: Dain, Meta data for an invocation. I assume you refer here to EJB/servlet invocations. No, I mean JBoss invocation. It doesn't matter if it an EJB, servlet, JMS message... and org.jboss.invocation.Invocation will do. Just out of curiosity, how is that metadata currently stored? Scattered across all the code. Most of it is in the container and interceptors. The big problems are the data is all static for the life of the container, and there is no good place to put defaults for an entire application or domain. -dain --- 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
[JBoss-dev] [ jboss-Bugs-637940 ] NamingService doesn't close context
Bugs item #637940, was opened at 2002-11-13 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637940group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Wan (jwan) Assigned to: Nobody/Anonymous (nobody) Summary: NamingService doesn't close context Initial Comment: In org.jboss.naming.NamingService, the startService() method creates an InitialContext, but does not close it, and instead waits for the garbage collecor to clean up the IntialContext object. Resolution: Need to add iniCtx.close() to the end of the method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637940group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-621270 ] invalid SQL is generated for MSSQL
Bugs item #621270, was opened at 2002-10-10 05:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=621270group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 8 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: invalid SQL is generated for MSSQL Initial Comment: I have the following EJBQL expression: SELECT DISTINCT OBJECT(c) FROM StoreCategory c, IN (c.locales) l WHERE l.code=?1 AND c.images IS NOT EMPTY which for postgresql translates into: Executing SQL: SELECT DISTINCT t0_c.id FROM storecategory t0_c, mmslocale t1_l, storecategory_locales_m_18q3els t2_c_locales_RELATION_TABLE, mmsimage t3_c_images, mmsimage_storecategorie_1diogue t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND TRUE) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) and executes normally. But for MSSQL I get: SELECT DISTINCT t0_c.id FROM StoreCategory t0_c, MMSLocale t1_l, StoreCategory_locales_MMSLocale_storeCategories t2_c_locales_RELATION_TABLE, MMSImage t3_c_images, MMSImage_storeCategories_StoreCategory_images t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND 1) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) which leads to java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Line 1: Incorrect syntax near ')'. Why not using AND 1=1 instead of AND 1? -- Comment By: Jeremy Boynes (jboynes) Date: 2002-11-13 11:29 Message: Logged In: YES user_id=378919 I bet the current implementation will generate something that works more like an AND instead of an OR. It generates (sorry about changing the names): SELECT t0_p.id FROM Parent t0_p, Child t1_p_children WHERE (1 OR t0_p.value = ?) -- oops AND (t0_p.id=t1_p_children.parent) which basically makes the condition irrelevant. Generating a subquery by default seems less problematic and resulted in the same execution plan (at least on Oracle). One solution for MySQL would be to always use a LEFT JOIN (rather than the current INNER JOIN) and check NULL/NOT NULL for a field from the child's PK: SELECT DISTINCT t0_p.id FROM Parent t0_p LEFT JOIN Child t1_p_children ON (t1_p_children.parent = t0_p.id) WHERE (t0_p.value = ?) OR (t1_p_children.id IS NOT NULL) Not the most performant solution but I think it works for all cases - it would be possible though to convert back to the inner join if the compiler could detect there was no OR condition present. I can work on a patch to do this if it would help. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 09:26 Message: Logged In: YES user_id=251431 You're right. Alex is going to put in '(1=1)' instead of the true mapping for IS NOT EMPTY. I think this will work for a temporary solution, but I now believe more than ever that the current IS NOT EMPTY generated SQL is broken. I bet the following query will not generate the expected results: SELECT OBJECT(o) FROM order o WHERE o.lineItems IS NOT EMPTY OR o.total 0 I bet the current implementation will generate something that works more like an AND instead of an OR. The IS EMPTY operator was really designed for a sub query and the default should be to generate a sub query regardless of the presence of a NOT. Of course this creates a problem for mySQL, so we'll have to code around that. -- Comment By: Jeremy Boynes (jboynes) Date: 2002-10-31 11:16 Message: Logged In: YES user_id=378919 I might be confused here but I don't think the IS NOT EMPTY clause should be using the value from true-mapping The root of this seems to be the lack of a boolean datatype in standard SQL allowing vendors to implement it differently (e.g. as NUMBER(1) in Oracle, BIT in MS SQL, BOOLEAN in PostgreSQL). The true-mapping parameter is needed to map Java Boolean values to a literal of whatever datatype is being used in the db. SQL does define boolean operators but they take boolean expressions and as there are no standard boolean literals you can't write AND TRUE. The current JDBCEJBQLCompiler needs to do this for the IS NOT EMPTY clause. This can't be the value defined by true-mapping for assignment as, strictly, that is not a boolean expression (except for db's like PostgreSQL that have such an extension). Instead it should be a SQL boolean expression e.g. (1=1) Three solutions come to mind: * Make the JDBCEJBQLCompiler smarter so it doesn't
[JBoss-dev] [ jboss-Bugs-637934 ] CMR add overpopulates read ahead cache
Bugs item #637934, was opened at 2002-11-13 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Bonham (bonhamcm) Assigned to: Nobody/Anonymous (nobody) Summary: CMR add overpopulates read ahead cache Initial Comment: Using JBoss 3.2.0beta with Dain's Unidirectional performance patch, Sun JDK 1.3.1_03 on both Win2K and RedHat Linux 7.3. Given two local CMP entity beans in a CMR (unidirectional or bidirectional): Order (M) -- (1) Lineitem. When a new Lineitem is created with a relationship to an Order, all the Order's related Lineitems (siblings of the new one) are added to the read ahead cache without a limit. I've attached a testcase that can be integrated with the CMP2/Commerce Testsuite as well as an insert script for one Order and 1 related Lineitems. There are no asserts, but the log will show that all 1 siblings are loaded into the read ahead cache. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 13:29 Message: Logged In: YES user_id=251431 And this a problem why? The cache uses soft references, so you won't get an out of memory error. Also you should take a look at the new PrefetchCache in 4.0 it is much simpler. I plan on merging it into 3.2 when I have tested it more. -dain -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 --- 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
Re: [JBoss-dev] Metadata Service
Matt Munz wrote: Dain, Please excuse my ignorance. I'm a bit JMX-centric at the moment. I see an org.jboss.mx.server.Invocation that doesn't seem to know about / relate to org.jboss.invocation.Invocation. Obviously the names are the same. Is there any deeper relationship? Got me. I am a bit to EJB centric at the moment. I would guess that plan it to merge them, but I don't know. When I hear metadata JBoss in the same sentence, I think of JMX MBeanInfo. Since I recently wrote some code to facilitate MBeanInfo persistence, I'm interested in any changes to the way MBeanInfo is stored in the server. Is this related at all? Cool. I'm interested in the MBean persistence stuff. I have no plans on writing the final metadata repository, I just want to use one, so I will quickly write something with a very simple interface that can be replaced later. I feel that all this stuff is related, we just need to figure out how it all fits together. -dain --- 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
[JBoss-dev] [ jboss-Bugs-621270 ] invalid SQL is generated for MSSQL
Bugs item #621270, was opened at 2002-10-10 15:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=621270group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 8 Submitted By: Alexei Yudichev (sflexus) Assigned to: Alexey Loubyansky (loubyansky) Summary: invalid SQL is generated for MSSQL Initial Comment: I have the following EJBQL expression: SELECT DISTINCT OBJECT(c) FROM StoreCategory c, IN (c.locales) l WHERE l.code=?1 AND c.images IS NOT EMPTY which for postgresql translates into: Executing SQL: SELECT DISTINCT t0_c.id FROM storecategory t0_c, mmslocale t1_l, storecategory_locales_m_18q3els t2_c_locales_RELATION_TABLE, mmsimage t3_c_images, mmsimage_storecategorie_1diogue t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND TRUE) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) and executes normally. But for MSSQL I get: SELECT DISTINCT t0_c.id FROM StoreCategory t0_c, MMSLocale t1_l, StoreCategory_locales_MMSLocale_storeCategories t2_c_locales_RELATION_TABLE, MMSImage t3_c_images, MMSImage_storeCategories_StoreCategory_images t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND 1) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) which leads to java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Line 1: Incorrect syntax near ')'. Why not using AND 1=1 instead of AND 1? -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-11-13 21:35 Message: Logged In: YES user_id=543482 This is fixed by replacing true type mapping for IS NOT EMPTY with (1=1). Fixed in HEAD, 3.0, 3.2. -- Comment By: Jeremy Boynes (jboynes) Date: 2002-11-13 21:29 Message: Logged In: YES user_id=378919 I bet the current implementation will generate something that works more like an AND instead of an OR. It generates (sorry about changing the names): SELECT t0_p.id FROM Parent t0_p, Child t1_p_children WHERE (1 OR t0_p.value = ?) -- oops AND (t0_p.id=t1_p_children.parent) which basically makes the condition irrelevant. Generating a subquery by default seems less problematic and resulted in the same execution plan (at least on Oracle). One solution for MySQL would be to always use a LEFT JOIN (rather than the current INNER JOIN) and check NULL/NOT NULL for a field from the child's PK: SELECT DISTINCT t0_p.id FROM Parent t0_p LEFT JOIN Child t1_p_children ON (t1_p_children.parent = t0_p.id) WHERE (t0_p.value = ?) OR (t1_p_children.id IS NOT NULL) Not the most performant solution but I think it works for all cases - it would be possible though to convert back to the inner join if the compiler could detect there was no OR condition present. I can work on a patch to do this if it would help. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 19:26 Message: Logged In: YES user_id=251431 You're right. Alex is going to put in '(1=1)' instead of the true mapping for IS NOT EMPTY. I think this will work for a temporary solution, but I now believe more than ever that the current IS NOT EMPTY generated SQL is broken. I bet the following query will not generate the expected results: SELECT OBJECT(o) FROM order o WHERE o.lineItems IS NOT EMPTY OR o.total 0 I bet the current implementation will generate something that works more like an AND instead of an OR. The IS EMPTY operator was really designed for a sub query and the default should be to generate a sub query regardless of the presence of a NOT. Of course this creates a problem for mySQL, so we'll have to code around that. -- Comment By: Jeremy Boynes (jboynes) Date: 2002-10-31 21:16 Message: Logged In: YES user_id=378919 I might be confused here but I don't think the IS NOT EMPTY clause should be using the value from true-mapping The root of this seems to be the lack of a boolean datatype in standard SQL allowing vendors to implement it differently (e.g. as NUMBER(1) in Oracle, BIT in MS SQL, BOOLEAN in PostgreSQL). The true-mapping parameter is needed to map Java Boolean values to a literal of whatever datatype is being used in the db. SQL does define boolean operators but they take boolean expressions and as there are no standard boolean literals you can't write AND TRUE. The current JDBCEJBQLCompiler needs to do this for the IS NOT EMPTY clause. This can't be the value
[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=detailatid=376685aid=630665group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open 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=detailatid=376685aid=630665group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-637934 ] CMR add overpopulates read ahead cache
Bugs item #637934, was opened at 2002-11-13 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Bonham (bonhamcm) Assigned to: Nobody/Anonymous (nobody) Summary: CMR add overpopulates read ahead cache Initial Comment: Using JBoss 3.2.0beta with Dain's Unidirectional performance patch, Sun JDK 1.3.1_03 on both Win2K and RedHat Linux 7.3. Given two local CMP entity beans in a CMR (unidirectional or bidirectional): Order (M) -- (1) Lineitem. When a new Lineitem is created with a relationship to an Order, all the Order's related Lineitems (siblings of the new one) are added to the read ahead cache without a limit. I've attached a testcase that can be integrated with the CMP2/Commerce Testsuite as well as an insert script for one Order and 1 related Lineitems. There are no asserts, but the log will show that all 1 siblings are loaded into the read ahead cache. -- Comment By: Chris Bonham (bonhamcm) Date: 2002-11-13 14:40 Message: Logged In: YES user_id=610917 This can be a problem when the dataset is so large (originally 30 siblings) that the transaction times out or the user has to wait a long time just to add one object. In this case, the CMR add operation is the last one in the transaction, so there's not much point to adding the siblings to the read ahead cache (commit option B). Perhaps a per-relationship read ahead cache limit option is a good idea? I haven't had a chance to look at your new code to see if maybe you've already done this. Thanks. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 14:29 Message: Logged In: YES user_id=251431 And this a problem why? The cache uses soft references, so you won't get an out of memory error. Also you should take a look at the new PrefetchCache in 4.0 it is much simpler. I plan on merging it into 3.2 when I have tested it more. -dain -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-626468 ] ejb ql IS NOT EMPTY is not implemented
Bugs item #626468, was opened at 2002-10-21 21:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=626468group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Andrew (mr_dronski) Assigned to: Nobody/Anonymous (nobody) Summary: ejb ql IS NOT EMPTY is not implemented Initial Comment: ejb 2.0 final spec, page 236, section 11.3.2 Find all orders that have line items: SELECT DISTINCT OBJECT(o) FROM Order o, IN(o.lineItems) l Note that the result of this query does not include orders with no associated line items. This query can also be written as: SELECT OBJECT(o) FROM Order o WHERE o.lineItems IS NOT EMPTY = those 2 queries are identical in meaning and the developer has a choice which way to write it. but the one with IS NOT EMPTY is giving a FinderException with a nested SQL exception: 19:10:35,461 ERROR [STDERR] javax.ejb.FinderException: Find failed: java.sql.SQLException: Missing relational operator at position 119. 19:10:35,477 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstractQueryCommand.java:1 48) 19:10:35,477 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFindEntitiesCommand.java:40) 19:10:35,477 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreManager.java:549) 19:10:35,477 ERROR [STDERR] at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistenceManager.java:348) the SQL error code is 10009. seems that there's an error in sql generator. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-11-13 21:38 Message: Logged In: YES user_id=543482 Please, check out a fresh JBoss version try your code. Similar bug 621270 was just fix. Let us know the results, please. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=626468group_id=22866 --- 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
RE: [JBoss-dev] Metadata Service
Bill, Components register their XML with this service. MBean, EJB, whatever... For MBeans, you're talking about *-service.xml, right? Would this apply also to XMBean XML? JMX console needs an additional XML editor for MBean attributes that are XML elements. I think it would be great to expand the JMX console to handle all sorts of common types, for input and output. Collection obects and arrays in particular would be a powerful addition. I believe that the PropertyEditor mechanism may be useful for this. I always thought that w3c DOM Elements were transient objects -- a stepping stone between XML text and full-fledged objects. I'm curious -- why do they need to be stored as MBean attributes? BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? Is there something specific to this metadata problem that makes a central XML file a more attractive solution? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 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
[JBoss-dev] [ jboss-Bugs-637934 ] CMR add overpopulates read ahead cache
Bugs item #637934, was opened at 2002-11-13 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Bonham (bonhamcm) Assigned to: Nobody/Anonymous (nobody) Summary: CMR add overpopulates read ahead cache Initial Comment: Using JBoss 3.2.0beta with Dain's Unidirectional performance patch, Sun JDK 1.3.1_03 on both Win2K and RedHat Linux 7.3. Given two local CMP entity beans in a CMR (unidirectional or bidirectional): Order (M) -- (1) Lineitem. When a new Lineitem is created with a relationship to an Order, all the Order's related Lineitems (siblings of the new one) are added to the read ahead cache without a limit. I've attached a testcase that can be integrated with the CMP2/Commerce Testsuite as well as an insert script for one Order and 1 related Lineitems. There are no asserts, but the log will show that all 1 siblings are loaded into the read ahead cache. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 13:46 Message: Logged In: YES user_id=251431 Ok, so you want to limit the number of guys put in the read-ahead cache. Are you sure you wan to limit this on a pre relationhship basis? I would guess a per bean basis is more desireable. Maybe a configurable (optional) shared cache, so we can say no more then n across all beans readahead per tx. Do you just want to cap it at x or should we use an LRU rule? -- Comment By: Chris Bonham (bonhamcm) Date: 2002-11-13 13:40 Message: Logged In: YES user_id=610917 This can be a problem when the dataset is so large (originally 30 siblings) that the transaction times out or the user has to wait a long time just to add one object. In this case, the CMR add operation is the last one in the transaction, so there's not much point to adding the siblings to the read ahead cache (commit option B). Perhaps a per-relationship read ahead cache limit option is a good idea? I haven't had a chance to look at your new code to see if maybe you've already done this. Thanks. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 13:29 Message: Logged In: YES user_id=251431 And this a problem why? The cache uses soft references, so you won't get an out of memory error. Also you should take a look at the new PrefetchCache in 4.0 it is much simpler. I plan on merging it into 3.2 when I have tested it more. -dain -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 --- 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
RE: [JBoss-dev] Metadata Service
BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Is there something specific to this metadata problem that makes a central XML file a more attractive solution? I saying Document as in the Java Object. Not in a XML file stored on disk. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 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 time). -dain
RE: [JBoss-dev] Metadata Service
Got me. I am a bit to EJB centric at the moment. I would guess that plan it to merge them, but I don't know. I'd be interested in hearing more about this topic. I imagine AOP converges on this issue as well? Cool. I'm interested in the MBean persistence stuff. I have no plans on writing the final metadata repository, I just want to use one, so I will quickly write something with a very simple interface that can be replaced later. I feel that all this stuff is related, we just need to figure out how it all fits together. Well, that is pretty much the approach with the MBean persistence stuff, AFAIK. The mechanism is pluggable, and the implementation is really a RI / straw man. Personally, I think that persistence of metadata for the server (JMX or otherwise) should be pluggable -- file, XML file, JDBC, whatever on the back end. To me, JMX is all about metadata -- in a sense, it is the metadata that makes detyped invocation work. When you talk about adding metadata to an invocation, and storing that metadata somewhere, it sounds just like MBean persistence. At a minimum, you should be able to reuse some ideas, if not code, from the management module... - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Matt Munz wrote: Dain, Please excuse my ignorance. I'm a bit JMX-centric at the moment. I see an org.jboss.mx.server.Invocation that doesn't seem to know about / relate to org.jboss.invocation.Invocation. Obviously the names are the same. Is there any deeper relationship? Got me. I am a bit to EJB centric at the moment. I would guess that plan it to merge them, but I don't know. When I hear metadata JBoss in the same sentence, I think of JMX MBeanInfo. Since I recently wrote some code to facilitate MBeanInfo persistence, I'm interested in any changes to the way MBeanInfo is stored in the server. Is this related at all? Cool. I'm interested in the MBean persistence stuff. I have no plans on writing the final metadata repository, I just want to use one, so I will quickly write something with a very simple interface that can be replaced later. I feel that all this stuff is related, we just need to figure out how it all fits together. -dain --- 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
[JBoss-dev] [ jboss-Bugs-637934 ] CMR add overpopulates read ahead cache
Bugs item #637934, was opened at 2002-11-13 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Bonham (bonhamcm) Assigned to: Nobody/Anonymous (nobody) Summary: CMR add overpopulates read ahead cache Initial Comment: Using JBoss 3.2.0beta with Dain's Unidirectional performance patch, Sun JDK 1.3.1_03 on both Win2K and RedHat Linux 7.3. Given two local CMP entity beans in a CMR (unidirectional or bidirectional): Order (M) -- (1) Lineitem. When a new Lineitem is created with a relationship to an Order, all the Order's related Lineitems (siblings of the new one) are added to the read ahead cache without a limit. I've attached a testcase that can be integrated with the CMP2/Commerce Testsuite as well as an insert script for one Order and 1 related Lineitems. There are no asserts, but the log will show that all 1 siblings are loaded into the read ahead cache. -- Comment By: Chris Bonham (bonhamcm) Date: 2002-11-13 15:11 Message: Logged In: YES user_id=610917 That's a good point, a per-bean limit makes more sense than a per-relationship one. Does the current read ahead/prefetch cache use a LRU rule? An optional LRU shared cache with a configurable hard limit would be optimal. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 14:46 Message: Logged In: YES user_id=251431 Ok, so you want to limit the number of guys put in the read-ahead cache. Are you sure you wan to limit this on a pre relationhship basis? I would guess a per bean basis is more desireable. Maybe a configurable (optional) shared cache, so we can say no more then n across all beans readahead per tx. Do you just want to cap it at x or should we use an LRU rule? -- Comment By: Chris Bonham (bonhamcm) Date: 2002-11-13 14:40 Message: Logged In: YES user_id=610917 This can be a problem when the dataset is so large (originally 30 siblings) that the transaction times out or the user has to wait a long time just to add one object. In this case, the CMR add operation is the last one in the transaction, so there's not much point to adding the siblings to the read ahead cache (commit option B). Perhaps a per-relationship read ahead cache limit option is a good idea? I haven't had a chance to look at your new code to see if maybe you've already done this. Thanks. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-13 14:29 Message: Logged In: YES user_id=251431 And this a problem why? The cache uses soft references, so you won't get an out of memory error. Also you should take a look at the new PrefetchCache in 4.0 it is much simpler. I plan on merging it into 3.2 when I have tested it more. -dain -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637934group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-637960 ] cmp bean not loaded
Bugs item #637960, was opened at 2002-11-13 14:07
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=637960group_id=22866
Category: JBossCMP
Group: v4.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Julien Viet (cooperfbi)
Assigned to: Nobody/Anonymous (nobody)
Summary: cmp bean not loaded
Initial Comment:
When a cmp bean is retrieved by a finder method it does
not set the isCreated property on to true.
my case :
I have a cmr set in a post create with a bean retrieved in
this way :
in UserEJB :
public void ejbPostCreate() {
Collection roles = getRoles();
roles.clear();
RoleEJBLocal role = roleHome.findByRoleAndRoleGroup
(authenticated, Roles); // custom EJBQL finder
roles.add(role);
}
roles.add(role); throw an exception (cmr field can't be
set in ejbCreate, etc...) because the cmp engine see
the isCreated property to false in
JDBCCMRFieldBridge.addRelation(...)
isCreated value is set to true when a bean is
created or loaded but the finder does not call the
loadEntity on JDBCStoreManager at all.
What I did to make ot work is to force the engine
to load the bean with an access to a cmp field :
RoleEJBLocal role = ... // custom EJBQL finder
**role.getName(); ** // load the instance
roles.add(role);
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=637960group_id=22866
---
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
[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=detailatid=376685aid=636920group_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-13 20:17
Message:
Logged In: YES
user_id=592596
Here is the basic layout of the problem
**Containing Page***
tabletrtd
%= myObject.getOutput(request, response) %
/td/tr/table...
*** 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 jsp:include. 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=detailatid=376685aid=636920group_id=22866
---
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
Re: [JBoss-dev] Metadata Service
This has merit, but mbeans today do not know about XML in general, they know about attributes. Changes made to the XML config need to propagate as attribute setter invocations. Editing mbean attributes via JMX would have to update the repository. I'm not sure using XML as the manifest memory storage mechanism is a good programming API. Maybe that is just the search/query index representation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 11:01 AM Subject: RE: [JBoss-dev] Metadata Service 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 --- 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
RE: [JBoss-dev] Metadata Service
Bill, My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured Well, so do DTDs and XML schemas. It is an interesting argument that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Is there something specific to this metadata problem that makes a central XML file a more attractive solution? I saying Document as in the Java Object. Not in a XML file stored on disk. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 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]
RE: [JBoss-dev] Metadata Service
To me, JMX is all about metadata -- in a sense, it is the metadata that makes detyped invocation work. When you talk about adding metadata to an invocation, and storing that metadata somewhere, it sounds just like MBean persistence. At a minimum, you should be able to reuse some ideas, if not code, from the management module... 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. Bill - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Matt Munz wrote: Dain, Please excuse my ignorance. I'm a bit JMX-centric at the moment. I see an org.jboss.mx.server.Invocation that doesn't seem to know about / relate to org.jboss.invocation.Invocation. Obviously the names are the same. Is there any deeper relationship? Got me. I am a bit to EJB centric at the moment. I would guess that plan it to merge them, but I don't know. When I hear metadata JBoss in the same sentence, I think of JMX MBeanInfo. Since I recently wrote some code to facilitate MBeanInfo persistence, I'm interested in any changes to the way MBeanInfo is stored in the server. Is this related at all? Cool. I'm interested in the MBean persistence stuff. I have no plans on writing the final metadata repository, I just want to use one, so I will quickly write something with a very simple interface that can be replaced later. I feel that all this stuff is related, we just need to figure out how it all fits together. -dain --- 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 --- 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
[JBoss-dev] [ jboss-Bugs-637973 ] NPE on shutdown/redeploy
Bugs item #637973, was opened at 2002-11-13 14:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637973group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Jimmy Wan (jwan) Assigned to: Nobody/Anonymous (nobody) Summary: NPE on shutdown/redeploy Initial Comment: On shutdown or redeploy, I see NPEs in server.log From shutdown: [14:32:08,942,JDBCDataSourceLoader] java.lang.NullPointerException From redeploy: [14:32:08,952,STDOUT] [ERROR,JDBCDataSourceLoader] java.lang.NullPointerException -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637973group_id=22866 --- 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
RE: [JBoss-dev] Metadata Service
search/query is exactly the benefit I see from a centralized XML-based config repository. I see your point though. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott M Stark Sent: Wednesday, November 13, 2002 3:17 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service This has merit, but mbeans today do not know about XML in general, they know about attributes. Changes made to the XML config need to propagate as attribute setter invocations. Editing mbean attributes via JMX would have to update the repository. I'm not sure using XML as the manifest memory storage mechanism is a good programming API. Maybe that is just the search/query index representation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 11:01 AM Subject: RE: [JBoss-dev] Metadata Service 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 --- 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 13-November-2002
Number of tests run: 991
Successful tests: 986
Errors:5
Failures: 0
[time of test: 13 November 2002 12:49 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://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
NOTE: If there are any errors shown above - this mail is only highlighting
them - it is NOT indicating that they are being looked at by anyone.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
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
[JBoss-dev] [ jboss-Bugs-637730 ] client-server JNDI lookup fails
Bugs item #637730, was opened at 2002-11-13 04:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637730group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Marko Strukelj (mstruk) Assigned to: Scott M Stark (starksm) Summary: client-server JNDI lookup fails Initial Comment: This is an issue on JBoss 3.0.4 only. JBoss 3.0.3 works fine. If jboss is restarted all remote objects become invalid - this is perfectly normal. Any automatic recovery of remote objects would then have to do something like: InitialContext ctx = new InitialContext(); MyServiceHome home = (MyServiceHome)ctx.lookup (MyService); sess = home.create(); The problem is that ctx.lookup returns null if jboss has been restarted. It can return null several times and then suddenly return home interface. Or sometimes it will always return null no matter how many times you try. It does not throw any exception it just returns null. Only restart of the client application helps. -- Comment By: Scott M Stark (starksm) Date: 2002-11-13 13:16 Message: Logged In: YES user_id=175228 This is due to a change in the connection logic that is attempting to deal with overloaded accept queues. I have fixed the problem for the 3.0.5 release. In the interim you can obtain the source from the 3.0 branch and use the jnp- client.jar from the jboss-all/naming module build. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637730group_id=22866 --- 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
Re: [JBoss-dev] Metadata Service
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. -dain --- 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
Re: [JBoss-dev] Metadata Service
I didn't know you could do that. What spec/library is this in? I want to read it. uPnP ? just a thought 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
[JBoss-dev] Be careful when overriding exception pathways
A change was made to the JNDI lookup in 3.0.4 that retries lookup ops due to connection errors. This was an attempt to workaround problems with windows tcp stack not handling accept backlogs well. The problem is that this broke the ability to reconnect to a server that has been restarted because the ConnectionException that was being caught in the retry loop was not thrown if the retries were exhausted. The bad server reference in the cache was not flushed and lookups to the restarted server always returned null instead of throwing an exception. In general you need to make sure that you test the exception path still works when you attempt to change its handling. Scott Stark Chief Technology Officer 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
RE: [JBoss-dev] Metadata Service
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Wednesday, November 13, 2002 3:30 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service Bill, My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured Well, so do DTDs and XML schemas. It is an interesting argument I don't like DTDs and XML schemas for the very reason that they force you to update the DTD every time a new type of configuration comes along. The Components themselves should do the validation of their particular part of the large XML file/document. Consider an ISV who wants to add their new component to JBoss with new complex configuration. They have to modify our DTD? No, they shouldn't have to and we shouldn't allow them. (Don't know much about XML Schemasmaybe they address these issues?) that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? What I was trying to suggest is that complex xml config data is modified via a file or through some Management Console at runtime. Components can register via XPATHS to listen to this changed data. They are notified and update their local config, construct new objects, whatever... Hmmm...I'm starting to see what you're saying. MBeans already have notifications and ways to query, right? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? XPATHs would be a perfect fit for something like this. Why recreate? Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Is there something specific to this metadata problem that makes a central XML file a more attractive solution? I saying Document as in the Java Object. Not in a XML file stored on disk. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 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
[JBoss-dev] [ jboss-Patches-637998 ] LdapLoginModule port selection bugfix
Patches item #637998, was opened at 2002-11-13 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=637998group_id=22866 Category: JBossSX Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: David Arnold (watermelonjam) Assigned to: Nobody/Anonymous (nobody) Summary: LdapLoginModule port selection bugfix Initial Comment: If Context.PROVIDER_URL is unspecified, LdapLoginModule.createLdapInitContext builds a default URL. Problem is, it chooses port 389 for ldaps://, and 636 for ldap://. This fixes that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=637998group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-636010 ] Problem with JAVA_HOME with spaces
Bugs item #636010, was opened at 2002-11-09 12:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=636010group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Archimedes Trajano (trajano) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with JAVA_HOME with spaces Initial Comment: If the JDK is installed in a directory that contains spaces say c:\program files\java\jdk1.4.1 the run.bat and shutdown.bat will not start properly. The simple fix I made is to just quote %JAVA% e.g. in run.bat %JAVA% %JAVA_OPTS% -classpath % JBOSS_CLASSPATH% org.jboss.Main %ARGS% -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=636010group_id=22866 --- 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
[JBoss-dev] Bug in TxCapsule.java for JBoss 3.0.4
Here's a patch for a bug I found. I couldn't determine how to
open a bug on either sourceforge.net nor jboss.org, so I'll just
simply post this patch to this list. Enjoy.
And with this, I believe I can now use an InformixXADs. :)
-Dan
--- TxCapsule.java.old Wed Nov 13 15:24:58 2002
+++ TxCapsule.java Wed Nov 13 14:59:47 2002
@@ -710,7 +710,7 @@
//{
for (int i = 0; i resourceCount; ++i)
{
- if (resourceSameRM[i] == -1 xaRes.isSameRM(resources[i]))
+ if (resourceSameRM[i] == -1 resources[i].isSameRM(xaRes))
{
// The xaRes is new. We register the xaRes with the Xid
// that the RM has previously seen from this transaction,
--
Dan A. Dickey
[EMAIL PROTECTED]
---
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
Re: [JBoss-dev] Metadata Service
Bill Burke wrote: I don't like DTDs and XML schemas for the very reason that they force you to update the DTD every time a new type of configuration comes along. The Components themselves should do the validation of their particular part of the large XML file/document. Consider an ISV who wants to add their new component to JBoss with new complex configuration. They have to modify our DTD? No, they shouldn't have to and we shouldn't allow them. (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. -dain --- 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
[JBoss-dev] [ jboss-Bugs-637999 ] LdapLoginModule chooses wrong port
Bugs item #637999, was opened at 2002-11-13 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637999group_id=22866 Category: JBossSX Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: David Arnold (watermelonjam) Assigned to: Nobody/Anonymous (nobody) Summary: LdapLoginModule chooses wrong port Initial Comment: If Context.PROVIDER_URL is unspecified, LdapLoginModule.createLdapInitContext builds a default URL. Problem is, it chooses port 389 for ldaps://, and 636 for ldap://. A reversed conditional at line 224 in LdapLoginModule.java. I've submitted patch 637998 for inclusion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637999group_id=22866 --- 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
[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=detailatid=376685aid=633392group_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-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=detailatid=376685aid=633392group_id=22866 --- 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
Re: [JBoss-dev] Metadata Service
Bill Burke wrote: XPATHs would be a perfect fit for something like this. Why recreate? Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. Bill to me this XML stuff is just an implementation detail. The important questions are: * Where does the metadata live? Is it hanging off the container, application or a toplevel domain? I would assume the container has a ref to a service that maybe shared across the domain, but the container doesn't care as it only has a simple interface. * How is the data loaded into the repository? I am thinking of specialized loader classes that in the example of ejb fill the repository with method level metadata like security and tx * How are changes propagated from the repository to the physical structure and the other way around. I have no idea on that one. -dain --- 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
Re: [JBoss-dev] Metadata Service
Matt Munz wrote: Bill, My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured Well, so do DTDs and XML schemas. It is an interesting argument that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... Actually, Jakarta JXPath can handle practically any java object graph (consisting of JavaBeans, Maps, etc. ) and traverse it via an XPATH query, so you don't have to tie yourselves to DOM objects. check out http://jakarta.apache.org/commons/jxpath/ So, actually, as long as your custom object graph is 'equivalent' to a DOM tree you can remove the DOM tree from the global configuration and replace it by your custom object graph. Don't know if it is useful to anybody, though. via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? - Matt -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- 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
Re: [JBoss-dev] Metadata Service
Dain Sundstrom wrote: Bill Burke wrote: XPATHs would be a perfect fit for something like this. Why recreate? Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. Bill to me this XML stuff is just an implementation detail. The important questions are: * Where does the metadata live? Is it hanging off the container, application or a toplevel domain? I would assume the container has a ref to a service that maybe shared across the domain, but the container doesn't care as it only has a simple interface. * How is the data loaded into the repository? I am thinking of specialized loader classes that in the example of ejb fill the repository with method level metadata like security and tx * How are changes propagated from the repository to the physical structure and the other way around. I have no idea on that one. -dain It seems, some of these issues Rickard tried to address by using run-time attributes (check out his weblog) http://roller.anthonyeden.com/page/rickard/20021113 -- - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - --- 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
Re: [JBoss-dev] Upcoming releases
I'm now writing some new code that I would like to get in the next 3.2 release. Have you an idea of when the release will be ? I need to decide whether I will try to get this code in or not. Thanks, Jules Scott M Stark wrote: Go ahead. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 1:09 PM Subject: Re: [JBoss-dev] Upcoming releases What has happened to the 3.2beta release ? I have some stuff to put in - am I to late ? Jules Scott M Stark wrote: I'm planning on the following releases so time your work accordingly: 2002-10-25jboss-2.4.10 2002-10-27jboss-3.0.4 2002-11-03jboss-3.0.2beta2 2002-12-22jboss-4.0alpha Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ 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
RE: [JBoss-dev] Metadata Service
If you are interested in XPath check out http://jakarta.apache.org/commons/jxpath/index.html which has an XPath implementation that will work with (quote from site) JavaBeans, Maps, Servlet contexts, DOM etc, including mixtures thereof. -Phil Matt Munz [EMAIL PROTECTED] Sent by: To: [EMAIL PROTECTED] [EMAIL PROTECTED] eforge.net cc: Subject: RE: [JBoss-dev] Metadata Service 11/13/2002 01:30 PM Please respond to jboss-development Bill, My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured Well, so do DTDs and XML schemas. It is an interesting argument that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Is there something specific to this metadata problem that makes a central XML file a more attractive solution? I saying Document as in the Java Object. Not in a XML file stored on disk. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 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
RE: [JBoss-dev] Metadata Service
Anatoly, Actually, Jakarta JXPath can handle practically any java object graph (consisting of JavaBeans, Maps, etc. ) and traverse it via an XPATH query, so you don't have to tie yourselves to DOM objects. check out http://jakarta.apache.org/commons/jxpath/ Wow. Thanks. Coolest thing I've seen today :) Bill, Perhaps this might bridge your need for cross-cutting metadata searches without using an XML object as a memory storage mechanism... - Matt --- 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
Re: [JBoss-dev] Metadata Service
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
RE: [JBoss-dev] Metadata Service
Bill, What I was trying to suggest is that complex xml config data is modified via a file or through some Management Console at runtime. Components can register via XPATHS to listen to this changed data. They are notified and update their local config, construct new objects, whatever... Hmmm...I'm starting to see what you're saying. MBeans already have notifications and ways to query, right? Yes. Why not build on JMX and JBoss Management instead of around it? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? XPATHs would be a perfect fit for something like this. Why recreate? A matter of implementation, right? Perhaps the search features are an extension of JMX (more of a JBoss Management feature). Maybe the jxPath route might work -- maybe something else? I don't know if the current search implementation could be replaced easily with something else or not... The MBean registry seemed fairly simple at first glance... something like a big Hashtable... Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Well, MBeans are fairly neutral. I'm sure that we could pile on whatever structure we want. For example, to make MBean persistence work, we used a certain MBean attribute to denote that an MBean could be persisted in a certain way. Nothing in the spec. requires this -- it's just an extension. Your configuration domains might be treated in a similar manner. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. Use cases are good. I don't know much about JBoss clustering -- I wouldn't know where to start. Is it possible to give a single-machine example? - Matt --- 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
[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
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
[JBoss-dev] MetaDataRepository Proposal
This is based on some emails I have been trading with Scott. I'm going
to start at the invoker and work my way out, because it is the way I
know best.
I'm going to add a new MetaDataLoaderInvoker. All this invoker does is
populate the invocation object with meta data from the repository. Here
is the code for the invoke method:
public Object invoke(Invocation invocation) throw Exception
{
invocationMetaDataLoader.load(invocation, metaDataRepository);
return getNext().invoke();
}
The invocation meta data loader is responsible for getting only the data
needed for the interceptor stack from the repository and merging the
data into the invocation object. The loader should not blindly
overwrite data already in the invocation, so clients can have control
over the invocation and the loader should fill in reasonable default if
non is available in the repository.
This design is a trade off between blindly stuffing all possible data
for an invocation in to the hash table, which could take a very long
time, and alternatively having an intelligent loader that knows what
is needed for the invocation. It is just a trade off of speed for a
more static (puggable and runtime replaceable) loader.
Assuming I haven't already confused you, now where does the repository
come from? I propose that it is just another service that the container
depends on like caching and pooling (when these become real MBeans). I
am thinking of an interface like this:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
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?
If you agree to this point, the next problem is how do we get data into
the repository and how do we get updates out. I see two possibilities
here: we could go the JCache route where you have a loader associated
with the repository that is called when data is not in the cache or we
could have an outboard loader that stuffs the cache on container
startup. Either way is cool with me.
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.
-dain
--
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
Re: [JBoss-dev] Metadata Service
If we can add an import mechanism then we can have both. I think a small set of files is better than one big file is better than a million little files. --jason On Wednesday, November 13, 2002, at 02:49 PM, Dain Sundstrom wrote: 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: 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
Re: [JBoss-dev] Metadata Service
Agreed. Jason Dillon wrote: If we can add an import mechanism then we can have both. I think a small set of files is better than one big file is better than a million little files. --jason On Wednesday, November 13, 2002, at 02:49 PM, Dain Sundstrom wrote: 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: 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
RE: [JBoss-dev] Metadata Service
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. I like that. If it was more configurable at runtime, the JBossMQ would be able to CMP 2.0 for it's message persistence. It would configure CMP engine via API calls. Regards, Hiram --- 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
Re: [JBoss-dev] Metadata Service
Hiram Chirino wrote: I like that. If it was more configurable at runtime, the JBossMQ would be able to CMP 2.0 for it's message persistence. It would configure CMP engine via API calls. Exactly -dain --- 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
[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=detailatid=376685aid=636920group_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 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 jsp:include 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***
tabletrtd
%= myObject.getOutput(request, response) %
/td/tr/table...
*** 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 jsp:include. 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=detailatid=376685aid=636920group_id=22866
---
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
Re: [JBoss-dev] Bug in TxCapsule.java for JBoss 3.0.4
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
On 2002.11.13 16:36:28 -0500 Dan A. Dickey wrote:
Here's a patch for a bug I found. I couldn't determine how to
open a bug on either sourceforge.net nor jboss.org, so I'll just
simply post this patch to this list. Enjoy.
And with this, I believe I can now use an InformixXADs. :)
-Dan
--- TxCapsule.java.old Wed Nov 13 15:24:58 2002
+++ TxCapsule.java Wed Nov 13 14:59:47 2002
@@ -710,7 +710,7 @@
//{
for (int i = 0; i resourceCount; ++i)
{
- if (resourceSameRM[i] == -1
xaRes.isSameRM(resources[i]))
+ if (resourceSameRM[i] == -1
resources[i].isSameRM(xaRes))
{
// The xaRes is new. We register the xaRes with the
Xid
// that the RM has previously seen from this
transaction,
--
Dan A. Dickey
[EMAIL PROTECTED]
---
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
Re: [JBoss-dev] MetaDataRepository Proposal
Can you please give a fairly detailed use case for this idea and indicate
why it is needed rather than a static division of metadata between that
which is tied to an interceptor stack (the same for every invocation going
through the stack) and that which is specific to a particular invocation
(and thus supplied by the client).
So far this idea strikes me as needless complexity that doesn't solve any
problems, so please enlighten me as to the point. I will understand much
better if you have a specific example that won't work with the division of
responsibility outlined above.
thanks
david jencks
On 2002.11.13 17:56:17 -0500 Dain Sundstrom wrote:
This is based on some emails I have been trading with Scott. I'm going
to start at the invoker and work my way out, because it is the way I
know best.
I'm going to add a new MetaDataLoaderInvoker. All this invoker does is
populate the invocation object with meta data from the repository. Here
is the code for the invoke method:
public Object invoke(Invocation invocation) throw Exception
{
invocationMetaDataLoader.load(invocation, metaDataRepository);
return getNext().invoke();
}
The invocation meta data loader is responsible for getting only the data
needed for the interceptor stack from the repository and merging the
data into the invocation object. The loader should not blindly
overwrite data already in the invocation, so clients can have control
over the invocation and the loader should fill in reasonable default if
non is available in the repository.
This design is a trade off between blindly stuffing all possible data
for an invocation in to the hash table, which could take a very long
time, and alternatively having an intelligent loader that knows what
is needed for the invocation. It is just a trade off of speed for a
more static (puggable and runtime replaceable) loader.
Assuming I haven't already confused you, now where does the repository
come from? I propose that it is just another service that the container
depends on like caching and pooling (when these become real MBeans). I
am thinking of an interface like this:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
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?
If you agree to this point, the next problem is how do we get data into
the repository and how do we get updates out. I see two possibilities
here: we could go the JCache route where you have a loader associated
with the repository that is called when data is not in the cache or we
could have an outboard loader that stuffs the cache on container
startup. Either way is cool with me.
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.
-dain
--
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: 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
Re: [JBoss-dev] MetaDataRepository Proposal
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,
and the worst part is we have no control over it at runtime. It is way
simpler. You'll see.
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
runtime. There really is no need to shut down an application in
production just to change some configuration data.
Even if there is no real need the code is simpler.
-dain
David Jencks wrote:
Can you please give a fairly detailed use case for this idea and indicate
why it is needed rather than a static division of metadata between that
which is tied to an interceptor stack (the same for every invocation going
through the stack) and that which is specific to a particular invocation
(and thus supplied by the client).
So far this idea strikes me as needless complexity that doesn't solve any
problems, so please enlighten me as to the point. I will understand much
better if you have a specific example that won't work with the division of
responsibility outlined above.
thanks
david jencks
On 2002.11.13 17:56:17 -0500 Dain Sundstrom wrote:
This is based on some emails I have been trading with Scott. I'm going
to start at the invoker and work my way out, because it is the way I
know best.
I'm going to add a new MetaDataLoaderInvoker. All this invoker does is
populate the invocation object with meta data from the repository. Here
is the code for the invoke method:
public Object invoke(Invocation invocation) throw Exception
{
invocationMetaDataLoader.load(invocation, metaDataRepository);
return getNext().invoke();
}
The invocation meta data loader is responsible for getting only the data
needed for the interceptor stack from the repository and merging the
data into the invocation object. The loader should not blindly
overwrite data already in the invocation, so clients can have control
over the invocation and the loader should fill in reasonable default if
non is available in the repository.
This design is a trade off between blindly stuffing all possible data
for an invocation in to the hash table, which could take a very long
time, and alternatively having an intelligent loader that knows what
is needed for the invocation. It is just a trade off of speed for a
more static (puggable and runtime replaceable) loader.
Assuming I haven't already confused you, now where does the repository
come from? I propose that it is just another service that the container
depends on like caching and pooling (when these become real MBeans). I
am thinking of an interface like this:
public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}
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?
If you agree to this point, the next problem is how do we get data into
the repository and how do we get updates out. I see two possibilities
here: we could go the JCache route where you have a loader associated
with the repository that is called when data is not in the cache or we
could have an outboard loader that stuffs the cache on container
startup. Either way is cool with me.
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.
-dain
--
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: Are you worried about
your web server security? Click here for a FREE
[JBoss-dev] [ jboss-Bugs-637999 ] LdapLoginModule chooses wrong port
Bugs item #637999, was opened at 2002-11-13 13:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637999group_id=22866 Category: JBossSX Group: CVS HEAD Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Arnold (watermelonjam) Assigned to: Scott M Stark (starksm) Summary: LdapLoginModule chooses wrong port Initial Comment: If Context.PROVIDER_URL is unspecified, LdapLoginModule.createLdapInitContext builds a default URL. Problem is, it chooses port 389 for ldaps://, and 636 for ldap://. A reversed conditional at line 224 in LdapLoginModule.java. I've submitted patch 637998 for inclusion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=637999group_id=22866 --- 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
Re: [JBoss-dev] Upcoming releases
Maybe by next Monday. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 2:07 PM Subject: Re: [JBoss-dev] Upcoming releases I'm now writing some new code that I would like to get in the next 3.2 release. Have you an idea of when the release will be ? I need to decide whether I will try to get this code in or not. Thanks, Jules --- 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
RE: [JBoss-dev] MetaDataRepository Proposal
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. 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? Regards, Hiram 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 runtime. There really is no need to shut down an application in production just to change some configuration data. Even if there is no real need the code is simpler. -dain --- 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
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 13-November-2002
Number of tests run: 1026 Successful tests: 991 Errors:30 Failures: 5 [time of test: 13 November 2002 21:3 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: 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] 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. -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
