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

[Design of JBoss internal QA (Test Suite)] - Re: Making parameters more configurable in jboss-test

by akostadinov

Unfortunately ANT_OPTS gets overrided by build.sh So there are 3 ways to go: 1. Change build.sh 2. Make server config task set the java property based on the existence of the ant property "jbossas.startup.timeout" 3. Use ant command instead build.sh Probably #2 is more straightforward followed by #1. I can help with waht you consider better. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132837#4132837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132837

16 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portlet Container 1.2 changes

by julien＠jboss.com

I have introduced ContentResponse as super class of FragmentResponse. All the FragmentResponse fields and accessors have been moved to that class except the nextModes and the title. The ContentResponse is a response of a portlet render or a portlet resource serving. In the case of a portlet render, it will return the FragmentResponse as usual. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132820#4132820 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132820

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Profile Service creating temporary files periodically

by dimitris＠jboss.org

I've enabled jboss.vfs.forceNoCopy=true by default (if not specified) in AS trunk, so that should solve the tmp file problem now. The CTS config seems happy with the change, too. http://jira.jboss.com/jira/browse/JBAS-4389 Going forward (for GA), we may consider making the vfs NoCopy behaviour the default, and use a different flag to explicitly enable it. http://jira.jboss.com/jira/browse/JBAS-5262 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132813#4132813 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132813

16 years, 10 months

1
0
0 / 0

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

by camunda

I agree... For the transactions: You can realize that with a base class also... But maybe it is more easy to use for the people if included in the jbpm infrastructure, agreed! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132797#4132797 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132797

16 years, 10 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

on balance, i think i want them in there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132793#4132793 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132793

16 years, 10 months

1
0
0 / 0

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

by tom.baeyens＠jboss.com

"camunda" wrote : In reality I don't like the use of exception handlers in the process too much. | | On the other hand is fault handling quite important in BPEL, so I think something comparable should be go into jPDL 4 too. So I think exception handlers are important for the language, because they are expected by the users... | | Even if I agree with you that it could be solved better by abstract base classes or the like. | | Cheers | BErnd i didn't really express the value that i see in exception handlers yet. there are now 2 reasons why i think they can be valuable: 1) configurability. if you do it in a base class, there is only one, hard-coded way of handling the exception. While if you use exception handlers, you can in the process decide whether you want to send an email to an admin or start another process in case of failure. 2) transactions. we can offer the infrastructure to execute the exception handler inside the failing transaction or as a synchronization creating a separate transaction right after the failing transaction rolled back. though both these arguments are maybe not enough to add them... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132792#4132792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132792

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Source code tidyup MC project - MetaType generics

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : I have not found them too useful in the management work, and there are incorrect generic usage in the managed project as well. The array stuff was an attempt to be able to use native java values in managed properties, but it was confused. Ok, I've bitten the bullet and removed the generics. I changed the iterator stuff to be iterators of Object. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132788#4132788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132788

16 years, 10 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | | There already is a BeanMetaDataBuilder class inside the MC. | OK, that looks a lot nicer :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132781#4132781 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132781

16 years, 10 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: log4j in .sar file in jboss 4.0.4 GA

by dimitris＠jboss.org

Please use the User Forums http://www.jboss.com/index.html?module=bb&op=viewforum&f=61 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132768#4132768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132768

16 years, 10 months

1
0
0 / 0

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

by camunda

Hi! Actually we developed a typed facade to jBPM in a former project as EJB3-SessionBean. The problem is, like Tom described, that you end up with too much methods/operations, so this facade got quite unhandy! After introducing the commands, I committed the code from that SessionBean to the Commands, and I like the code more now. Better structured, overwriting of commands possible, sending commands as JMS message possible... And in our Swing-Client-Framework we can easily use the Commands, and I think the most people build some kind of "infrastructure"-code around jBPM, so the untyped command is not the biggest problem... But what I would vote for is that the CommandExecutor returns the Command object itself as result. Then you could include the return as attribute in the Command. The CommandExecutor can garantee to return the same Command-Class as given to him. So there is one ClassCast which cannot fail. And all the rest is typed... There was a discussion on that in this forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106234 Cheers Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132767#4132767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4132767

16 years, 10 months

1
0
0 / 0

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