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

[Design of Kosmos] - Re: serviceResultUpdaterJob not traversing repository

by sstuart4

Ok, I changed the path to /root/kosmos-cache-test and 2 files were created: | hu.midori.kosmos.server.cache.data | hu.midori.kosmos.server.cache.index | Both of these files have zero size also. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961361#3961361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961361

19 years, 5 months

1
0
0 / 0

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

by timfox

"adrian(a)jboss.org" wrote : | Because if everything delcares Throwable, | you can propogate the Throwable throughout your | internal api without wrapping it at every level. | | e.g. for JMS you would wrap the Throwable in a JMSException | in the facade. 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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961360#3961360 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961360

19 years, 5 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Multiple Mail Bodies?

by sappenin

In JBCS 1.0M5 (and I assume before), each Mail message had only a single mail body. So, for example, the MailboxService.getMailBody(MessageData message) function would return a single MailBody object. Post 1.0M5 (i.e., the current HEAD), it appears that each Message object can now store multiple Mail Bodies, as each function that returns a mail body now returns a list of mail bodies. I don't necessarily disagree with the change -- I'm just wondering what prompted it? Is the plan to start storing MIME attachments in separate bodies, or is there some other application/reason? Thanks! David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961355#3961355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961355

19 years, 5 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Tomcat libs path

by alex.jch＠gmail.com

For these folders in Tomcat $CATALINA_HOME/common/lib $CATALINA_HOME/server/lib what are the equivalent in JBoss? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961350#3961350 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961350

19 years, 5 months

1
0
0 / 0

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

by adrian＠jboss.org

"timfox" wrote : That make sense, although I don't see how that applies to the particular methods that have been declared as throws Throwable in messaging core. Because if everything delcares Throwable, you can propogate the Throwable throughout your internal api without wrapping it at every level. e.g. for JMS you would wrap the Throwable in a JMSException in the facade. You probably aren't aware of the problems we had due to the stupid jmx exception wrapping. :-) anonymous wrote : | This is mentioned in Bloch's effective Java "Strive for failure atomicity" | Not everything can be atomic. e.g. in the example above, it could be JMS (outside a transaction) step1 == write the message to a persistent store step2 == do the processing to add to the queue a failure in step2 requires reverseStep1 == remove from the persistent store View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961346#3961346 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961346

19 years, 5 months

1
0
0 / 0

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

by timfox

"adrian(a)jboss.org" wrote : Resource allocation can generally be dealt with try/finally. | The "throws Throwable" is more for when you probably need | to perform some reversing operation in your state Ok, but if you get step1() to automatically reverse itself when a Throwable is thrown, then you don't need to worry about it. Isn't that easier (and safer)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961344#3961344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961344

19 years, 5 months

1
0
0 / 0

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

by timfox

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. E.g. | Connection getConnection() throws Throwable | { | | log.info("before allocation"); | | Connection conn = ...... | | log.info("after allocation"); | | return conn; | } | In the above, both calls to log.info can throw a RuntimeException. If it's thrown from the first log.info line then the connection hasn't been allocated, but if it's thrown from the second one then the connection has been allocated. If you do something like: | Connection getConnection() | { | Connection conn = null; | | try | { | | log.info("before allocation"); | | conn = ...... | | log.info("after allocation"); | } | catch (Throwable t) | { | if (conn != null) conn.close(); | | throw new IllegalStateException(); | } | | return conn; | } | | 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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961343#3961343 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961343

19 years, 5 months

1
0
0 / 0

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

by adrian＠jboss.org

Resource allocation can generally be dealt with try/finally. The "throws Throwable" is more for when you probably need to perform some reversing operation in your state, e.g. | step1(); | try | { | step2(); | } | catch (Throwable t) | { | reverseStep1(); | handle(t); | } | Of course step2() doesn't need to explicitly declare "throws Throwable" but it does help to make you think about! :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961341#3961341 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961341

19 years, 5 months

1
0
0 / 0

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

by timfox

That make sense, although I don't see how that applies to the particular methods that have been declared as throws Throwable in messaging core. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961340#3961340 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961340

19 years, 5 months

1
0
0 / 0

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

by scott.stark＠jboss.org

Its tied to resource cleanup, be it a thread, socket, file descriptor, memory, ...: | Resource r = null; | try | { | r = ...; | } | catch(Throwable t) | { | if( r != null ) | r.close(); | } | A method that declares a Throwable is an indication of a potential resource leak, or state transition inconsistency. More generally the issue is not having a complete state machine model of the subsystem and not explicitly dealing with the subsystem state when an error occurs. In this model unchecked vs checked exceptions related to whether or not the current system state can safely ignore the exception and transition correctly to the next state. If it can the exception can be unchecked. If it cannot the exception is checked and needs to be caught. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961329#3961329 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961329

19 years, 5 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 2006