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

[Design the new POJO MicroContainer] - Bug in Microcontainer - Errors from DependencyInfo/Item

by adrian＠jboss.org

I've found a bug in the MC where if a DependencyItem.resolve() throws a RuntimeException that error doesn't get handled. It is propogated out to whoever did the install()/change() and further resolution stops. I don't think it leaves anything in an inconsistent state, but it does mean that everytime tries to install()/change() something (regardless of whether it is related to the context in error) they will get that error back. For the case I found, the fix is (which I will commit) | Index: dependency/src/main/org/jboss/dependency/plugins/AbstractController.java | =================================================================== | --- dependency/src/main/org/jboss/dependency/plugins/AbstractController.java (revision 75590) | +++ dependency/src/main/org/jboss/dependency/plugins/AbstractController.java (working copy) | @@ -1017,8 +1017,18 @@ | if (advance(ctx)) | { | DependencyInfo dependencies = ctx.getDependencyInfo(); | - if (dependencies.resolveDependencies(this, state)) | - result.add(ctx); | + try | + { | + if (dependencies.resolveDependencies(this, state)) | + result.add(ctx); | + } | + catch (Throwable error) | + { | + log.error("Error resolving dependencies for " + state.getStateString() + ": " + ctx.toShortString(), error); | + uninstallContext(ctx, ControllerState.NOT_INSTALLED, trace); | + errorContexts.put(ctx.getName(), ctx); | + ctx.setError(error); | + } | } | } | } | Which treats the error from the DependencyInfo as a normal installation failure and moves that context to the error state. It then continues with other contexts. But this needs validating for all "callouts" to DependencyInfo and tests written for a "poison" DependencyInfo/Item implementation to make sure it doesn't cause the repeated error problem I described above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163502#4163502 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163502

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by apwalker

"timfox" wrote : | The other problem with auto formatting is everyone seems to have a different idea what "proper" formatting is. This only gets worse to standardise when everyone is using different IDEs. | We use checkstyle to enforce our coding standard and fail the build it doesn't conform. Also our CI system will automatically revert any change that causes a build failure. --Aaron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163496#4163496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163496

17 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Problem in XML to CSV transformation

by Neha29

I am exploring jboss-soa-p.4.2.0. I am facing a problem with XML to CSV transformation. Smooks does not give any direct way of XML to CSV transformation.So I have tried this transformation using XSLT but it is not working as desired. The trouble is it is not working when I am running this with jboss-soa-p.4.2.0 which uses Smooks 0.9. This works correctly with Smooks 1.0 used in later versions of Jboss ESB . In the result with Smooks 0.9, i am getting the desired csv within the root element "AssignedTaskDetails". My input xml is : | <xml version="1.0"?> | <AssignedTaskDetails> | <task> | <TaskId>641f71c1</TaskId> | <TaskDescription>Javatesting</TaskDescription> | <TaskCompletionTime> EOD</TaskCompletionTime> | <TaskresponseDetails>ok</TaskresponseDetails> | <isCancelled>false</isCancelled> | <isCompleted>false</isCompleted> | </task> | <task> | <TaskId>845dfdf0</TaskId> | <TaskDescription>Javacoding</TaskDescription> | <TaskCompletionTime>Urgent</TaskCompletionTime> | <TaskresponseDetails> will do</TaskresponseDetails> | <isCancelled>false</isCancelled> | <isCompleted>false</isCompleted> | </task> | </AssignedTaskDetails> | The result I obtain is: <AssignedTaskDetails> | 641f71c1,Javatesting,EoD,ok,false,false | | 845dfdf0,Javacoding,Urgent,yps,false,false | | </AssignedTaskDetails> The smooks config is: | <?xml version='1.0' encoding='UTF-8'?> | <smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.0.xsd"> | <resource-config selector="task"> | <resource>BasicXslTransform.xsl</resource> | </resource-config> | </smooks-resource-list> My BasicXslTransform is: | <?xml version="1.0" encoding="UTF-8"?> | <xsl:stylesheet version="1.0" | xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> | <xsl:output method="text"/> | <xsl:template match="AssignedTaskDetails"> | <xsl:apply-templates select="task"/> | </xsl:template> | <xsl:template match="task"> | <xsl:for-each select="*"> | <xsl:value-of select="."/> | <xsl:if test="position() != last()"> | <xsl:value-of select="','"/> | </xsl:if> | </xsl:for-each> | <xsl:text> </xsl:text> | </xsl:template> | </xsl:stylesheet> In smooks-config if I give resource-config selector as "AssignedTaskDetails" then the result is same as the input xml. How should i go about this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163490#4163490 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163490

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMDR-1; LRU cache impl

