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

[Design of JBoss Web Services] - Run tests-compile without wsconsume

by thomas.diesler＠jboss.com

Folks, did you know that you can run | [tdiesler@tddell trunk]$ ant -Dnoconsume=true tests-compile | Buildfile: build.xml | ... | wsconsume: | | tests-compile: | [javac] Compiling 2 source files to /home/tdiesler/svn/jbossws/stack/native/trunk/output/tests/classes | | BUILD SUCCESSFUL | Total time: 5 seconds | This reduces test compile time dramatically. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133144#4133144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133144

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedProject and Dependencies - AOP

by adrian＠jboss.org

Also, the managed (as well as the metatype) annotations and their related integration interfaces should really be moved into the jboss-integration project. That way people can reference those annotations for compilation purposes without necessarily including them in their project release (the annotations will be ignored if they are not in the classpath). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133143#4133143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133143

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - ManagedProject and Dependencies - AOP

by adrian＠jboss.org

The wrapper advice in the managed project is causing lots of projects that use its annotations to gain transitive dependencies on AOP via maven. 1) I think this interception of the managed object interfaces is really something that belongs in the profile service, e.g. for trapping changes for the purposes of versioning, persisting, etc. 2) We should move these classes into the "test" part of the managed project if we really need to write mock tests for this behaviour in that project? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133141#4133141 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133141

16 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: New Reflection Project

by adrian＠jboss.org

One issue with the reflection stuff is that there is some code in there to parse | <javabean xmlns="urn:jboss:javabean:1.0" .../> | xml elements. With Maven, this means every user of BeanInfo (including JBossXB itself :-) gets a depdendency on JBossXB and transitively its dependencies. What I propose to do is to leave the "container" project in the MC but rename it to "javabean", to include this xml parsing code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133134#4133134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133134

16 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Bold Transitions in Workflow-Designer

by kukeltje

The answer I'd give you is 'by changing the source of the GPD'. This is probably not what you wanted to here but that's just the way it is. It cannot be done in some css way or something, sorry. btw, you mean the label or the whole line? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133131#4133131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133131

16 years, 7 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Support for UNIX?

by mark.little＠jboss.com

We already answered this didn't we? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133125#4133125 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133125

16 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Changing dependencies in poms

by adrian＠jboss.org

When you update build/pom.xml to change a version of a related project can you please: 1) Create a JIRA issue for it and link to the release notes for that release. 2) Update the relevant .classpath files (1) Is a new requirement for all JBoss Projects. There is a JIRA issue type of "Release" and I've created a new component type called "Release" for the MC project. Here's an example http://jira.jboss.com/jira/browse/JBMICROCONT-245 NOTE: This is also a requirement for thirdparty jars. I'd recommend you copy the release notes into the task for thirdparty jars since there's no guarantee any thirdparty link will remain valid over the long term. (2) is optional, but it would be friendly, otherwise we end up with different subprojects referencing different versions (e.g. because only one uses a new feature) and Eclipse gets confused when running tests or showing source. SNAPSHOTS: This does not apply to snapshot releases. We do NOT reference snapshots from our official releases. They will get a JIRA issue when we include the non-snapshot release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133108#4133108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133108

16 years, 7 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Facade Questions

by adrian＠jboss.org

For this case, we should just make DeployersImpl an emitter of some DeploymentStage event. That way it can include information related to the deployment which a generic event can't do (the listener would have to filter for relevant events and then do lookups to get information). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133096#4133096 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133096

16 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Bold Transitions in Workflow-Designer

by magro1202

Hi everyone does anybody know how i can implement that any default leaving transition is automatically displayed in bold? By the way the default leaving transition of a State is the first transition that is declared in the processdefinition. thanks for any advises regards Matthias View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133084#4133084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133084

16 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Restricting scanning for ejbs

by scott.stark＠jboss.org

One problem I ran into in a cts test is the Ejb3Deployment scanning for annotated ejbs. There are tests where wars are including annotated ejbs. When such a war is bundled with the ejb jar that should be the deployment unit for the Seems like we need a mode that disables the scanning ejbs in non-ejb units. The war is not actually treated as ejb unit because the deployBeansFromLib() method only processes units with JBossMetaData. However, the war is registered as an ejb container with the Ejb3Registry, and when ejbs are resolved based on its interface by the DeploymentEjbResolver, there are duplicate ejbs seen. I'm not sure why we are scanning for classes if there is no JBossMetaData. Perhaps its a hangover from before having an annotation deployer. I'm going to bypass the scanning if there is no JBossMetaData. Probably need to revisit this for using ejb3 in modes outside of the server if its not going to rely on the mc deployer architecture. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133070#4133070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133070

16 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2008