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

Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml

by David Lloyd

David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion "Profiles in domain.xml" To view the discussion, visit: http://community.jboss.org/message/546291#546291 -------------------------------------------------------------- > Brian Stansberry wrote: > > There's a product requirement: > [..] > To me the spirit of that is its not required to have running services to properly configure things. And to me part of properly configuring things is seeing what the current values are, so I can decide whether those values are appropriate. That includes values that are defaulted. If I have to have a running JBossWeb to know that when I start a server it's going to listen for HTTP requests on port 8080, we're doing something wrong. OK I've been thinking in terms of "configuration is a write operation, monitoring is a read operation", but that is, I guess, too limited of a view. Let's continue the discussion of defaults in Alexey's new thread: http://community.jboss.org/message/546290#546290 http://community.jboss.org/message/546290#546290 -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546291#546291] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

[Management Development] - default values in domain management

by Alexey Loubyansky

Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] created the discussion "default values in domain management" To view the discussion, visit: http://community.jboss.org/message/546290#546290 -------------------------------------------------------------- I thought it's worth a separate thread. There are of course very different kinds of properties. I.e. the ones that are set in deployment descriptors and those that can't be, e.g. jvm args, environment variables, etc. Here is what I think about those that are set in deployment descriptors. I maybe off the path, so please correct my view on this. At least in the beginning, domain.xml could be optional from the server instance start-up point of view. I.e. it would be possible to start a stand-alone server instance without domain.xml. Then all the services/containers would be initialized from their deployment descriptors (and possibly other config files) as it's happening now. But if domain.xml is present then the values it contains will override the corresponding values from the deployment descriptors. As Brian said in the other thread this approach implies that to have correct values of a manged component in an admin tool the managed service must be initialized at a minimum. In addition, the values for managed properties are duplicated, i.e. in the deployment descriptors and domain.xml, which is confusing. Admin tool will apply changes to domain.xml but not the deployment descriptor. domain.xml is synchronized between the server instances in the instance but deployment descriptors probably won't. Which means if the value is removed from the domain.xml the default value for the property on every server instance coming from the deployment descriptors maybe different. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546290#546290] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "Profiles in domain.xml" To view the discussion, visit: http://community.jboss.org/message/546289#546289 -------------------------------------------------------------- There's a product requirement: > Instances will still be configurable even if they are not currently running. Changes > will become active when the instance is next started. To me the spirit of that is its not required to have running services to properly configure things. And to me part of properly configuring things is seeing what the current values are, so I can decide whether those values are appropriate. That includes values that are defaulted. If I have to have a running JBossWeb to know that when I start a server it's going to listen for HTTP requests on port 8080, we're doing something wrong. My phrasing about not having a fixed API was poorly worded. What I meant was, if for example a configuration API had a getHttpPort() method but whether it would return a meaningful result depends on whether they have services running, that's not really a configuration API. It's a monitoring API. A monitoring API is a reasonable part of the domain management API, but it's a distinct thing from a configuration API. We were chatting a bit about the problem of multiple versions of AS running in the same domain, which bears on this whole area. I was interrupted and had to bail; let me get my brain back into the train of thought... -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546289#546289] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml

by David Lloyd

David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion "Profiles in domain.xml" To view the discussion, visit: http://community.jboss.org/message/546276#546276 -------------------------------------------------------------- > Brian Stansberry wrote: > > If I understand you correctly that means the management API we expose is limited to what the users actually configure. It's no longer a fixed API. Is that not true? The management API can do two things: 1. Perform operations which update the domain model and possibly the running state of one or more Server, and 2. Read values that reflect the currently running state of one or more configured service (though it's not clear to me how this would work - would the DC relay request and gather the data to present? would each machine have a monitoring interface for this purpose? etc) Am I missing something? All I'm saying is that if nothing is configured for a domain value for a specific running service, then the server determines the default value. If a new value is configured, it becomes part of the domain configuration and the default is no longer used. I suppose it also implies that if a value is *removed* then the default takes over again and the value is no longer in the domain model. (How we represent this would probably depend on the implementation - null or empty lists or whatever). There's probably some other details to iron out though - for example, if a service is "autovivified" (to steal a Perl term) by another service but it doesn't appear in the domain.xml, how would the user know how to configure it? They'd have to "define" the service (with the same name) and then configure it how they want. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546276#546276] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - Installing JBossWS Native on JBAS 5.1.0

