Re: [JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
That was me. I agree, we shouldn't force finders to run under active transaction. The reason for the change was a bug in cleaning ReadAheadCache. I'll look at it. alex Friday, June 27, 2003, 3:11:02 AM, Scott Stark wrote: SMS So why was this change made? There is a difference between yelling at SMS the user for running under a scenario with potentially n^2 related SMS performance degradation and breaking a working app. -- Scott Stark Chief Technology Officer JBoss Group, LLC Original Message Subject: [JBoss-user] Read-Ahead Cache Supports Date: Thu, 26 Jun 2003 15:47:23 -0700 From: Gavin Matthews [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] CC: Gavin Matthews [EMAIL PROTECTED] All, I'm upgrading from 3.2.0 to 3.2.2(RC1) and I hit an incompatibility with the new(?) ReadAheadCache implementation and the finder transaction type. Basically if I have a finder with transaction-type=Supports and use read-ahead-strategy=on-find then I get the following exception if I'm outside of a transaction: 14:43:55,968 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: There is no tranaction associated with the current thread at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.getTransaction(TransactionLo cal.java:206) at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get(TransactionLocal.java:11 8) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.getCache(ReadAheadCa che.java:624) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.add(ReadAheadCache.j ava:570) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinderResults(ReadAheadCach e.java:114) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstract QueryCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstract QueryCommand.java:91) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFindEntit iesCommand.java:40) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreManage r.java:599) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistenceManag er.java:324) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntitie s(CachedConnectionInterceptor.java:323) at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:604) The fix for me is trivial, I can switch to transaction-type=Required without any issues but I think there is a bug here, the ReadAheadCache should only be used if you're already in a transaction (the read-ahead cache strategy is forcing the transaction-type decision which seems wrong to me). thanks, gavin --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Antwort: Re: [JBoss-dev] Re: default web server
Hi Frank, can you give some more detailed informations about your 'much better' experiences with Jetty ? Would be interesting ! Regards Ulf Frank Morton [EMAIL PROTECTED] Gesendet von: [EMAIL PROTECTED] 27.06.2003 03:05 Bitte antworten an jboss-development An:[EMAIL PROTECTED] Kopie: Thema:Re: [JBoss-dev] Re: default web server We will continue to use Jetty no matter. Our experience has been much better with Jetty than Tomcat. On Thursday, June 26, 2003, at 06:30 PM, Greg Wilkins wrote: Scott M Stark wrote: Simply because Tomcat is the defacto standard and the default choice for most of our users and I'm not happy with the level of integration we currently offer. For those of you who are using Jetty and are happy with that choice, I just want to assure you that regardless of what decisions the JBoss Group make, that Jetty in JBoss will continue to be supported by a strong open source community sponsored by Mort Bay and commercial support will be available for it from the core developers network. So we are continuing to develop and support the jetty sar for JBoss and hopefully it will continue to live in the JBoss project (although we may want to review the duplicate source tree issue). The intent will be to keep the web container services totally pluggable so that you can simple drop in the web sar of *your* choice. regards -- /** * Greg Wilkins * Partner * Core Developers Network **/ There's a difference between knowing the path and walking the path - morpheus --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tyrex transaction manager
From what I heard at JavaOne from a couple of people (e.g., Macromedia use a cut of it in their app. server), it's dead. Mark. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 4:54 PM Subject: RE: [JBoss-dev] Tyrex transaction manager Anatoly Akkerman was maintaining it a lnnng time ago. Nobody really uses it or used it. I think the project is dead since their last release was May 2002 and they only have one CVS committer. http://sourceforge.net/projects/tyrex/ Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bruce Snyder Sent: Thursday, June 26, 2003 11:10 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Tyrex transaction manager This one time, at band camp, Bill Burke said: BBWe will not be supporting the Tyrex transaction manager anymore unless you BBwant to take over the integration. I'm just curious, why was this decision made? Who used to maintain this integration? Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\F9EG)E=\$\!FFEI+F-O;0\`\`);' --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JSR-77: EAR sub-modules?
Hello, Is that intended or a bug that in JSR-77, the EAR never has any sub-modules listed (always empty). Cheers, Sacha --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JSR-77: EAR sub-modules?
Must be a bug. I'll look at this tomorrow when I look into some other jsr-77 issues. -- Scott Stark Chief Technology Officer JBoss Group, LLC Sacha Labourey wrote: Hello, Is that intended or a bug that in JSR-77, the EAR never has any sub-modules listed (always empty). Cheers, Sacha --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JSR-77: EAR sub-modules?
Sorry, the pre-written e-mail went away when I connected to the Internet: I found the bug and fixed it locally. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: vendredi, 27. juin 2003 16:10 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JSR-77: EAR sub-modules? Must be a bug. I'll look at this tomorrow when I look into some other jsr-77 issues. -- Scott Stark Chief Technology Officer JBoss Group, LLC Sacha Labourey wrote: Hello, Is that intended or a bug that in JSR-77, the EAR never has any sub-modules listed (always empty). Cheers, Sacha --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
Alexey, Did you make this change or was it me? Either way, I think it is my fault as I was the one that re-enabled running with out a transaction and didn't add any integration tests. -dain On Friday, June 27, 2003, at 02:07 AM, Alexey Loubyansky wrote: That was me. I agree, we shouldn't force finders to run under active transaction. The reason for the change was a bug in cleaning ReadAheadCache. I'll look at it. alex Friday, June 27, 2003, 3:11:02 AM, Scott Stark wrote: SMS So why was this change made? There is a difference between yelling at SMS the user for running under a scenario with potentially n^2 related SMS performance degradation and breaking a working app. -- Scott Stark Chief Technology Officer JBoss Group, LLC Original Message Subject: [JBoss-user] Read-Ahead Cache Supports Date: Thu, 26 Jun 2003 15:47:23 -0700 From: Gavin Matthews [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] CC: Gavin Matthews [EMAIL PROTECTED] All, I'm upgrading from 3.2.0 to 3.2.2(RC1) and I hit an incompatibility with the new(?) ReadAheadCache implementation and the finder transaction type. Basically if I have a finder with transaction-type=Supports and use read-ahead-strategy=on-find then I get the following exception if I'm outside of a transaction: 14:43:55,968 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: There is no tranaction associated with the current thread at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.getTransaction(Transact ionLo cal.java:206) at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get(TransactionLocal.ja va:11 8) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.getCache(ReadAh eadCa che.java:624) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.add(ReadAheadCa che.j ava:570) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinderResults(ReadAhea dCach e.java:114) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract QueryCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract QueryCommand.java:91) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFind Entit iesCommand.java:40) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreM anage r.java:599) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistence Manag er.java:324) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEn titie s(CachedConnectionInterceptor.java:323) at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:604) The fix for me is trivial, I can switch to transaction-type=Required without any issues but I think there is a bug here, the ReadAheadCache should only be used if you're already in a transaction (the read-ahead cache strategy is forcing the transaction-type decision which seems wrong to me). thanks, gavin --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development /* * Dain Sundstrom * Partner * Core Developers Network */ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[2]: [JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
Hello Dain, That was me. I switched to TransactionLocal in ReadAheadCache. Before that, just List and Map were used for caching and there were issues with their cleanning which affected subsequent transactions. As the stacktrace shows, the exception occurs right in TransactionLocal.getTransaction(). There is some nice trick needed to not call ReadAheadCache or do nothing in ReadAheadCache when there is no active tx. alex Friday, June 27, 2003, 6:15:39 PM, Dain Sundstrom wrote: DS Alexey, DS Did you make this change or was it me? Either way, I think it is my DS fault as I was the one that re-enabled running with out a transaction DS and didn't add any integration tests. DS -dain DS On Friday, June 27, 2003, at 02:07 AM, Alexey Loubyansky wrote: That was me. I agree, we shouldn't force finders to run under active transaction. The reason for the change was a bug in cleaning ReadAheadCache. I'll look at it. alex Friday, June 27, 2003, 3:11:02 AM, Scott Stark wrote: SMS So why was this change made? There is a difference between yelling at SMS the user for running under a scenario with potentially n^2 related SMS performance degradation and breaking a working app. -- Scott Stark Chief Technology Officer JBoss Group, LLC Original Message Subject: [JBoss-user] Read-Ahead Cache Supports Date: Thu, 26 Jun 2003 15:47:23 -0700 From: Gavin Matthews [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] CC: Gavin Matthews [EMAIL PROTECTED] All, I'm upgrading from 3.2.0 to 3.2.2(RC1) and I hit an incompatibility with the new(?) ReadAheadCache implementation and the finder transaction type. Basically if I have a finder with transaction-type=Supports and use read-ahead-strategy=on-find then I get the following exception if I'm outside of a transaction: 14:43:55,968 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: There is no tranaction associated with the current thread at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.getTransaction(Transact ionLo cal.java:206) at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get(TransactionLocal.ja va:11 8) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.getCache(ReadAh eadCa che.java:624) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.add(ReadAheadCa che.j ava:570) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinderResults(ReadAhea dCach e.java:114) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract QueryCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract QueryCommand.java:91) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFind Entit iesCommand.java:40) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreM anage r.java:599) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistence Manag er.java:324) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEn titie s(CachedConnectionInterceptor.java:323) at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:604) The fix for me is trivial, I can switch to transaction-type=Required without any issues but I think there is a bug here, the ReadAheadCache should only be used if you're already in a transaction (the read-ahead cache strategy is forcing the transaction-type decision which seems wrong to me). thanks, gavin --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development DS /* DS * Dain Sundstrom DS * Partner DS * Core Developers Network DS */ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JSR-77: EAR sub-modules?
Commit or send me that change so I can get head synched up with 3.2. -- Scott Stark Chief Technology Officer JBoss Group, LLC Sacha Labourey wrote: Sorry, the pre-written e-mail went away when I connected to the Internet: I found the bug and fixed it locally. --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Undelivered Mail Returned to Sender
This is the Postfix program at host jerry.hpbroadcasting.com. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to postmaster If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program [EMAIL PROTECTED]: can't create user output file Reporting-MTA: dns; jerry.hpbroadcasting.com Arrival-Date: Fri, 27 Jun 2003 12:18:55 -0400 (EDT) Final-Recipient: rfc822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; can't create user output file ---BeginMessage--- This is a multipart message in MIME format Please see the attached zip file for details. your_details.zip Description: Zip compressed data ---End Message---
[JBoss-dev] [ jboss-Bugs-758484 ] Create SubContext not replicated
Bugs item #758484, was opened at 2003-06-21 19:46 Message generated for change (Comment added) made by slaboure You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=758484group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 5 Submitted By: Jens Schumann (french_c) Assigned to: Sacha Labourey (slaboure) Summary: Create SubContext not replicated Initial Comment: Create SubContext (and possibly destroySubcontext) is not replicated across HA JNDI Trees. This way object bind/rebind/etc calls will be broadcasted, however the tree will be out of sync. Example: Use the code in bug #758476 and execute it (with two different jndi names) on both nodes while both are running. Lets say the code was executed on node one first, on node two second. Now on node one the sub context contains both objects, node two will have its own object only. After that replication within this sub context will work as expected. Tested on JBoss 3.0.7. -- Comment By: Sacha Labourey (slaboure) Date: 2003-06-27 20:13 Message: Logged In: YES user_id=95900 Fixed in 3.2, waiting for further feedback before applying on 3.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=758484group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-758476 ] SubContexts and Cluster Node getState
Bugs item #758476, was opened at 2003-06-21 19:12
Message generated for change (Comment added) made by slaboure
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=758476group_id=22866
Category: Clustering
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jens Schumann (french_c)
Assigned to: Sacha Labourey (slaboure)
Summary: SubContexts and Cluster Node getState
Initial Comment:
Node getState() fails in case the HA JNDI Tree contains
a sub context. As soon as a new node joins the cluster
state synchronisation will result in a
java.io.NotSerializableException. I have been looking
in the source and it seems that a simple getState()
returning the Hashtable is not the appropriate way to
synchronize a the JNDI Tree. The required changes may
involve changes in the NamingContext/NamingServer
classes, so I stopped looking for a solution.
---
Example:
Execute the follwing code on one node while the second
node is not active:
Hashtable properties = {HA JNDI Properties}
InitialContext ctx = new InitialContext(properties);
Context subCtx = (Context)ctx.createSubcontext(Test)
subCtx.rebind(foo,bar);
Start the second node.
Tested against 3.0.7.
-
2003-06-21 17:57:44,354 ERROR
[org.jboss.ha.framework.server.HAPartitionImpl.DefaultPartition]
GetState failed
java.io.NotSerializableException:
org.jboss.ha.framework.server.HAPartitionImpl
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
java.util.Hashtable.writeObject(Hashtable.java:802)
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
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:795)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at java.util.HashMap.writeObject(HashMap.java:958)
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
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:795)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at
org.jboss.ha.framework.server.HAPartitionImpl.objectToByteBuffer(HAPartitionImpl.java:123)
at
org.jboss.ha.framework.server.HAPartitionImpl.getState(HAPartitionImpl.java:311)
at
org.javagroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:460)
at
org.javagroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:294)
at
org.javagroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:513)
at org.javagroups.JChannel.up(JChannel.java:841)
at
org.javagroups.stack.ProtocolStack.up(ProtocolStack.java:302)
at
org.javagroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:318)
at
org.javagroups.stack.Protocol.passUp(Protocol.java:435)
at
[JBoss-dev] [ jboss-Patches-762041 ] OR grouping JAAS login module
Patches item #762041, was opened at 2003-06-27 21:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=762041group_id=22866 Category: JBossSX Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hauer (hauer) Assigned to: Nobody/Anonymous (nobody) Summary: OR grouping JAAS login module Initial Comment: This module will allow to group a bunch of login modules under one flag. If one of these specified sub login modules succeeds this login module will succeed. If all sub login modules fail this login module will fail. One example where something like this might be useful is if you have a bunch of login modules you might want to use for authentication. Yet possibly only one of these login module will succeed. Once one of these login modules is successful you will need to run an Optional or Required flagged login module, e.g. a role login module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=762041group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-762045 ] Cannot get EJB Home interface from Remote interface
Bugs item #762045, was opened at 2003-06-27 12:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=762045group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Dan Ciarniello (dciarnie) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot get EJB Home interface from Remote interface Initial Comment: One cannot get an EJB home interface from a remote interface (using getEJBHome()) when the JNDI connection properties are not set in the System property space. The following code fragment illustrates the problem: == Properties props = new Properties(); props.setProperty(Context.INITIAL_CONTEXT_FACTORY,org.jnp.interfaces.NamingContextFactory); // host must be remote, not local props.setProperty(Context.PROVIDER_URL,remotehost:1099); props.setProperty(Context.URL_PKG_PREFIXES,org.jboss.naming); InitialContext ctx = new InitialContext(props); FooHome foohome = (FooHome)ctx.lookup(ejb/foohome); Foo foo = foo.findByPrimaryKey(id); EJBHome home = foo.getEJBHome(); == The last line will fail with a java.lang.reflect.UndeclaredThrowableException caused by a java.net.SocketTimeoutException. I have traced the problem to org.jboss.proxy.ejb.GenericEJBInterceptor.getEJBHome(Invocation). which has the line InitialContext iniCtx = new InitialContext(); and therein lies the problem. This assumes that the JNDI connection properties have been set in the System property space which is not the case in the above example. The remote interface must have explicit access to the JNDI properties used to retrieve it in the first place. It cannot assume that these properties have been set in the System property space. Note that this problem also exists in v3.2. It does not exist in 2.4.x. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=762045group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-762060 ] Read-Ahead Cache Supports transaction type mismatch
Bugs item #762060, was opened at 2003-06-27 12:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=762060group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Gavin Matthews (bladedancer) Assigned to: Nobody/Anonymous (nobody) Summary: Read-Ahead Cache Supports transaction type mismatch Initial Comment: From: Gavin Matthews [EMAIL PROTECTED] Read-Ahead Cache Supports 2003-06-26 16:08 All, I'm upgrading from 3.2.0 to 3.2.2(RC1) and I hit an incompatibility with the new(?) ReadAheadCache implementation and the finder transaction type. Basically if I have a finder with transaction- type=Supports and use read-ahead-strategy=on-find then I get the following exception if I'm outside of a transaction: 14:43:55,968 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: There is no tranaction associated with the current thread at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.getTrans action(TransactionLo cal.java:206) at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get (TransactionLocal.java:11 8) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCach e.getCache(ReadAheadCa che.java:624) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCach e.add(ReadAheadCache.j ava:570) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinde rResults(ReadAheadCach e.java:114) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryComma nd.execute(JDBCAbstract QueryCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryComma nd.execute(JDBCAbstract QueryCommand.java:91) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand. execute(JDBCFindEntit iesCommand.java:40) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEnti ties(JDBCStoreManage r.java:599) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities (CMPPersistenceManag er.java:324) at org.jboss.resource.connectionmanager.CachedConnection Interceptor.findEntitie s(CachedConnectionInterceptor.java:323) at org.jboss.ejb.EntityContainer.findLocal (EntityContainer.java:604) The fix for me is trivial, I can switch to transaction- type=Required without any issues but I think there is a bug here, the ReadAheadCache should only be used if you're already in a transaction (the read-ahead cache strategy is forcing the transaction-type decision which seems wrong to me). thanks, gavin From: Scott M Stark [EMAIL PROTECTED] Re: Read-Ahead Cache Supports 2003-06-26 17:14 Apparently someone got overzealous in trying to avoid the worst case performance that results when you ask for the read- ahead optimization and do not execute with a transaction to take advantage of the cached data. File a bug report on SF. -- Scott Stark Chief Technology Officer JBoss Group, LLC -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=762060group_id=22866 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
