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

[Design of Persistence on JBoss] - JBOSSDO documentation and examples.

by ramkir

We would like to try JbossDO. We are using JBoss4.x and Java1.5. Please point me to the JBossDO documentation and examples. Thank you so much. Regards, ramki View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961399#3961399 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961399

17 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: next steps for the console webapp

by kukeltje

Most of the work will be in creating the JSF ui components, adding monitoring then and administration functionalities (including some ui components, defining HQL etc) is for me the next step. The webapp itself is not to difficult. If seam works with jdk1.4 and runs on Tomcat, JBoss AS, WLS and Websphere, then it would be fine by me, altough I will not have the time to learn seam in the near future. But since seam requires jdk 5.0 I would personally not do it (yet) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961396#3961396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961396

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Internal exception propagation strategy

by scott.stark＠jboss.org

The flip side argument for frameworks using checked exceptions has to do with static code auditability. If I'm writing a framework in an environment that requires every security issue to be logged, frameworks that detect security issues could throw a checked SecurityException and all caller code "analyzed" for proper handling of the exception. I think this would be better handled by being able to register a SecurityException handler at the jvm root thread group such that every call stack inherits the handler, but that is not the current exception model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961387#3961387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961387

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Internal exception propagation strategy

by scott.stark＠jboss.org

I don't agree with a black/white assesment of checked/unchecked exceptions. The problem is that this distinction cannot be made by the exception emitter. Its a function of the caller state machine. If the state has no transitions for any exception, every exception is unchecked. If the state has fine grained events based on the exception type, every exception is checked. You should start a java7 campaign to make all exceptions unchecked by default with annotations that map to on exception handlers along with a Thread active exception state map that indicates which exception types are of interest to the caller at any given point in time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961382#3961382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961382

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Internal exception propagation strategy

by scott.stark＠jboss.org

Wrapping exceptions does throw away information that the caller may want, so I'm in favor of framework code just emitting Exceptions. The nightmare that is jmx is the best example of way too specific of throws clauses and exception wrapping rules. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961381#3961381 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961381

17 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Setting content type for the whole portal : ContentTypeI

by scollins311

free1000 I've been messing around with this for the past couple days and this is what I've found so far... I edited the ContentTypeInterceptor to return MediaType.XHTML for certain URLs. Not the most elegant solution but it's just to test. Then I went and edited the portal-core.war/WEB-INF/layout/portal-renderSet.xml to look like this <?xml version="1.0" encoding="UTF-8"?> | <portal-renderSet> | <renderSet name="divRenderer"> | <set content-type="text/html"> | <region-renderer>org.jboss.portal.theme.impl.render.DivRegionRenderer</region-renderer> | <window-renderer>org.jboss.portal.theme.impl.render.DivWindowRenderer</window-renderer> | <portlet-renderer>org.jboss.portal.theme.impl.render.DivPortletRenderer</portlet-renderer> | <decoration-renderer>org.jboss.portal.theme.impl.render.DivDecorationRenderer</decoration-renderer> | </set> | <set content-type="application/xhtml+xml"> | <region-renderer>org.jboss.portal.theme.impl.render.DivRegionRenderer</region-renderer> | <window-renderer>org.jboss.portal.theme.impl.render.DivWindowRenderer</window-renderer> | <portlet-renderer>org.jboss.portal.theme.impl.render.DivPortletRenderer</portlet-renderer> | <decoration-renderer>org.jboss.portal.theme.impl.render.DivDecorationRenderer</decoration-renderer> | </set> | </renderSet> | <renderSet name="emptyRenderer"> | <set content-type="text/html"> | <region-renderer>org.jboss.portal.theme.impl.render.EmptyRegionRenderer</region-renderer> | <window-renderer>org.jboss.portal.theme.impl.render.EmptyWindowRenderer</window-renderer> | <portlet-renderer>org.jboss.portal.theme.impl.render.EmptyPortletRenderer</portlet-renderer> | <decoration-renderer>org.jboss.portal.theme.impl.render.EmptyDecorationRenderer</decoration-renderer> | </set> | <set content-type="application/xhtml+xml"> | <region-renderer>org.jboss.portal.theme.impl.render.EmptyRegionRenderer</region-renderer> | <window-renderer>org.jboss.portal.theme.impl.render.EmptyWindowRenderer</window-renderer> | <portlet-renderer>org.jboss.portal.theme.impl.render.EmptyPortletRenderer</portlet-renderer> | <decoration-renderer>org.jboss.portal.theme.impl.render.EmptyDecorationRenderer</decoration-renderer> | </set> | </renderSet> | </portal-renderSet> and the portal-core.war/WEB-INF/layout/portal-strategies.xml to look like this: <?xml version="1.0" encoding="UTF-8"?> | <portal-strategies> | <set name="maximizedRegion"> | <strategy content-type="text/html"> | <implementation>org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl</implementation> | </strategy> | <strategy content-type="application/xhtml+xml"> | <implementation>org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl</implementation> | </strategy> | </set> | </portal-strategies> Now things are starting to look promising. I'm getting a faces error because the action on the form isn't well-formated xml. I'm looking into that. And Internet Explorer seems to think the page is a downloadable file. So, there is that too. Thanks for finding that interceptor for me. I'd still be lost if you hadn't. Shaun View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961374#3961374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961374

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Justification for

