July 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: New Locking Strategy Proposal for JBoss Cache

by gavin.king＠jboss.com

"jason.greene(a)jboss.com" wrote : Hello everyone, | | I would like your feedback | | Thoughts? I think the colored lights on your laptop are great! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067204#4067204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067204

17 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: New Locking Strategy Proposal for JBoss Cache

by manik.surtani＠jboss.com

Ok, after much discussion over the last 2 days with Jason et al in Austin, we've hashed out more details on this. I've documented this on this wiki page, and would like feedback/thoughts on this. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheMVCC View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067188#4067188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067188

17 years, 6 months

1
0
0 / 0

[Design of JBoss Profiler] - web.for, .FilterForm - ClassNotFoundException

by hykwok

HI, it has been more than a year since the last time I used JBoss Profiler. Recently, I use it again for a new assignment, but keep getting this error when clicking the "Runtime Profiler" link under my http://localhost:8080/jboss-profiler/index.jsp. Any idea? Thanks. HTTP ERROR: 500 Exception creating bean of class org.jboss.profiler.web.form.FilterForm: java.lang.ClassNotFoundException: org.jboss.profiler.web.form.FilterForm RequestURI=/jboss-profiler/indexRuntime.jsp View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067153#4067153 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067153

17 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

by adrian＠jboss.org

I doubt that method fails to commit either (and if it crosses an EJB/transaction boundary it is even more broken :-). But this is beside the point. The rules are simple. If you want it, you do it! As long as it is disabled by default. I could have done it in the time it took for this argument if I thought it was a good thing (my guess is that it doesn't even solve the problem!) BUT ONLY DO IT IF YOU ARE WILLING TO SUPPORT IT AND ANSWER ALL THE STUPID QUESTIONS. I'm fed up of people adding unsupportable/broken features and leaving others to answer the faqs with the same old message; "Don't use it is broken and its an anti-pattern/anti-spec." The classic example is remote datasource usage - http://jira.jboss.com/jira/browse/JBAS-1794 which is an issue that goes back long before I opened that JIRA issue 2 years ago. If I thought it was a good feature, I'd have fixed it. I don't, so I won't. :-) Well actually, I probably will eventually (since nobody else is stepping up to the plate) but its nowhere near the top of my priorities. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067141#4067141 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067141

17 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Security Configuration for JBoss 5

by anil.saldhana＠jboss.com

If I adopt JAXB2 for security configuration, I have 5.0 version, 4.1 version and the default schema-less version to deal with. JBossXB had some schema validation issues. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067138#4067138 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067138

17 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

by bill.burke＠jboss.com

What if the connection is being passed as a parameter and committed/rolledback/closed outside of this method? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067128#4067128 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067128

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3 API Approach Proposal

by david.lloyd＠jboss.com

The wiki article has been updated with more information about JCA integration, and changes to the API based on that and other bits of information. It's a fairly substantial change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067122#4067122 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067122

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4543 Design

by JerryGauth

Just to document what I found - The original discussion of JBMICROCONT-192 suggested that a "name-method" attribute would be used to expose the bean name. It appears that this was either not implemented or was rolled back. The bean name is available using "inject fromContext". For example, adding the following to the HASingletonDeployer bean will cause the bean name to be injected into serviceHAName. <property name="serviceHAName"><inject fromContext="name"/></property> | It looks like the version of jboss-kernel.jar containing this support hasn't been updated in the repository yet. I built the jar from latest microcontainer source and confirmed that this technique works for HAServiceMBeanSupport. Once the jar is available, I'll modify deploy-hasingleton-beans.xml to use this capability. If annotation support subsequently becomes available, I'll revisit the issue as it might be preferable to handle this in the base class rather than in the configuration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067111#4067111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067111

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4574 and JBAS-1476

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : "bstansberry(a)jboss.com" wrote : | | | [OT] Re: 'the "view change" is less than it previously was" after a cluster restart. No. The viewId passed between the server and HA clients is not a counter. It is a hash of the service's cluster topology. | | | | Nice fix. You just broke all the old clients that assume its a counter. | | What fix? I never changed anything; this is the way viewId has worked in any clustering code I've looked at. I have no idea where this counter concept you have comes from; maybe some early version. It's not the way it works at least since 4.0.3 (and I didn't touch it there). You calling me an old timer? :-) My guess is Sacha changed it when refactored the whole thing to do his cluster family stuff? Either that or I'm just going senile. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067106#4067106 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067106

17 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : I don't think you are listening to me. connection.commit() /rollback()SHOULD fail as it is a state change. setAutoCommit(false) should succeed as there is no state change to the connection if auto commit is already false. | | Thirdparty code may not be doing commit(), rollback(), but may only be doing setAutoCommit(false). Which should be perfectly fine, again, because there is no state change to the connection. This could be what the user is running into. I don't know. | Impossible. The code would never work without a commit() outside a JTA transaction. connection.close() does a rollback if there was no commit. anonymous wrote : | Weston/myself had similar spec religiousness debates with Mark Little around allowing multiple non-XA resources in a transaction. | | Morale of the story? You may know something is wrong and not the right way to do it, but there may be no other way because you don't control all the variables. | But using non-XA resources works in most cases (there are some failures that don't). What's important is that it doesn't break code using XA resources to support it. There's absolutely no way | Connection c = datasource.getConnection(); | try | { | c.setAutoCommit(false) | // do stuff but don't commit | } | finally | { | c.close(); | } | works in any environment. It's just broken code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067098#4067098 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067098

17 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2007