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

[Design of JBoss jBPM] - Re: how crucial are exception handlers ?

by heiko.braun＠jboss.com

I don't know much about the extension point you are describing, but does it help to distinguish user code from PVM by using checked vs. unchecked exceptions? That basically means no exception handlers required if the extension point doesn't allow checked exceptions. So the PVM would just guard runtime exceptions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132228#4132228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132228

18 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty

by pgier

"scott.stark(a)jboss.org" wrote : "pgier" wrote : Unfortunately the mapping part will be separate from the dependencies, because the mapping will have to be a parameter to the plugin. I can't change the XML for the dependencies in the pom without hacking up and forking the maven code. I'll post an example tomorrow of what it looks like once I get a couple more of the details figured out. | | | Right, I was just reproducing the dependency info in the plugin config to allow the mapping to be clear. | Oh yeah, sorry, I didn't read your earlier post very carefully. It will look very similar to what you put above. "scott.stark(a)jboss.org" wrote : | "pgier" wrote : | | I'm going to make this a new mojo (maven plugin class) in the current jboss-deploy plugin because they can share some code for writing component-info files and other stuff. I'm thinking about renaming the plugin to something like jboss-thirdparty plugin, but that's low priority. | | | Remember we really don't need the component-info.xml in the local thirdparty contents as we would not be using the jbossbuild repository mechanism any longer. | It's not a big deal since I already had some small code for it from the jboss-deploy plugin. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132220#4132220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132220

18 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: What do the dependency:analyze warnings mean?

by pgier

"scott.stark(a)jboss.org" wrote : | All of these unused dependencies are in fact used, so what is this telling me? | The reason these ones are showing up is because of the renamed stuff. When the groupId changes from one version to another, then maven doesn't know that they are the same thing anymore. So the code might be compiling against a version picked up transitively. The way around this is to exclude the transitive dependency. Unfortunately there is currently no way to globally exclude a certain transitive dep. So you have to exclude it from each direct dependency where it is picked up. The junit dependency could probably be changed to a test scope instead of compile scope since it's not used by the main classes. I think that's why it's complaining about that one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132209#4132209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132209

18 years, 1 month

1
0
0 / 0

[Design of JBoss Serialization] - Re: JBOSS Serialization & other JBOSS projects

by clebert.suconic＠jboss.com

No.. just regular Object*Stream over RMI. (I believe it is part of the JNDI spec) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132206#4132206 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132206

18 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Command facade API

by tom.baeyens＠jboss.com

the command pattern is only an intermediate step towards a normal session facade interface. the idea is that process languages like jPDL still could offer a session facade with normal methods, typed return values and typed parameters. these could then be implemented in terms of the command. such a session facade would look like this public class JpdlService extends CommandService { | Execution startProcess(String processName); | Execution signal(long executionId); | ... | } impl would be something like this public class JpdlServiceImpl extends CommandServiceImpl implements JpdlService { | public Execution startProcess(String processName) { | return (Execution) execute(new StartProcessCommand(processName)); | } | ... | } There are 2 motivations for this approach 1) graph retrieval. A typical session facade doesn't have a way to specify how much of the returned object graph needs to be eagerly initialized. When navigating through the object graph outside of the session facade (hence outside the hibernate session scope) you can get lazy initialization exceptions. By using the command pattern, users can easily extend a command, appending the eager fetching to the command. 2) open ended session facade A bunch of commands are reusable. But if you're writing a UI as a front end for the whole engine, you want to do fetch very specific things from the facade. In that case, it might be easier to have local command classes to the UI, instead of bloating a customized session with hundreds of methods for each individual use case. That is the summary of the argumentation why i came to it. I certainly acknowledge that it has it's limitations. But I didn't yet see a better alternative. (that incl a quick but incomplete scan of the post you referenced) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132203#4132203 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132203

18 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: What do the dependency:analyze warnings mean?

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | All of these unused dependencies are in fact used, so what is this telling me? | Probably that is using a transitive dependency from one of the other dependencies instead of the what you declared. The MC build has lots of this kind of thing which solves the problem, but it isn't the real solution for me: | |  | | <dependency> | <groupId>org.jboss</groupId> | <artifactId>jbossxb</artifactId> | |  | | <exclusions> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-core</artifactId> | </exclusion> | <exclusion> | <groupId>jboss</groupId> | <artifactId>jboss-common-logging-spi</artifactId> | </exclusion> | </exclusions> | </dependency> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132202#4132202 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132202

18 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Facade Questions

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : "johnbailey" wrote : | | Any idea on when the MainDeployer will have the correct interface to move the deployment to a different state? | | I'm doing it now. I've already added a getMainDeployer() to the deployment unit. | I'm just adding a MainDeployer.change(deploymentName, DeploymentStage); | Ok this is done. I also had to move the DeploymentStage(s) class to the client api and make it Serializable. So you should now be able to do something like: | DeployerClient main = unit.getMainDeployer(); | main.change(unit.getName(), DeploymentStages.CLASSLOADER); | If you find any problems, then update the test case in the deployers-impl package, to show the issue. org.jboss.test.deployers.main.test.DeployerChangeStageTestCase View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132201#4132201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132201

18 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - What do the dependency:analyze warnings mean?

by scott.stark＠jboss.org

Running mvn dependency:analyze on https://svn.jboss.org/repos/jbossas/projects/naming/trunk/jnpserver produces: | [INFO] [dependency:analyze] | [WARNING] Unused declared dependencies found: | [WARNING] jboss:jboss-logging-spi:jar:2.0.2.GA:compile | [WARNING] apache-log4j:log4j:jar:1.2.14:compile | [WARNING] jboss:jboss-common-core:jar:2.0.2.GA:compile | [WARNING] jboss:jboss-logging-log4j:jar:2.0.2.GA:runtime | [WARNING] junit:junit:jar:3.8.1:compile | All of these unused dependencies are in fact used, so what is this telling me? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132197#4132197 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132197

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: COM Gateway

by tfennelly

hehehehe ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132196#4132196 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132196

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: COM Gateway

by mark.little＠jboss.com

No truth in that rumour ;-) Though I am waiting for you ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132192#4132192 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132192

18 years, 1 month

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