by alesj

"adrian(a)jboss.org" wrote : | What makes you think caching will improve this, I think you'll find it makes it worse | You are right. :-) I tried this on AS5_trunk, and like you said, it even got a bit slower. But it still doesn't hurt to have this impl present. ;-) Someone might actually have a real use-case for it, hitting a lot of the same data. Hence using that out-of-the-box. Or even our new mdr-cache project. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163487#4163487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163487

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMDR-1; LRU cache impl

by adrian＠jboss.org

Marko did some investigation, due to the latest AS5 performance complaints on the jboss-dev ml. Due to his results - AbstractMetaDataContext::getComponentMetaDataRetrieval is the biggest hotspot -, I've decided to add caching impls that are part of MDR already, and will work in bootstrap as well. Marko's results on artificial app (100 EJBs, 100 @Local, 100 jsp): | 21% | org.jboss.metadata.plugins.context.AbstractMetaDataContext.getComponentMetaDataRetrieval(Signature) (The method calls itself recursively) | org.jboss.metadata.spi.retrieval.MetaDataRetrievalToMetaDataBridge.getComponentMetaData(Signature) | org.jboss.aop.Advisor.hasJoinPointAnnotation(Class, Signature, String) | org.jboss.aop.Advisor.hasAnnotation(long, Method, String, Class) | org.jboss.aop.Advisor.hasAnnotation(Method, String) | org.jboss.aop.pointcut.MethodMatcher.classMatchesAll(ClassExpression) | | org.jboss.aop.pointcut.MethodMatcher.matchesIdentifier(ASTMethod) | org.jboss.aop.pointcut.MethodMatcher.matches(ASTMethod) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163486#4163486 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163486

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by timfox

"apwalker" wrote : I find it's ok to make formatting changes but just don't do it in a commit that contains code changes. I would do it in a separate commit that only contains formatting changes with a commit message that reflects this. | | just my 2cents | | --Aaron +1. Auto format in the same commit can make it hard to see what the original commit was about, hard to view using a diff, and all our commits should be traceable to the JIRA task which should have the JIRA change and only the JIRA change in it. The other problem with auto formatting is everyone seems to have a different idea what "proper" formatting is. This only gets worse to standardise when everyone is using different IDEs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163480#4163480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163480

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Handling Large Messages

by ataylor

heres a proper link http://wiki.jboss.org/wiki/JBM2HandlingLgeMessages View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163459#4163459 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163459

17 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Cannot run JBoss ESB

by beve

Hi, can you run 'java -version' from the command line? Is there any output to the server.log? Regards, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163458#4163458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163458

17 years, 9 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Porting Deployers to EJB3 Source Tree

by scott.stark＠jboss.org

"ALRubinger" wrote : | Can't Have it Both Ways: | | "scott.stark(a)jboss.org" wrote : ...legacy deployers like ejb2 and the war deployer still have way too many dependencies on other jbossas pieces to pull out. | | | | The Ejb3Deployer does have other integration pieces like JBossASDepdencyPolicy, JBossASKernel, Ejb3JBoss5Deployment, so those would have to be separated out into another layer and injected when configured for jbossas. | | In other words, in the present setup we cannot simply move the deployers out of AS as they're needed by other AS components. We also cannot update them from the EJB3 Plugin in subsequent EJB3 releases. So we're stuck in an undesirable situation. | There is no reason to move all deployers out. Move the ejb3 deployers out into a separate project and ensure that the policy elements that need to be overridden like the dependency, kernel and deployment view have a proper spi that can be implemented by the runtime environment. That is all I and Adrian are saying as far as I can see. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163449#4163449 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163449

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Please don't use IDE auto format on commit

by apwalker

I find it's ok to make formatting changes but just don't do it in a commit that contains code changes. I would do it in a separate commit that only contains formatting changes with a commit message that reflects this. just my 2cents --Aaron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163440#4163440 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163440

17 years, 9 months

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