March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by ALRubinger

"adrian(a)jboss.org" wrote : No we should use constraints (version ranges). But we need to understand how that interacts with the release process and reproducability of tagged versions. Brian had this to say about current support for ranges: "#maven" wrote : ALR: Brian: Don't know if you're interested, we've been running into some conflicts regarding versioning and transitive dependencies in JBossAS build. | Brian: ugh | ALR: Some use cases are documented: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131748 | Brian: FWIW, i never used ranges in my corp builds | ALR: Brian: Is that a vote for "don't Mavenize"? :) | Brian: no, just don't use ranges S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137838#4137838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137838

18 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionTimeoutConfiguration pluggability

by adrian＠jboss.org

"jhalliday" wrote : I'm tempted to revise the spi spec such that the method throws SystemException if the arg is true and the tx is in anything other than STATUS_ACTIVE. The JIRA mentions STATUS_PREPARING as a valid state, but I'm not so sure. | Its perfectly valid for "one resource adapter" or synchronization to invoke another resource adapter during the before synchronization or prepare e.g. the hibernate rar (if it was used) delegates work to the jdbc rar. anonymous wrote : | Attempting to timeout and rollback a PREPARING tx is a very dodgy proposition. | Its no where near as bad during the commit phase. ;-) anonymous wrote : | IllegalStateException is probably more appropriate than SystemException, but unchecked. There is also the matter of clarifying the expected time units for the return value. SystemException is for serious failure isn't it? IllegalStateException would be preferable if it is not RollBackOnly or RolledBack. The other bad states (e.g. Commiting/ted) indicate a misuse by the application. e.g. forking threads and re-enlisting the tx in the new threads but not synchronizing the commit across that work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137831#4137831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137831

18 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Broken object names in jacc

by anil.saldhana＠jboss.com

The object name will contain the full vfs url within quotes obtained via unit.getName(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137825#4137825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137825

18 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionTimeoutConfiguration pluggability

by jhalliday

I'm tempted to revise the spi spec such that the method throws SystemException if the arg is true and the tx is in anything other than STATUS_ACTIVE. The JIRA mentions STATUS_PREPARING as a valid state, but I'm not so sure. Attempting to timeout and rollback a PREPARING tx is a very dodgy proposition. IllegalStateException is probably more appropriate than SystemException, but unchecked. There is also the matter of clarifying the expected time units for the return value. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137820#4137820 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137820

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Jbpm pageflow

by kukeltje

the pageflow designer in jbpm.3 is the 'current' one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137811#4137811 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137811

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Field access restriction

by adrian＠jboss.org

"alesj" wrote : | both beans get normally installed. | | What am I missing? | They shouldn't be!!!! If your the test deploys the xml manually, it should throw a SecurityException. It doesn't have the authority to access though fields, so it shouldn't gain the authority via deploying xml file. If the xml is deployed during the bootstrap then it runs under the MC's ALL authority and would allow it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137807#4137807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137807

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Amazon S3 cache loader

by manik.surtani＠jboss.com

If the tests written for it can be done using an emulator so it can be run along with JBC-core unit tests, I'm happy to include the cache loader into core. It will then be built/tagged/distributed along with JBC-core. Regarding package names: org.jboss.cache.loader? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137806#4137806 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137806

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty (2nd try)

by pgier

I copied most of the remaining dependencies to the maven repository yesterday. So today I will updated the new shared parent pom with dependencies that match build-thirdparty. One thing that will be different is upgrading javacc from 3.2 to 4.0. This is due to what the javacc-maven-plugin uses. I don't believe this is a problem, because I think javacc is only used at build time and not at run time, and the javacc sources do build correctly. If this could be a problem, please let me know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137802#4137802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137802

18 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionTimeoutConfiguration pluggability

by jhalliday

> Committed/Completed/etc. is also an error That's more than a javadoc change. The only exception I can throw with the current method signature is RollbackException, which is hardly appropriate for those cases. The spi would have to change too. Fix for trunk maybe, I'll have to rev the spi anyhow for the new recovery handling. > ... the jdbc resource adapter to work like it used to. Right, so it's not actually optional if AS 4.2 is going to work as the users expect. Hence the test suite should not consider it optional. Throwing it away should cause a regression, since that breaks existing functionality. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137801#4137801 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137801

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Field access restriction

by alesj

anonymous wrote : | Also I don't see a test in the kernel project that is validating | that you can't use the xml deployment (or programmatic deployment) | to bypass the private field access. | | e.g. See the AccessControlTestCase that validates | that somebody can't use the MC to get access the system properties if they | don't have the right to do so. | Looking at that test, plus trying the 'suck it and see' principle with setting up the FieldAccess test, I fail to get it to fail on access restriction. My bean looks like this: | public class AccessBean | { | @SuppressWarnings("unused") | private String priString; | protected String protString; | public String pubString; | } | and the test class extends AbstractDeploymentTest which enables security. | public static AbstractTestDelegate getDelegate(Class<?> clazz) throws Exception | { | AbstractTestDelegate delegate = MicrocontainerTest.getDelegate(clazz); | delegate.enableSecurity = true; | return delegate; | } | While trying this: | <bean name="private" class="org.jboss.test.kernel.deployment.support.AccessBean" access-mode="ALL"> | <property name="priString">foobar</property> | </bean> | | <bean name="protected" class="org.jboss.test.kernel.deployment.support.AccessBean" access-mode="ALL"> | <property name="protString">foobar</property> | </bean> | both beans get normally installed. What am I missing? Since 'enableSecurity=true' does the trick on PropertyField2DependencyTestCase (where I had to disable it in order to test what I wanted to test). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137800#4137800 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137800

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008