by scott.stark＠jboss.org

"timfox" wrote : The philosophy I'm following is that JMSExceptions are for recoverable conditions, e.g. trying to send to a destination that doesn't exist, the database isn't up etc. | | I'm treating RuntimeExceptions as programing errors - symptoms of some bug in the code - in which case we just want to throw it as is to the client. | | This gets back to another question on whether implementation details should leak to clients. Given that there is no agreement on checked/unchecked exception usage, there is nothing semantically meaningful about a RuntimeException in terms of whether or not its a recoverable condition. It's just as likely to be a normal failure mode as an Exception depending on the frameworks in use on the server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961373#3961373 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961373

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Justification for

by adrian＠jboss.org

"timfox" wrote : | Why do RuntimeExceptions/Errors need to be wrapped in a JMSException and sent to the client? | | Can't we just propagate the RuntimeExceptions/Error as is to the client? Errors yes/maybe - they are normally non-recoverable, but that doesn't mean you shouldn't try, otherwise the whole system could go into an indeterminate state. There are many errors that might only be related to a specific request, e.g. NoClassDefFoundError when unmarshalling an object message. However, if the user passes bad parameters then the appropriate exception should be thrown. Any RuntimeException after you accepted the request is your problem, it should be reported to the user as a JMSException, even though it is likely fatal. How do you pass that Error/RuntimeException to onException()? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961372#3961372 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961372

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Justification for

by scott.stark＠jboss.org

"timfox" wrote : Wouldn't it be better if the method is written to always guarantee to leave the object in a well defined state? | | If the object is not left in a well defined state then even if you catch Throwable, then there's not much you can do since you don't know if the underlying resource (or whatever) was actually allocated. | | ... | | Then your're not leaving anything to chance and you can avoid throws Throwable. | | This is mentioned in Bloch's effective Java "Strive for failure atomicity" | | What am I missing? | You have made an assumption that all Throwables map to an IllegalStateException and that the actual type of the exception event is not relevant to the caller's state machine with respect to how it relates to obtaining a connection. I would miss the opportunity to have different transitions for different types of exception events: | | { | Connection conn = null; | | try | { | | log.info("before allocation"); | | conn = ...... | | log.info("after allocation"); | } | catch(NoRouteToHostException e) | { | ... | } | catch(OutOfMemoryError e) | { | ... | } | catch (Throwable t) | { | if (conn != null) conn.close(); | // Why should I throw away the type and prevent my caller from doing fine-grained event handling? | throw new IllegalStateException(); | } | | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961365#3961365 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961365

17 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Justification for

by timfox

The philosophy I'm following is that JMSExceptions are for recoverable conditions, e.g. trying to send to a destination that doesn't exist, the database isn't up etc. I'm treating RuntimeExceptions as programing errors - symptoms of some bug in the code - in which case we just want to throw it as is to the client. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961363#3961363 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961363

17 years, 9 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 July 2006