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

[Design of JBoss Build System] - Dependency conflicts lost during AS mavenization

by heiko.braun＠jboss.com

I am currently looking at two projects sharing a dependency, with each specifying a different version. During the AS build this conflict is not recognized anymore. I.e. the metadata project refers to jbossws-spi 1.0.0.GA, but the latest AS 5 build ships with jbossws-spi 1.0.2.GA. Event though these versions are compatible, lack of an explicit compatibility statement should cause a dependency error when building the AS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140501#4140501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140501

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NPE with new parsing in aop-mc-int tests

by alesj

"adrian(a)jboss.org" wrote : | What does JBossXB have to do with the following code? | | | KernelDeployment dep = new AbstractKernelDeployment("test"); | | dep.setBeans(Arrays.asList((BeanMetaDataFactory) null)); | | | which produces the same error. Good point. :-) I'll fix/handle this together with this: "adrian(a)jboss.org" wrote : | "adrian(a)jboss.org" wrote : | | | Then in the part where the deployment/bean are checked for classloader | | | AbstractKernelDeployer::deploybean() | | | | While I am on this subject. | | I originally put all the deployment defaults in this method, but other | defaults have been added in the AbstractKernelDeployment::getBeans(). | | I think the AbstractKernelDeployment is the correct place for this code, | so we should look at moving all the logic that is AbstractKernelDeployer::deployBean() | into there. | | Especially since the AbstractKernelDeployer is not always used, | e.g. the BeanMetaDeployer in the deployers project. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140499#4140499 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140499

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: mvn dependency:tree

by pgier

I think the dependency plugin uses the dependency resolution from the maven core components. Unfortunately I don't think this has a way to distinguish between resolving the dependencies just to get the list (just download the poms) and resolve the dependencies for compiling (where you need the jars) and other stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140496#4140496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140496

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NPE with new parsing in aop-mc-int tests

by adrian＠jboss.org

"alesj" wrote : | "adrian(a)jboss.org" wrote : | | But we shouldn't be throwing an NPE there. We should have something more | | informative. | Definitely. :-) | But this should be already handled in JBossXB. | Otherwise we can add all sorts of NPE checks throughout our metadata classes, if we cannot trust JBossXB to deal with them before. | What does JBossXB have to do with the following code? | KernelDeployment dep = new AbstractKernelDeployment("test"); | dep.setBeans(Arrays.asList((BeanMetaDataFactory) null)); | which produces the same error. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140492#4140492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140492

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: webservices ejb3 api usage

by heiko.braun＠jboss.com

The current tracking issue is http://jira.jboss.org/jira/browse/JBWS-2083. I've implemented and released the API with jbossws-spi 1.0.2.GA. It already implemented in EJB3 trunk (EJBTHREE-1247). The only pieces missing pieces are a) http://jira.jboss.org/jira/browse/JBMETA-12 (SPI update in meta data project) b) http://jira.jboss.org/jira/browse/JBWS-2086 (Make the WS container integration use the new API) c) http://jira.jboss.org/jira/browse/EJBTHREE-1248 (Automate the WS integration test runs as part of the EJB3 release QA) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140487#4140487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140487

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Jbpm pageflow

by kukeltje

anonymous wrote : pls advise me regarding jbpm.ide/org.jbpm.ui project. What is this exactly? and are we using this anywhere. It is the old cvs entry. Not used anymore. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140485#4140485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140485

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AOPConstructorJoinpoint::methodHasAnnotations is wrong

by alesj

"alesj" wrote : | Looking at Kabir's comment on recent change: | anonymous wrote : | | [JBMICROCONT-250] When checking component metadata for a method, only return that we have joinpoint annotations if they exist at instance level or below. | | | Looks like a case of wrong impl or wrong conclusion on how MetaData.getScopeMetaData(ScopeLevel) works. | | Should we really always check for all levels below and including INSTANCE? | I've added this hierarchy check: | private boolean checkForMetaDataAtSubInstanceLevel(MetaData metaData) | { | if (metaData != null) | { | List<ScopeLevel> levels = CommonLevelsUtil.getSubLevels(CommonLevels.INSTANCE); | for (ScopeLevel level : levels) | { | boolean hasMetaData = hasMetaDataAtLevel(metaData, level); | if (hasMetaData) | return true; | } | } | return false; | } | And I'm ignoring any annotations that are marked with InstanceAnnotation(false): | protected boolean hasMetaDataAtLevel(MetaData metaData, ScopeLevel level) | { | MetaData levelMetaData = metaData.getScopeMetaData(level); | if (levelMetaData != null && levelMetaData.isEmpty() == false) | { | Set<Object> checkSet = new HashSet<Object>(); | Object[] allMetaData = levelMetaData.getMetaData(); | Annotation[] annotations = levelMetaData.getAnnotations(); | // all meta data is not null, since instance metadata is not empty | checkSet.addAll(Arrays.asList(allMetaData)); | checkSet.removeAll(Arrays.asList(annotations)); | | // do we have something else than annotations | if (checkSet.isEmpty() == false) | return true; | else | { | // do we have an annotation that's not marked with IA | for (Annotation annotation : annotations) | { | InstanceAnnotation ia = annotation.annotationType().getAnnotation(InstanceAnnotation.class); | if (ia == null || ia.value()) | return true; | } | } | } | return false; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140480#4140480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140480

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NPE with new parsing in aop-mc-int tests

by alesj

"adrian(a)jboss.org" wrote : | It's a long standing bug in JBossXB. It basically means it didn't figure out how | to create the object. | Yup. I've traced it down to not understanding aop:lifecycle-configure. Or any aop:lifecycle-(state) for that matter. Kabir, I thought you said the new jbossxb+aop_mc is a superset of previous schema initializers? ;-) "adrian(a)jboss.org" wrote : | But we shouldn't be throwing an NPE there. We should have something more | informative. Definitely. :-) But this should be already handled in JBossXB. Otherwise we can add all sorts of NPE checks throughout our metadata classes, if we cannot trust JBossXB to deal with them before. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140478#4140478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140478

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NPE with new parsing in aop-mc-int tests

by adrian＠jboss.org

"alesj" wrote : | Who matches/produces this null? It's a long standing bug in JBossXB. It basically means it didn't figure out how to create the object. But we shouldn't be throwing an NPE there. We should have something more informative. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140471#4140471 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140471

18 years

1
0
0 / 0

[Design of JBoss Build System] - mvn dependency:tree

by dimitris＠jboss.org

An 'mvn dependency:tree' from AS trunk/thirdparty with a semi-cleaned local maven repo takes almost half for me. Is there a way to see the dependency tree without actually downloading all the .jar files locally? | [INFO] ------------------------------------------------------------------------ | [INFO] BUILD SUCCESSFUL | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: 27 minutes 49 seconds | [INFO] Finished at: Tue Apr 01 15:28:52 EEST 2008 | [INFO] Final Memory: 24M/47M | [INFO] ------------------------------------------------------------------------ | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140458#4140458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140458

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 April 2008