June 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Getting the whole cause stack of the deployment exceptio

by adrian＠jboss.org

"pete.muir(a)jboss.org" wrote : | But, I can see that this is more generally applicable in the area of tooling (both prod via Jopr, and dev via JBoss Tools) - that if an accurate deployment exception(s) can be reported back to the tool, it can start to suggest possible remedies... Tool interaction should be done via the profile service. But I don't see anything in that api that lets you get the error? http://anonsvn.jboss.org/repos/jbossas/projects/jboss-man/trunk/managed/s... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241028#4241028 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241028

15 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: JAXB annotations for OSGi Blueprint

by alex.loubyansky＠jboss.com

As Adrian said, the annotations should be moved to methods. You can see what is bound and how if you enable TRACE for org.jboss.xb.builder. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241026#4241026 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241026

15 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Getting the whole cause stack of the deployment exceptio

by adrian＠jboss.org

"pete.muir(a)jboss.org" wrote : | "alesj" wrote : Wrt to having entire exception in IDE, I think we would need to change too much code, in order to still properly display any useful info. | | (we're already not the greatest there, but the issue is more complex than it looks like) | | | | For me, IDE isn't a big problem. My use case is that I need to examine deployment exceptions (root cause and sometimes the next level or so up) in an testsuite so I can verify that the correct error happened on deployment. | | try | { | deploySomething(); | } | catch (IncompleteDeploymentException e) | { | Throwable t = e.getDeploymentsInError().get(deploymentURL); | // assert things here | } | Or if you aren't directly deploying something, e.g. the test framework does the deployment. You can run the check later: | try | { | deployerClient.checkComplete(deploymentURL); | } | catch (IncompleteDeploymentException e) | { | // as before. | } | Or finally more direct access (if you want to peek under the covers into unsupported code): | MainDeployerStructure mds = (MainDeployerStructure) mainDeployer; | DeploymentContext dc = mds.getDeploymentContext(deploymentURL); | Throwable t = dc.getProblem(); | // etc. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241020#4241020 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241020

15 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Getting the whole cause stack of the deployment exceptio

by alesj

"pete.muir(a)jboss.org" wrote : | But, I can see that this is more generally applicable in the area of tooling (both prod via Jopr, and dev via JBoss Tools) - that if an accurate deployment exception(s) can be reported back to the tool, it can start to suggest possible remedies... How do you know what's accurate? :-) I can see this being done in a test, but not in general, e.g. tooling. As there can be so many layers in between the real cause and when the exception finally pops out, that chance of having one framework wrapping it in useless wrapper is quite big. And imho wrong/confusing info is worse than no info at all. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241019#4241019 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241019

15 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Getting the whole cause stack of the deployment exceptio

by pete.muir＠jboss.org

"alesj" wrote : "pete.muir(a)jboss.org" wrote : | | This should be checked when we're unwinding the exception to its cause, | | as you never know who all is wrapping the real cause. | | Yes, this is probably enough control for those who need to dig deeper into deployment exceptions, especially if I can get the whole stack here. | | "alesj" wrote : Wrt to having entire exception in IDE, I think we would need to change too much code, in order to still properly display any useful info. | | (we're already not the greatest there, but the issue is more complex than it looks like) | | | | For me, IDE isn't a big problem. My use case is that I need to examine deployment exceptions (root cause and sometimes the next level or so up) in an testsuite so I can verify that the correct error happened on deployment. | | But, I can see that this is more generally applicable in the area of tooling (both prod via Jopr, and dev via JBoss Tools) - that if an accurate deployment exception(s) can be reported back to the tool, it can start to suggest possible remedies... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241000#4241000 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241000

15 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: JAXB annotations for OSGi Blueprint

by adrian＠jboss.org

"thomas.diesler(a)jboss.com" wrote : | Perhaps you like to explain a little better why I would want to use X2JB and why it is more suitable than JBossXB or JAXB. | | https://sourceforge.net/forum/forum.php?thread_id=3318335&forum_id=638125 One major disadvantage (without even looking at the code) is that it is another thirdparty dependency which would mean more bloat. We already have an xml binding framework which is JBossXB and its based on a standard. If it doesn't do what you want then fix/change it, don't write another, that's just NIH syndrome. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240956#4240956 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240956

15 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Supporting entry-point

by beve

Sorry for not replying earlier..some other stuff came up :( anonymous wrote : The answer is that we want both streams of objects in a single working memory so the rules operate against the combined set of facts. Are we talking about sharing a working memory between three services here? OrderEventHandlingService and CustomerEventHandlingService would need to insert their events/facts into the same working memory that the DiscountService later uses. I guess this could be done by passing the RuleBase along with the ESB Message instance in the pipeline but this could get messy given the current architecture. Would a possible solution for this use case be that the OrderEventHandlingService did its required transformations and post the result to a JMS destination. The DiscountService Drools Fusion application then uses that destination as the one of its sources for event. It would do the same for the CustomerEventHandlingService. What is the advantage of putting this business logic in an ESB service. This would mean that replacing the ESB would also affect you business application as opposed to "simply" configuring the new ESB with a transformation and a router to a JMS destination in this case. Regards, /Daniel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240955#4240955 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240955

15 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: JAXB annotations for OSGi Blueprint

by adrian＠jboss.org

"thomas.diesler(a)jboss.com" wrote : @Alex | | I did as you suggested, but still get the same error | | https://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/bluepri... JBossXB was never updated to look at fields so you need to move the @XmlElement(s) to the getter. It should be easy though to make JBossXB look at fields. http://anonsvn.jboss.org/repos/common/jbossxb/trunk/src/main/java/org/jbo... | // Create the handler | -BeanInfo beanInfo = JBossXBBuilder.configuration.getBeanInfo(typeInfo); | + BeanInfo beanInfo = JBossXBBuilder.configuration.getBeanInfo(typeInfo, BeanAccessMode.ALL); | P.S. All metadata should be Serializable P.S.2. You should be setting the property order on the type otherwise the parsing won't match the schema - you get a random order of elements based on what java.lang.reflect returns. P.S.3. We already have the metadata for the bean stuff. Look at the spring-mc-int project which maps the spring xml to mc metadata (or speak to Ales) - no point reinventing it View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240954#4240954 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240954

15 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1823 - handling of res-type in resource-ref

by jaikiran

"Wolfgang Knauf" wrote : | Shall I create any JIRA issues (about the unnecessary warning and about the type check)? | | Sure, please create one. anonymous wrote : | yes, your "I did not get this" guess was correct: I used it to inject a SessionContext, and no matter what was entered for the "res-type", it did not complain, neither on injection nor on JNDI lookup. I can build a sample if you want. Although, the spec mentions this as a deployer's responsibility to correctly configure the res-type, i guess we could issue either a WARN or ERROR if the types don't match. Please create a separate JIRA for this too and attach your application. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240946#4240946 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240946

15 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: JAXB annotations for OSGi Blueprint

by thomas.diesler＠jboss.com

@Alex I did as you suggested, but still get the same error https://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/bluepri... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240943#4240943 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240943

15 years, 6 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 June 2009