by ANIL SALDHANA

ANIL SALDHANA [http://community.jboss.org/people/anil.saldhana%40jboss.com] replied to the discussion "Installing JBossWS Native on JBAS 5.1.0" To view the discussion, visit: http://community.jboss.org/message/546275#546275 -------------------------------------------------------------- Please take this as a feature request. Stefan just told me that I can use AS5.1 direct to test out the PicketLink STS tests. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546275#546275] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

[JBoss Web Services Development] - Installating JBossWS Native on JBAS 5.1.0

by ANIL SALDHANA

ANIL SALDHANA [http://community.jboss.org/people/anil.saldhana%40jboss.com] created the discussion "Installating JBossWS Native on JBAS 5.1.0" To view the discussion, visit: http://community.jboss.org/message/546273#546273 -------------------------------------------------------------- This is my use case part of my automated build : a) I take a JBossAS 5.1.0.GA zip. Unzip it. b) I need to install JBossWS native onto it. Currently, what I see is that I need to download this JBossWS zip. Unzip it and fix an ant.properties file pointing to jboss.home and run an "ant deploy". As it stands, the JBossWS install is so bloated with multiple directories and jars that in fact could have been replaced by a simple zip that was created for each release of JBAS. I could then just unzip this install at the base of the JBAS5.1 and get the updated jars. This is for PicketLink integration tests and the current JBossWS install method is totally not working for me. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546273#546273] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "Profiles in domain.xml" To view the discussion, visit: http://community.jboss.org/message/546263#546263 -------------------------------------------------------------- If I understand you correctly that means the management API we expose is limited to what the users actually configure. It's no longer a fixed API. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546263#546263] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml

by David Lloyd

David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion "Profiles in domain.xml" To view the discussion, visit: http://community.jboss.org/message/546261#546261 -------------------------------------------------------------- > Brian Stansberry wrote: > 1) Admin uses tool that communicates with DC to see current configuration of running domain. That means all the default values a) have to be present in the in-memory domain model so they can be displayed and b) have to be present in the in-memory domain model on the server acting as the DC. > So a) means the > components which are (a) managed and (b) are in use but were not specified in the domain.xml > > must be provided with an SPI via which they can publish the defaults back to the domain model. Not the end of the world. > > > > But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC. Blah. OK how about this alternative view. Things not specified in domain.xml are also not specified in the doman DB, and the host defaults take over, and there's no writing back to the domain database of defaults. So the total domain view is really the sum of the local host configuration plus the domain configuration at the end of the day. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546261#546261] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/546243#546243 -------------------------------------------------------------- > > but it could be made optional to do this at boot time instead. The easiest way to do this would be to add a deployer and somesort of weld-lib repository service to the bootstrap process. e.g. part of bootstrap.xml sub-systems, which would simply take a set of lib locations to check, and spit out a set of lib jars that contain META-INF/beans.xml -- note, there is no Weld dependency, hence can be easily put into bootstrap -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546243#546243] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/546240#546240 -------------------------------------------------------------- The behavior should be deterministic / well-defined from the spec. My guess is the previous behavior was correct, if not, then like you said, it's just a matter of fixing the tests. But if it was correct, then your impl needs fixing in the following way -- actually a small change: > Notice that, interestingly, in the way things are implemented today, if you pass one of the missing classes as a parameter to a Deployment.loadBeanDeploymentArchive, my implementation will return the requested BDA correctly, but still the BDA will lack the requested class! == simply dynamically add the classes of requested class' owner jar to BDA's classes. Even thought our "glue" for BDA mapping is CL, it doesn't mean they are 1:1. And with that suggested fix I don't see the need for more fine grained mapping. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546240#546240] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 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 June 2010