Re: [JBoss-dev] Cannot build off the head.
Ok looks like my checkout didn't complete successfully and I was thinking that cvs update would make up for it. Now I'm doing the cvs check again it's bring in some more stuff from thirdparty so I'll assume the check out isn't complete. Sorry to disturb. --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 你好
ÄãºÃ£º Çë¿´ http://www.cnhxw.com QQºÅ:17064191 ÇëºÍÎÒÁªÏµ --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Cannot build off the head.
Should the thirdparty directory have xdoclet in it? I'm trying to build jboss-head on Mac OS 10.2.1 and I'm not getting anywhere. the following in libraries.ent suggests that I should have xdoclet-xdoclet in thirdparty but in my fresh check out it's not there [Robert-Nicholsons-Computer:~/Archives/jboss-head/thirdparty] robert% ls -alg total 0 drwxr-xr-x 19 robert staff 646 Oct 23 12:40 . drwxr-xr-x 30 robert staff 1020 Oct 23 13:26 .. drwxr-xr-x 5 robert staff 170 Oct 23 13:23 CVS drwxr-xr-x 5 robert staff 170 Oct 23 13:29 apache-axis drwxr-xr-x 6 robert staff 204 Oct 23 12:14 apache-bcel drwxr-xr-x 4 robert staff 136 Oct 23 12:13 apache-log4j drwxr-xr-x 5 robert staff 170 Oct 23 12:16 apache-xalan drwxr-xr-x 4 robert staff 136 Oct 23 12:29 exolab-castor drwxr-xr-x 4 robert staff 136 Oct 23 12:33 exolab-tyrex drwxr-xr-x 5 robert staff 170 Oct 23 12:34 gnu-getopt drwxr-xr-x 4 robert staff 136 Oct 23 12:34 gnu-regexp drwxr-xr-x 4 robert staff 136 Oct 23 12:34 hsqldb-hsqldb drwxr-xr-x 4 robert staff 136 Oct 23 12:35 javagroups-javagroups drwxr-xr-x 4 robert staff 136 Oct 23 12:09 jboss-plastic drwxr-xr-x 4 robert staff 136 Oct 23 12:37 junit-junit drwxr-xr-x 4 robert staff 136 Oct 23 12:38 sun-jaas drwxr-xr-x 4 robert staff 136 Oct 23 12:38 sun-jaf drwxr-xr-x 5 robert staff 170 Oct 23 12:38 sun-javacc drwxr-xr-x 4 robert staff 136 Oct 23 12:40 sun-javamail When I build under OS 10.2.1 I get [Robert-Nicholsons-Computer:~/Archives/jboss-head/build] robert% ./build.sh build.sh: Executing: /Users/robert/Archives/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property _buildmagic:init:local-properties: [copy] Copying 1 file to /Users/robert/Archives/jboss-head/build BUILD FAILED file:/Users/robert/Archives/jboss-head/build/../tools/etc/ buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 4 seconds --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Stay with BT AND save money!
Save money on your telephhone calls UK Telephone users! Are you one of the thousands of people paying more than they need to for their phone calls? Whether you phone abroad, or locally...during peak hours or in the evenings, Telco can offer you fantastic savings on all your calls. - Telco is free to join - Keep your own phone and number - No prefix numbers to dial - No additional equipment or boxes to fit - You continue to pay BT for your line rental, and any additional BT services - Save up to: 25% on local, 50% on National, 82% on International and 62% on Internet calls BT price per minute Telco price per minute Local Calls 4p Local Call 3p National Calls 8p National Calls 4p USA 24p USA 2p Australia 49p Australia 3p India 120p India 25p Ireland 23p Ireland 2p All backed by the unique Telco Price Promise which means Telco prices are below BT standard rates for Local, National, International, Mobile and Internet calls or we'll refund double the difference. (BT standard rates before promotions and discounts. Internet calls via Telco4u.net. Terms and conditions apply. See price list for details.) Interested? Just go to: http://www.cheap-telephone-calls.com and click on the link. _ This email was sent using a [try before you buy] newsletter program. --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-578063 ] HttpSession-clustering fails
Bugs item #578063, was opened at 2002-07-06 10:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=578063&group_id=22866 Category: Clustering Group: v3.1 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Thomas Peuss (tpeuss) Assigned to: Sacha Labourey (slaboure) Summary: HttpSession-clustering fails Initial Comment: The HttpSession-clustering mechanism fails to deploy on HEAD. Logfile follows: 12:38:09,775 ERROR [URLDeploymentScanner] Incomplete Deployment listing: Packages waiting for a deployer: Incompletely deployed packages: MBeans waiting for classes: MBeans waiting for other MBeans: [ObjectName: jboss:service=ClusteredHttpSession state: CREATED I Depend On: jboss.j2ee:service=EJB,jndiName=clustering/HTTPSession Depends On Me: , ObjectName: jboss.j2ee:service=EJB,jndiName=clustering/HTTPSession state: FAILED I Depend On: jboss:service=DefaultPartition Depends On Me: jboss:service=ClusteredHttpSession java.lang.RuntimeException: invoker is null: jboss:service=invoker,type=jrmp] 12:38:09,788 INFO [URLDeploymentScanner] Started 12:38:09,788 INFO [MainDeployer] Successfully completed deployment of package: file:/scratch/thomas/jboss-head/build/output/jboss-3.1.0alpha/server/default/co nf/jboss-service.xml 12:38:09,791 ERROR [Server] start failed Incomplete Deployment listing: Packages waiting for a deployer: Incompletely deployed packages: MBeans waiting for classes: MBeans waiting for other MBeans: [ObjectName: jboss:service=ClusteredHttpSession state: CREATED I Depend On: jboss.j2ee:service=EJB,jndiName=clustering/HTTPSession Depends On Me: , ObjectName: jboss.j2ee:service=EJB,jndiName=clustering/HTTPSession state: FAILED I Depend On: jboss:service=DefaultPartition Depends On Me: jboss:service=ClusteredHttpSession java.lang.RuntimeException: invoker is null: jboss:service=invoker,type=jrmp] at org.jboss.deployment.MainDeployer.checkIncompleteDeployments(MainDeployer.java:1098) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:601) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:582) 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.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:309) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:224) at org.jboss.Main.boot(Main.java:152) at org.jboss.Main$1.run(Main.java:385) at java.lang.Thread.run(Thread.java:536) 12:38:09,840 ERROR [STDERR] Incomplete Deployment listing: Packages waiting for a deployer: Incompletely deployed packages: MBeans waiting for classes: MBeans waiting for other MBeans: [ObjectName: jboss:service=ClusteredHttpSession state: CREATED I Depend On: jboss.j2ee:service=EJB,jndiName=clustering/HTTPSession Depends On Me: , ObjectName: jboss.j2ee:service=EJB,jndiName=clustering/HTTPSession state: FAILED I Depend On: jboss:service=DefaultPartition Depends On Me: jboss:service=ClusteredHttpSession java.lang.RuntimeException: invoker is null: jboss:service=invoker,type=jrmp] 12:38:09,843 ERROR [STDERR] at org.jboss.deployment.MainDeployer.checkIncompleteDeployments(MainDeployer.java:1098) 12:38:09,845 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:601) 12:38:09,845 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:582) 12:38:09,847 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 12:38:09,848 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 12:38:09,848 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 12:38:09,849 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:324) 12:38:09,850 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) 12:38:09,850 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) 12:38:09,850 ERROR [STDERR] at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:309) 12:38:09,850 ERROR [STDERR] at org.jboss.system.server.ServerImpl.start(ServerImpl.java:224) 12:38:09,850 ERROR [STDERR] at org.jboss.Main.boot(Main.java:152) 12:38:09,850 ERROR [STDERR] at org.jboss.Main$1.run(Main.java:385) 12:38:09,851 ERROR [STDERR] at java.lang.Thread.run(Thread.java:536) --
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
sorry single container looks like a good idea. It will probably be refactored a bit more to fit in the Aspect stuff. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > Sundstrom > Sent: Tuesday, October 22, 2002 10:22 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign > > > marc fleury wrote: > > One more request: stateless vs stateful interceptors. It is clear to me > > that both are needed. For example: stateful are easy to code you just > > have your variable in there and it is easy. A good example of stateless > > (taken from invocation) is the "read-ahead" interceptor. The read-ahead > > interceptor lives in the CMP stack (if you coded your CMP stack with > > interceptors). > > You need to have that information from the client. The client can then > > set the "READ-AHEAD" bucket to 3-5 or 20 or whatever it is that he wants > > to display, the invocation carries that information under the > > "READ-AHEAD" value and the interceptor reads it under that value *from > > the invocation*. It is my feeling that this is now a configuration > > thingy passed by the XML files. It is good as is, meaning we need the > > defaults to be configured by the XML file for all the invocations but > > let the Invocation overwrite them. > > > > Bottom line is that I believe the CMP optimization of READ-AHEAD is a > > good example of both coding practices, in fact they show the *need* for > > both. > > CMP will be an set of interceptors so this type of optimization will be > trivial. > > Based on the work I've already done, I think I can eliminate > EntityContainer, StatefullSessionContainer, StatelessSessionContainer > and MessageDrivenContainer and replace all of them with the single > Container class plus some interceptors. I'm not sure about this yet, > but it looks like it will be a simple solution in the end. > > -dain > > > > --- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
we want to get this stuff under Hiram's aspect framework so that not every subproject in JBoss uses a different interceptor mechanism. Take a look at Hiram's stuff. ITs good. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Dain > Sundstrom > Sent: Tuesday, October 22, 2002 10:22 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign > > > marc fleury wrote: > > One more request: stateless vs stateful interceptors. It is clear to me > > that both are needed. For example: stateful are easy to code you just > > have your variable in there and it is easy. A good example of stateless > > (taken from invocation) is the "read-ahead" interceptor. The read-ahead > > interceptor lives in the CMP stack (if you coded your CMP stack with > > interceptors). > > You need to have that information from the client. The client can then > > set the "READ-AHEAD" bucket to 3-5 or 20 or whatever it is that he wants > > to display, the invocation carries that information under the > > "READ-AHEAD" value and the interceptor reads it under that value *from > > the invocation*. It is my feeling that this is now a configuration > > thingy passed by the XML files. It is good as is, meaning we need the > > defaults to be configured by the XML file for all the invocations but > > let the Invocation overwrite them. > > > > Bottom line is that I believe the CMP optimization of READ-AHEAD is a > > good example of both coding practices, in fact they show the *need* for > > both. > > CMP will be an set of interceptors so this type of optimization will be > trivial. > > Based on the work I've already done, I think I can eliminate > EntityContainer, StatefullSessionContainer, StatelessSessionContainer > and MessageDrivenContainer and replace all of them with the single > Container class plus some interceptors. I'm not sure about this yet, > but it looks like it will be a simple solution in the end. > > -dain > > > > --- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggestion for JBOSS_CMP
I totally agree and this is already planned for JBoss 4.0. The real problem is not the code to do the loading but figuring out a simple xml structure to define the loading. -dain Emerson Cargnin - SICREDI Serviços wrote: I have a suggestion regarding to CMP : why not create a configuration to a find method to allow the container to load the relationships of a bean? This could be useful in the cases you have to read all the beans(or a good amount of then) and all (or almost all) relationships of them. eg : in a report you will have a sql to finding the pk's, one (at least) to load the bean data and one sql to each relation you have to report (for each bean). I think that one of the worse problem with CMP is that : database overhead. CMP generates too much sql commands that in some cases could be handled by fewer (if not one) sql commands. The DBA's in my company didn't like very much the trace they saw in the database for a very simple app. --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
marc fleury wrote: One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the "read-ahead" interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the "READ-AHEAD" bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the "READ-AHEAD" value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. CMP will be an set of interceptors so this type of optimization will be trivial. Based on the work I've already done, I think I can eliminate EntityContainer, StatefullSessionContainer, StatelessSessionContainer and MessageDrivenContainer and replace all of them with the single Container class plus some interceptors. I'm not sure about this yet, but it looks like it will be a simple solution in the end. -dain --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
While you guys discussed this like a bunch of academics, I have almost all of the code done. I'll commit it when I get back on Friday or Saturday. The changes I have made pass stateful information between interceptors using the Invocation object. Anyway, I'll let the code speak for me. -dain marc fleury wrote: Good point, answered online marc f -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net] On Behalf Of Bill Burke Sent: Monday, October 21, 2002 10:54 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign I think we need 2 types of interceptors Per instance(per target object) and Singleton (one interceptor serving all target objects). See my previous email for use cases. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Sunday, October 20, 2002 11:41 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign Previously we were on opposite sides of this debate:-) I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. This was the way I created the aspect stuff initially. The interceptors were tottaly statless. Even intercetor config was not stored in the interceptor. The config was put at the top of the stack. Advantage: 1 interceptor instance could be used for all stack instances. (less memory usage?? not really, the config objects are created and put at the top of the stack) Disadvantages: Hard to develop the interceptors and I think it lead to worse perfomance. I had to do a hashmap look up of the config every time it had to handle an invocation. --- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ 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 emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-620262 ] Trying to change Tx in enlist exception
Bugs item #620262, was opened at 2002-10-08 14:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620262&group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open >Resolution: Fixed Priority: 5 Submitted By: Marko Strukelj (mstruk) Assigned to: David Jencks (d_jencks) Summary: Trying to change Tx in enlist exception Initial Comment: When doing very intensive remote calls via statefull session, using the database with user managed transactions I often get this error: 2002-10-03 15:51:16,000 WARN [org.jboss.resource.connectionmanager.LocalTxConnecti onManager$LocalConnectionEventListener] in Enlisting tx, trying to change tx. illegal state: old: TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//233, BranchQual=], new: TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//234, BranchQual=], cel: org.jboss.resource.connectionmanager.LocalTxConnecti onManager$LocalConnectionEventListener@1f8d0a4 2002-10-03 15:51:16,000 ERROR [STDERR] java.lang.IllegalStateException: Trying to change Tx in enlist! 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnecti onManager$LocalConnectionEventListener.enlist (LocalTxConnectionManager.java:309) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnecti onManager.managedConnectionReconnected (LocalTxConnectionManager.java:255) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnection Manager2.allocateConnection (BaseConnectionManager2.java:534) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnection Manager2$ConnectionManagerProxy.allocateConnection (BaseConnectionManager2.java:812) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.local.LocalDataSource.g etConnection(LocalDataSource.java:102) It only happens when there is severe concurent use of the database. But it does happen a lot. What seems to happen is this: Thread 1: userTransaction.begin(); Connection c=ds.getConnection();// lets call this Connection1 // ... use connection c.close(); // close connection // now don't commit transaction yet Thread 2: userTransaction.begin(); Connection c=ds.getConnection(); // KABOOOM! Exception happens here. Exception happened because Connection1 was trying to be returned - the same connection that was used by another thread. In the time between returning a connection to the pool and calling commit on UserTransaction the same connection is checked out to another thread. I am trying to make an example to reproduce the bug. So far the only way I can reproduce it is on my production system with full application deployed. -- >Comment By: David Jencks (d_jencks) Date: 2002-10-22 23:25 Message: Logged In: YES user_id=60525 I think there was a race between close and commit checking if a connection could be returned and returning it to the pool. I've added some synchronization to the 3.0 branch to try to fix this. Please try it out and see if is fixed, then I will do something similar in the other branches. If you are using a later branch please let me know, I will check in something there for you to test. Thanks david jencks -- Comment By: Marko Strukelj (mstruk) Date: 2002-10-14 14:33 Message: Logged In: YES user_id=625403 Now I finally got to the bottom of this. Turns out the problem that the two threads get the same connection from the pool is due to connection being returned to the pool twice. I have a situation where connection is referenced by another object (ormsession object that represents an object relational mapper). This object is created upon request and it retrieves a database connection from a DataSource for its internal use. ormsession calls connection.close() in its finalize() and it does this through Finalizer thread - bad idea. Before this happens (or maybe after - I'm not sure) ut.commit () is done in the thread that got the ormsession before and this again causes the managed connection to be returned to the pool. The problem is that the described chain of events causes an inconsistent state in InternalManagedConnectionPool. Afterwards there are two different MCHolder instances referencing the same ManagedLocalConnection instance. This makes it possible that later that same MC is checked out twice. During this exploration I also realized that I am using the connection pool in such a way that "not participating properly in this management scheme." condition is always present. I have an MBean with its own thread and it is accessing DataSource directly without going through interceptors. Doing it this way is very convenient for me and
[JBoss-dev] scope of interceptors and aspect (cross cutting)
Let's take this talk online. David, let's talk about this as it is a good example of "EJB use a cache, most aspects don't" marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
Good point, answered online marc f > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net] On > Behalf Of Bill Burke > Sent: Monday, October 21, 2002 10:54 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign > > > I think we need 2 types of interceptors > > Per instance(per target object) and Singleton (one > interceptor serving all target objects). See my previous > email for use cases. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > > Hiram Chirino > > Sent: Sunday, October 20, 2002 11:41 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign > > > > > > > Previously we were on opposite sides of this debate:-) > > > > > > I think for simplicity we should have only stateless > interceptors, > > > any interceptor can store per-stack state in a the stack top in a > > > hashmap. > > > > > > > This was the way I created the aspect stuff initially. The > > interceptors were tottaly statless. Even intercetor config was not > > stored in the interceptor. The config was put at the top of the > > stack. > > > > Advantage: > > 1 interceptor instance could be used for all stack instances. (less > > memory usage?? not really, the config objects are created > and put at > > the top of the > > stack) > > > > Disadvantages: > > Hard to develop the interceptors and I think it lead to worse > > perfomance. I had to do a hashmap look up of the config > every time it > > had to handle an invocation. > > > > > > > > > > > > --- > > 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:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
See my responses online at www.jboss.org we need to start breaking down the development and letting people get in our development in a more transparent fashion. > 1. Interceptors do not belong in the JMX layer. JMX should > stay simple. If you want interceptors in front of an MBean, > you should make the MBean an aspect. Let's gut out the JMX > interceptors in favor of using Hiram's Aspect stuff when its > mature enough. Agreed. > 2. I really don't like this idea of storing state in some > detached hashmap somewhere. You're getting back to > functional programing with structures and functions. I agree > with Marc, hashmap.getvalue is just plain unreadable as well. Yes and no. I argue these online in response to your thread. marc f --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
Guys this is a great discussion but it needs to move to www.jboss.org/forums in the Aspects on JBoss forums marc f > -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net] On > Behalf Of Bill Burke > Sent: Tuesday, October 22, 2002 4:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > > David Jencks > > Sent: Monday, October 21, 2002 4:52 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign > > > > > > On 2002.10.21 10:50:45 -0400 Bill Burke wrote: > > > 1. Interceptors do not belong in the JMX layer. JMX should > > stay simple. > > > If > > > you want interceptors in front of an MBean, you should make the > > > MBean an aspect. Let's gut out the JMX interceptors in favor of > > > using Hiram's Aspect stuff when its mature enough. > > > > I disagree. Juha implemented the mbean server based on > interceptors > > for the same reason most of jboss is based on interceptors. > > > > I think there should only be one kind of interceptor stack, > used for > > mbeans, clients, aspects, ejbs. In the server, what's on the top > > makes it an mbean. In a client, it can be the proxy. For aspects, > > maybe something else. But we only need one kind of > interceptor (as in > > "interface that all interceptors implement" and "how do we > invoke each > > interceptor in the stack", not as in "they should all be > > stateless/ful). > > > > Yes there should be only one kind of interceptor stack. This > is the Aspect framework (all aspects are, are interceptors anyways). > > JMX worries about deployment, dependencies, management, > basically its a lightweight component framework. Aspects > provide the interceptors. If you implement an MBean as an > Aspect you can use the power of the Aspect framework. > Complete separation. As you said, there only needs to be one > kind of interceptor stack. This is the Aspect Framework. > > So both POJOs and MBeans can have interceptors via the Aspect > Framework. Unified. > > > > For ejbs, this will translate into a slightly odd kind of > mbean, since > > there won't exactly be one particular object at the end of > the stack, > > but rather the instance will get selected by one of the > interceptors. > > > > Its not odd at all. The object at the end of the stack is > the Interceptor that invokes on the actual EJB. > > > Bill > > > > > > > > > > 2. I really don't like this idea of storing state in some > detached > > > hashmap somewhere. You're getting back to functional programing > > > with structures and > > > functions. I agree with Marc, hashmap.getvalue is just > plain unreadable > > > as > > > well. > > > > > > Hiram, example of state? > > > An example is the "Nuke" pattern for replicated SFSB. > The state of > > > the SFSB stays with the client in the vent of a total > destruction of > > > the server. The > > > client provides the state in the event of a failover. > > > > > > Another is IDEMPOTENT methods. Idenpotent methods return > the same > > > value no matter what. An interceptor knowing this could > store the > > > state of the returned method call and avoid a remote invocation. > > > > > > The above are examples of state per instance. Now I believe you > > > would have singleton interceptors that needed to maintain > state. An > > > example is a client side interceptor that does clustering, > > > loadbalancing and > > failover. > > > It needs to maintain a list of available nodes. > > > > > > There are kind of 3 kinds of state: > > > > Configuration of interceptor instances of the same class, > conceptually > > from some kind of interceptor factory. This should > definitely be kept > > in the interceptor instance. Related to this is "which > interceptors > > are in the stack". Both of these are currently recorded in > jboss.xml > > as a config-name > > for ejb stacks. > > > > State of interceptor instances depending not on stack name but on > > identity the "top of stack object". This includes, for ejbs, stuff > > like local jndi environment, security proxy instances, tx-method > > associations. I think this is what we are debating. I > think it will > > lead to significantly simpler stack management and clearer thinking > > about interceptors to store this in a hashmap at the top of > the stack. > > If this state info is stored in the interceptors, you need > an instance > > of the interceptor for each "top of stack object". If it > is store in > > the "top of stack object", you only need one instance of each > > interceptor for each stack definition. > > > > Currently, most interceptors are stateless in this way, > although many > > already are stateless because they store the state info in > the "top of >
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of David > Jencks > Sent: Monday, October 21, 2002 4:52 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign > > > On 2002.10.21 10:50:45 -0400 Bill Burke wrote: > > 1. Interceptors do not belong in the JMX layer. JMX should > stay simple. > > If > > you want interceptors in front of an MBean, you should make the MBean an > > aspect. Let's gut out the JMX interceptors in favor of using Hiram's > > Aspect > > stuff when its mature enough. > > I disagree. Juha implemented the mbean server based on interceptors for > the same reason most of jboss is based on interceptors. > > I think there should only be one kind of interceptor stack, used for > mbeans, clients, aspects, ejbs. In the server, what's on the top makes it > an mbean. In a client, it can be the proxy. For aspects, maybe something > else. But we only need one kind of interceptor (as in "interface that all > interceptors implement" and "how do we invoke each interceptor in the > stack", not as in "they should all be stateless/ful). > Yes there should be only one kind of interceptor stack. This is the Aspect framework (all aspects are, are interceptors anyways). JMX worries about deployment, dependencies, management, basically its a lightweight component framework. Aspects provide the interceptors. If you implement an MBean as an Aspect you can use the power of the Aspect framework. Complete separation. As you said, there only needs to be one kind of interceptor stack. This is the Aspect Framework. So both POJOs and MBeans can have interceptors via the Aspect Framework. Unified. > For ejbs, this will translate into a slightly odd kind of mbean, since > there won't exactly be one particular object at the end of the stack, but > rather the instance will get selected by one of the interceptors. > Its not odd at all. The object at the end of the stack is the Interceptor that invokes on the actual EJB. Bill > > > > > 2. I really don't like this idea of storing state in some detached > > hashmap > > somewhere. You're getting back to functional programing with structures > > and > > functions. I agree with Marc, hashmap.getvalue is just plain unreadable > > as > > well. > > > > Hiram, example of state? > > An example is the "Nuke" pattern for replicated SFSB. The state of the > > SFSB > > stays with the client in the vent of a total destruction of the server. > > The > > client provides the state in the event of a failover. > > > > Another is IDEMPOTENT methods. Idenpotent methods return the same value > > no > > matter what. An interceptor knowing this could store the state of the > > returned method call and avoid a remote invocation. > > > > The above are examples of state per instance. Now I believe you would > > have > > singleton interceptors that needed to maintain state. An example is a > > client side interceptor that does clustering, loadbalancing and > failover. > > It needs to maintain a list of available nodes. > > > There are kind of 3 kinds of state: > > Configuration of interceptor instances of the same class, > conceptually from > some kind of interceptor factory. This should definitely be kept in the > interceptor instance. Related to this is "which interceptors are in the > stack". Both of these are currently recorded in jboss.xml as a > config-name > for ejb stacks. > > State of interceptor instances depending not on stack name but on identity > the "top of stack object". This includes, for ejbs, stuff like local jndi > environment, security proxy instances, tx-method associations. I think > this is what we are debating. I think it will lead to significantly > simpler stack management and clearer thinking about interceptors to store > this in a hashmap at the top of the stack. If this state info is > stored in > the interceptors, you need an instance of the interceptor for each "top of > stack object". If it is store in the "top of stack object", you only need > one instance of each interceptor for each stack definition. > > Currently, most interceptors are stateless in this way, although many > already are stateless because they store the state info in the "top of > stack object". I'm proposing that we formalize this and make the > remaining > interceptors (such as security proxy) use this model as well. > > Thirdly, there is state from the method invocation. I think everyone > agrees that this state should stay in the method invocation, and we should > not create and configure a stack for each invocation. > > david jencks > > > > > > Bill > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > > Hiram > > > Chirino > > > Sent: Sunday, October 20, 2002 11:25 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign > > > > >
[JBoss-dev] Cannot build off the head.
Should there be xdoclet stuff in thirdparty as per the libraries.ent file in tools/etc/buildfragments? In my cvs co jboss-head there's no xdoclet stuff in thirdparty whatsoever and the classnames in tools.ent do not reflect the package names in the xdoclet-1.1.2 that I already have on disk. [Robert-Nicholsons-Computer:~/Archives/jboss-head/build] robert% ./build.sh build.sh: Executing: /Users/robert/Archives/jboss-head/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/Users/robert/Archives/jboss-head/build/../tools/etc/ buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 3 seconds [Robert-Nicholsons-Computer:~/Archives/jboss-head/build] robert% --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-621664 ] test hangs with 3.0.3 but passes 3.0.2
Bugs item #621664, was opened at 2002-10-11 01:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=621664&group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 7 Submitted By: Joe Simone (jsimone) Assigned to: Nobody/Anonymous (nobody) Summary: test hangs with 3.0.3 but passes 3.0.2 Initial Comment: OS: Win XP Pro, SP1 JDK 1.3.1_05 I have a test that creates sample data in my DB2 database. Using DB2 EE 7.2 with fixpack 7 applied. If I run the data creator under 3.0.2/4.0.4 then it runs to completion. If I run the data creator under 3.0.3/4.1.12 then my console client just stops midway. I'll get a WARN about timeout with STATUS_ACTIVE. How can I enable debug so I can provide more info? P.S. didn't know which component to open under so I just picked JBossTX -- >Comment By: David Jencks (d_jencks) Date: 2002-10-22 15:33 Message: Logged In: YES user_id=60525 Your thread dump makes it look like db2 is hung on the fetch entity command. Can you investigate this and determine what the sql is and what db2 has to say about it? This would be consistent with a db2 process becoming unusable... -- Comment By: Joe Simone (jsimone) Date: 2002-10-22 14:30 Message: Logged In: YES user_id=586242 Has there been any action on this problem? I have stopped using 3.0.3 and gone back to 3.0.2 since this occurred. BTW, when the server/app freezes and I close down the JBoss server, one or more of my DB2 processes are toast! This is the first time I have seen JBoss killing my database server! -- Comment By: Joe Simone (jsimone) Date: 2002-10-14 21:40 Message: Logged In: YES user_id=586242 CTRL-BREAK results in ... 17:27:35,505 INFO [Server] JBoss (MX MicroKernel) [3.0.3 Date:200209301503] Started in 0m:20s:459ms Full thread dump: "SeedGenerator Thread" daemon prio=2 tid=0x164b4478 nid=0x8c8 waiting on monitor [0x1753f000..0x1753fdbc] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:415) at sun.security.provider.SeedGenerator.run (SeedGenerator.java:100) at java.lang.Thread.run(Thread.java:479) "RMI TCP Connection(4)-192.168.2.35" daemon prio=5 tid=0x15b60eb0 nid=0x310 runnable [0x174fe000..0x174ffdbc] at COM.ibm.db2.jdbc.app.DB2PreparedStatement.SQLExecute (Native Method) at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2 (DB2PreparedStatement.java:2065) at COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeQuer y(DB2PreparedStatement.java:1596) at org.jboss.resource.adapter.jdbc.local.LocalPreparedStatemen t.executeQuery(LocalPreparedStatement.java:289) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.ex ecute(JDBCLoadEntityCommand.java:122) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.ex ecute(JDBCLoadEntityCommand.java:62) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity (JDBCStoreManager.java:572) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity (CMPPersistenceManager.java:410) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.loadEntity(CachedConnectionInterceptor.java: 353) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke (EntitySynchronizationInterceptor.java:262) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke (EntityReentranceInterceptor.java:90) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke (EntityInstanceInterceptor.java:152) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockInterceptor.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke (EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions (TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke (BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.EntityProxy.invoke (EntityProxy.java:38) at $Proxy68.getName(Unknown Source) at com.highnotes.ebu.enrollment.eventmanager.EventManagerB ean._convertMaterialsToDataObjects(EventManagerBean.ja va:388) at com.h
[JBoss-dev] [ jboss-Bugs-626893 ] Suggestion to CMP (relations read-ahead)
Bugs item #626893, was opened at 2002-10-22 12:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626893&group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Emerson Cargnin (echofloripa) Assigned to: Nobody/Anonymous (nobody) Summary: Suggestion to CMP (relations read-ahead) Initial Comment: I have a suggestion regarding to CMP : why not create a configuration to a find method to allow the container to load the relationships of a bean? This could be useful in the cases you have to read all the beans(or a good amount of then) and all (or almost all) relationships of them. eg : in a report you will have a sql to finding the pk's, one (at least) to load the bean data and one sql to each relation you have to report (for each bean). I think that one of the worse problem with CMP is that : database overhead. CMP generates too much sql commands that in some cases could be handled by fewer (if not one) sql commands. The DBA's in my company didn't like very much the trace they saw in the database for a very simple app. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626893&group_id=22866 --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-621664 ] test hangs with 3.0.3 but passes 3.0.2
Bugs item #621664, was opened at 2002-10-10 21:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=621664&group_id=22866 >Category: JBossServer Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Joe Simone (jsimone) Assigned to: Nobody/Anonymous (nobody) Summary: test hangs with 3.0.3 but passes 3.0.2 Initial Comment: OS: Win XP Pro, SP1 JDK 1.3.1_05 I have a test that creates sample data in my DB2 database. Using DB2 EE 7.2 with fixpack 7 applied. If I run the data creator under 3.0.2/4.0.4 then it runs to completion. If I run the data creator under 3.0.3/4.1.12 then my console client just stops midway. I'll get a WARN about timeout with STATUS_ACTIVE. How can I enable debug so I can provide more info? P.S. didn't know which component to open under so I just picked JBossTX -- >Comment By: Joe Simone (jsimone) Date: 2002-10-22 10:30 Message: Logged In: YES user_id=586242 Has there been any action on this problem? I have stopped using 3.0.3 and gone back to 3.0.2 since this occurred. BTW, when the server/app freezes and I close down the JBoss server, one or more of my DB2 processes are toast! This is the first time I have seen JBoss killing my database server! -- Comment By: Joe Simone (jsimone) Date: 2002-10-14 17:40 Message: Logged In: YES user_id=586242 CTRL-BREAK results in ... 17:27:35,505 INFO [Server] JBoss (MX MicroKernel) [3.0.3 Date:200209301503] Started in 0m:20s:459ms Full thread dump: "SeedGenerator Thread" daemon prio=2 tid=0x164b4478 nid=0x8c8 waiting on monitor [0x1753f000..0x1753fdbc] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:415) at sun.security.provider.SeedGenerator.run (SeedGenerator.java:100) at java.lang.Thread.run(Thread.java:479) "RMI TCP Connection(4)-192.168.2.35" daemon prio=5 tid=0x15b60eb0 nid=0x310 runnable [0x174fe000..0x174ffdbc] at COM.ibm.db2.jdbc.app.DB2PreparedStatement.SQLExecute (Native Method) at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2 (DB2PreparedStatement.java:2065) at COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeQuer y(DB2PreparedStatement.java:1596) at org.jboss.resource.adapter.jdbc.local.LocalPreparedStatemen t.executeQuery(LocalPreparedStatement.java:289) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.ex ecute(JDBCLoadEntityCommand.java:122) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.ex ecute(JDBCLoadEntityCommand.java:62) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity (JDBCStoreManager.java:572) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity (CMPPersistenceManager.java:410) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.loadEntity(CachedConnectionInterceptor.java: 353) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke (EntitySynchronizationInterceptor.java:262) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke (EntityReentranceInterceptor.java:90) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke (EntityInstanceInterceptor.java:152) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockInterceptor.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke (EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions (TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke (BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.EntityProxy.invoke (EntityProxy.java:38) at $Proxy68.getName(Unknown Source) at com.highnotes.ebu.enrollment.eventmanager.EventManagerB ean._convertMaterialsToDataObjects(EventManagerBean.ja va:388) at com.highnotes.ebu.enrollment.eventmanager.EventManagerB ean.getMaterialsAll(EventManagerBean.java:3026) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor .invoke(StatelessSessionContainer.java:660) at org.jboss.resource.connectionmanager.CachedConnectionInte rceptor.invoke(CachedConnectionInterceptor.java:186)
[JBoss-dev] jboss-applications build problem
Hello, I've checked out jboss-applications module from CVS, put all jars from jboss-applications/tools/lib/ including crimson.jar into my CLASSPATH, but build.sh tells me: $ ./build.sh build.sh: Executing: /home/koles/eclipse/workspace/jboss-applications/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml BUILD FAILED XML parser factory has not been configured correctly: Provider org.apache.crimson.jaxp.SAXParserFactoryImpl not found Does anybody have an idea what I am doing wrong? The version I've checked out before Jason's CVS changes works OK, but I can't say if there's any connection or if it's just coincidence. I'm using JDK 1.3.1_04 on RedHat 7.3 Thanks for any suggestions. Pavel --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-626854 ] Error using ibm jdk 1.4 in AIX
Bugs item #626854, was opened at 2002-10-22 11:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626854&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Emerson Cargnin (echofloripa) Assigned to: Nobody/Anonymous (nobody) Summary: Error using ibm jdk 1.4 in AIX Initial Comment: I'm using AIX 5.1 in a IBM M80 (8 processors) 8 giga RAM and ibm jdk1.4 64 bits. while jboss3.0.0 it's running ok, just with 3.0.3 i have the following error message : 17:55:43,903 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/xalan.jar 17:55:43,904 INFO [MainDeployer] Package: file:/optlocal/java/jboss-3.0.3/server/default/lib/xalan.jar is already deployed 17:55:43,925 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/ant.jar 17:55:43,926 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jboss-management.jar 17:55:43,984 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jboss-management.jar 17:55:43,984 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/mail.jar 17:55:44,093 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/mail.jar 17:55:44,094 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jnet.jar 17:55:44,127 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jnet.jar 17:55:44,127 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jboss.jar 17:55:44,432 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jboss.jar 17:55:44,432 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jboss-jca.jar 17:55:44,487 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jboss-jca.jar 17:55:44,488 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jaas.jar 17:55:44,628 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jaas.jar 17:55:44,629 INFO [MainDeployer] Package: file:/optlocal/java/jboss-3.0.3/server/default/lib/xalan.jar is already deployed 17:55:44,629 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jbossha.jar 17:55:44,691 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jbossha.jar 17:55:44,692 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/bcel.jar 17:55:44,812 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/bcel.jar 17:55:44,813 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jcert.jar 17:55:44,836 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jcert.jar 17:55:44,837 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jmxtools.jar 17:55:44,871 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jmxtools.jar 17:55:44,872 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/properties-plugin.jar 17:55:44,903 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/properties-plugin.jar 17:55:44,904 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/hsqldb.jar 17:55:44,983 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/hsqldb.jar 17:55:44,983 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/counter-plugin.jar 17:55:45,017 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/counter-plugin.jar 17:55:45,017 INFO [MainDeployer] Starting deployment of package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jmxri.jar 17:55:45,098 INFO [MainDeployer] Deployed package: file:/optlocal/java/jboss-3.0.3/server/default/lib/jmxri.jar 17:55:46,473 INFO [PropertyEditorManagerService] Creating 17:55:46,473 INFO [PropertyEditorManagerService] Created 17:55:46,474 INFO [SystemPropertiesService] Creating 17:55:46,474 INFO [SystemPropertiesService] Created 17:55:46,477 INFO [Log4jService] Creating 17:55:46,477 INFO [Log4jService] Created 17:55:46,478 INFO [WebService] Creating 17:55:46,478 INFO [WebService] Created 17:55:46,479 WARN [ServiceController] jboss.management.single:j2eeType=J2EEDomain,name=Manager does not implement any Service methods 1
[JBoss-dev] [ jboss-Bugs-626430 ] Verifier complains about java.lang.Exception being thrown
Bugs item #626430, was opened at 2002-10-21 12:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626430&group_id=22866 Category: JBossServer Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sean hager (seanhager) Assigned to: Christian Riege (lqd) Summary: Verifier complains about java.lang.Exception being thrown Initial Comment: 12:09:06,468 INFO [EJBDeployer] Bean : PIVItem Method : public abstract Object getParentKey() throws Exception Section: 7.10.7 Warning: The methods in the local interface must not include java.rmi.RemoteException in their throws clause. Should not issue a RemoteException warning when throwing an "Exception" In the above statement, only an Exception is being thrown not a RemoteException. If I change the exception to an EJB exception I do not get a warning. Sean. -- >Comment By: Sean hager (seanhager) Date: 2002-10-22 07:27 Message: Logged In: YES user_id=532458 Thank you for your quick response. I do appriciate you fixing the problem. Just to offer a simple rebuttle, we let all unanticipated exceptions float up to the proxy ejb class where they are logged and handled before nested in a remote exception and sent to the client. This simple approach saves a bunch of try catch wrap and rethrow code that would add no value to the application. When we do find that there is an exception that we can recover from we add in the try catch, and do so, or rethrow if we can't recover from it. -- Comment By: Christian Riege (lqd) Date: 2002-10-22 03:49 Message: Logged In: YES user_id=176671 matter of fact, if you change the very generic java.lang.Exception to anything else besides a RemoteException or any of its subclasses the error message will disappear. anyways, i have fixed this in the Verifier. It now explicitly allows a java.lang.Exception to be thrown on local interface methods. Although IMHO you really should use a more specific Exception ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626430&group_id=22866 --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-610223 ] Classloader NPE in dependent redeploy
Bugs item #610223, was opened at 2002-09-16 23:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610223&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: Fixed Priority: 7 Submitted By: Michael Bartmann (bartmann) Assigned to: David Jencks (d_jencks) Summary: Classloader NPE in dependent redeploy Initial Comment: There is a problem under 3.2 when redeploying an ear with several dependent ears. When redeploying the dependent ears "manually" everything works ok. When instead I redeploy the ear they depend on, they get re-created, but after the destroy nulled their classloader. This results in an NPE during redeployment. Tested under Branch_3_2, checkout 16.09.2002. OS Windows NT 4.0, JDK 1.4.0_01 -- >Comment By: Michael Bartmann (bartmann) Date: 2002-10-22 13:30 Message: Logged In: YES user_id=69300 I had some other problems in between which kept my from deploying under HEAD (classloading issues fixed by Adrian). Now we got a chance to test (using HEAD as of 2002-10-21) our results are: When we redeploy the "root"-ear which the other ears depend on there is no NPE anymore (and no other exception either), but thereafter many EJBs (even in the "root"-ear) are not in state STARTED, but in state DESTROYED; starting them one by one through html-console works. There were even EJBs in the central ear which were not restarted correctly. -- Comment By: David Jencks (d_jencks) Date: 2002-09-19 17:49 Message: Logged In: YES user_id=60525 I believe I have fixed this in HEAD. I'd appreciate verification before I backport it to 3.2, since it is a substantial refactoring of the ejb deployment/service lifecycle code. I'll close this after backporting to 3.2. -- Comment By: David Jencks (d_jencks) Date: 2002-09-17 07:51 Message: Logged In: YES user_id=60525 Thanks, now I know what the problem is, I just have to fix it. -- Comment By: Michael Bartmann (bartmann) Date: 2002-09-17 07:14 Message: Logged In: YES user_id=69300 Below comes the blurb from jboss.xml. Only the MDB in the dependent ear is declared to be dependent of the "common" ear. Each of the dependent ears also contains a custom JMSProvider with its container-configuration. Did I mention that all my ears have their own scope? BTW: Starting any stoping the contained JMSProvider through JMX is another problem, cause the server doesn't provide the correct TCL when calling the management methods from remote. But in the bug we are just discussing this is no problem, cause the JMSProvider is not restarted. ACTControlSystemReceiver ACT Message Driven Bean queue/ACTFLS FLS geheim ejb/ControlSystemManager transport/ControlSystemManager fs4p.act:service=MS4PMessageService fs4p.act:service=JMSProviderLoader,name=ACTJMSProvider fs4p.act:service=ServerSessionPoolMBean,name=ACTJMSPool jboss.j2ee:service=EJB,jndiName=transport/ControlSystemManager jboss.j2ee:service=EJB,jndiName=material/Material -- Comment By: David Jencks (d_jencks) Date: 2002-09-17 00:26 Message: Logged In: YES user_id=60525 I see what causes some of the problem, I think it shows up if you stop, destroy, create, and start an ejb through the jmx console. However, could you be more specific about how you are specifying the dependency between the ears? I'm not quite sure why the references to the containers in the dependent .ear are getting saved. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=610223&group_id=22866 --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] (no subject)
--- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-626430 ] Verifier complains about java.lang.Exception being thrown
Bugs item #626430, was opened at 2002-10-21 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626430&group_id=22866 Category: JBossServer Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sean hager (seanhager) >Assigned to: Christian Riege (lqd) >Summary: Verifier complains about java.lang.Exception being thrown Initial Comment: 12:09:06,468 INFO [EJBDeployer] Bean : PIVItem Method : public abstract Object getParentKey() throws Exception Section: 7.10.7 Warning: The methods in the local interface must not include java.rmi.RemoteException in their throws clause. Should not issue a RemoteException warning when throwing an "Exception" In the above statement, only an Exception is being thrown not a RemoteException. If I change the exception to an EJB exception I do not get a warning. Sean. -- >Comment By: Christian Riege (lqd) Date: 2002-10-22 10:49 Message: Logged In: YES user_id=176671 matter of fact, if you change the very generic java.lang.Exception to anything else besides a RemoteException or any of its subclasses the error message will disappear. anyways, i have fixed this in the Verifier. It now explicitly allows a java.lang.Exception to be thrown on local interface methods. Although IMHO you really should use a more specific Exception ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626430&group_id=22866 --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-626540 ] exceptions from mbean-info-db-service
Bugs item #626540, was opened at 2002-10-21 22:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626540&group_id=22866 Category: None Group: v4.0 Status: Open Resolution: None Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Nobody/Anonymous (nobody) Summary: exceptions from mbean-info-db-service Initial Comment: The deployment of mbean-info-db-service.xml gives me exceptions on startup of jboss-head. See attached extract from server.log. (JBoss-Head, current checkout, JDK 1.4.1 on Linux ) -- >Comment By: Christian Riege (lqd) Date: 2002-10-22 10:25 Message: Logged In: YES user_id=176671 Matt, have a look at org.jboss.metadata.XmlFileLoader which defines a custom Resolver for loading the DTD's from within a jar itself depending upon the PUBLIC DocId. Using this or a variant thereof might be the solution. -- Comment By: Matthew Munz (mattmunz) Date: 2002-10-21 23:16 Message: Logged In: YES user_id=340814 I think that the problem here is that the xmbean DTD cannot be found. I wrote MBean-Info-xmbeandd.xml, and I think it works on my machine because I generated the documentation for jboss (this includes DTDs in the location requested). I'm sure that there must be a beter way to specify the XMBean DTD. Could someone on jboss-dev please give an example? Also note that this service is not currently required for any feature of the server. Feel free to delete the offending file from your deploy folder. - Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=626540&group_id=22866 --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
