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

[Design of OSGi Integration] - Re: mailing list test

by thomas.diesler＠jboss.com

another test View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220907#4220907 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220907

17 years

1
0
0 / 0

[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults

by ips

On the the XML config file end, only a handful of the config elements are required. For example, if I have a ds.xml file containing only: <connection-factories> | <tx-connection-factory> | <jndi-name>MyTx</jndi-name> | <rar-name>jms-ra.rar</rar-name> | <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition> | </tx-connection-factory> | </connection-factories> Somehow or another, the other properties will end up with default values on the underlying connection factory. This must be happening in one of two ways: 1) For any missing elements in the XML file, the deployer knows what defaults to use and passes those defaults to the underlying connection factory. 2) For any missing elements in the XML file, the deployer passes null to the underlying connection factory or does not call the corresponding setters at all, and the connection factory knows to use its own internal defaults. Based on your comment that the profile service would have to store defaults for primitives, I'm guessing that 1) is what was done on the deployer end, because if 2) is what was done, the profile service could do the exact same thing and just rely on the underlying connection factory to provide defaults. So assuming for now that 1) is what was done on the deployer end, I suggest the following: 1) Add some sort of defaultValue attribute on the ManagedProperty annotation, e.g.: @ManagementProperty(name="idle-timeout-minutes", includeInTemplate=true, defaultValue="30") public void setIdleTimeoutMinutes(int idleTimeout) { this.idleTimeout = idleTimeout; } This attribute would be optional and would only be allowed for properties that map to SimpleValues or EnumValues. For primitive properties, when a defaultValue is specified, the Profile Service would set mandatory to false on that property, otherwise it would set mandatory to true. For non-primitive properties, unless the annotation explicitly contained mandatory=true, the properties would default to mandatory=false. If the profile service can't provide something like the above, we'll have to make all of these primitive properties required in jboss-as-plugin's metadata (today they're optional), and when a user creates a new Connection Factory via JON or the Admin Console, they will have to specify values for 20 or so properties, rather than the 3 that really need to be required (jndi-name, rar-name, and connection-definition). Of course, RHQ provides a mechanism for specifying templates for new Resources, so we can include defaults for all 17 of these properties in our plugin descriptor. This basically places the responsibility of maintaining the defaults on RHQ, rather than the profile service. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220894#4220894 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220894

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Failure handling

by kukeltje

No sorry (and he did not read your comment yet as it is not visible on his blog) :-( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220891#4220891 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220891

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 Beta1 test suite Check List

by ataylor

I've updated the list. Could everyone check that nothings missing. Ive also repacked quite a few tests to make things a bit easier. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220853#4220853 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220853

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Semantic on Session.stop and MessageHandler

by ataylor

anonymous wrote : A couple of issues with the latest commit: | | 1) The logic in setMessageHandler() doesn't look right: | | When setting a non null message handler, then it remains stopped so any messages won't get delivered. | | Messages are being requeued if the previous handler was null but even if the current handler is null correct, I'll add a test and fix anonymous wrote : 2) receive() method: | | while ((stopped || (m = buffer.poll()) == null) && !closed && toWait > 0) | | It will stay in the loop as long as the consumer is stopped. This is not correct - receive should always return after timeout, it's just that if it's stopped then it should always return null. are you sure? ClientConsumerTest:testStopStartConsumerSyncReceive() tests for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220840#4220840 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220840

17 years

1
0
0 / 0

[Design of Management Features on JBoss] - JBAS-6672, null values and defaults

by scott.stark＠jboss.org

Essentially this JBAS-6672 issue is asking for null managed property values to be interpreted as resetting primitive values back to their default values. This does not seem to have an easy mapping as there is no practical way for the managed property layer to know what the initial value for the primitive field is. We would have to have a default value notion at the ManagedProperty level, and we would have to have a policy of using that value when a null was passed in for a primitive. Is there a reason we have to set a primitive to null? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220783#4220783 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220783

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Failure handling

by bradsdavis

You don't happen to know do you Ronald? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220779#4220779 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220779

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: task attributes

by kukeltje

anonymous wrote : ronald, do you see a violation of what we did in relation to bpmn or ws-human-task ? 'violation' in a generic sense? I cannot find the bpmn 2.0 draft spec anymore to compare things. I only have some 1.x things in mind where using some attributes you propose differ in name and usage. But I do not want to compare with 1.x. So please bear with me a little until I've found the 2.0 spec again. Google is leaving me in the dark. I'll have a quick scan for WS-HT also over the weekend. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220776#4220776 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220776

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Failure handling

by kukeltje

Brad, The chances are little Burk will read this. This forum does not automatically send you responses, not even if you started the topic. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220773#4220773 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220773

17 years

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Connection Factory managed component types and templates

by scott.stark＠jboss.org

Yes, that makes sense. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220770#4220770 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220770

17 years

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 March 2009