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

Re: [jboss-dev-forums] [JBoss Profiler Development] - Problem with JBoss Profiler 2 Beta install.

by Hiamnshu Walia

Hiamnshu Walia [http://community.jboss.org/people/waliahimanshu] replied to the discussion "Problem with JBoss Profiler 2 Beta install." To view the discussion, visit: http://community.jboss.org/message/535330#535330 -------------------------------------------------------------- how to set Run.conf file for JBoss Profiler which one is correct if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -javaagent:jboss-profiler.jar -Djboss-profiler.properties=jboss-profiler.properties" fi or JAVA_OPTS="$JAVA_OPTS -javaagent:bin/jboss-profiler.jar -Djboss-profiler.properties=bin/jboss-profiler.properties" this giving problem , of jar file corrupt could not initialize the VM ,... also i have cheked my Jboss-profiler.jar file with jat -tf command its fine , not showing error -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535330#535330] Start a new discussion in JBoss Profiler Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Profiler Development] - jboss-profiler-2.0.0 Configuration Issue.

by Hiamnshu Walia

Hiamnshu Walia [http://community.jboss.org/people/waliahimanshu] replied to the discussion "jboss-profiler-2.0.0 Configuration Issue." To view the discussion, visit: http://community.jboss.org/message/535327#535327 -------------------------------------------------------------- can u tell me , which version of JBOSS Profiler will support with JBoss : Release ID: JBoss [Trinity] 4.2.3.GA and JDK :version JDK 1.6 -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535327#535327] Start a new discussion in JBoss Profiler Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Scott Stark

Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535295#535295 -------------------------------------------------------------- The ManagedComponent view is an admin client view of the deployment metadata, including any override values applied previously. This view would show the value of properties that are specified at an admin domain view, but if I change such a property I have overriden it at a component level. It is a post admin edit view. If we are to allow editing of a local server domain.xml, changes to a ManagedComponent view would have to propagate to the domain.xml. Changes to properties that are dervied from some higher level admin domain would not be propagated because you would not be specifying the domain level value. The admin domain would have a separate component for that. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535295#535295] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535279#535279 -------------------------------------------------------------- > Scott Stark wrote: > > 1. This is beyond the current doman model discussion. This is truly MDR level overrides of either domain.xml of ManagedComponent properties at a level above the server > While we are looking at doing just the server side up front I think it's an important question to answer. It's really a question of what the jboss-management ManagedComponent view represents. Is it a representation of the client view, and thus has a direct mapping to a future multi-server domain.xml, or is it a normalized/realized post-evaluated view? Long term, It can't really be used as a client api if it is solely the latter. It seems like it could be both though, and that's compatible with the approach you describe. A client can edit a view (one that could just be a bunch of managed components, or it could even be static metadata since the model is itself static), and that view would then be transformed into something a service or deployer could act on. In the end this would be realized in changes to the runtime MOs. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535279#535279] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Scott Stark

Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535277#535277 -------------------------------------------------------------- Right, and my answer for 4 is too generic. JON adds a constraint in a sense to ManagedComponents based on their type/subtype. A ManagedComponent has a type(DataSource, JmsDestination, etc.) and a subtype(LocalTx, Topic, ...). They use this to define the expected properties and operations. So, the exposed ManagedComponent for these type/subtype have an implicit contract based on the rhq-plugin.xml. The domain.xml metadata is largely a pojo representation of type/subtype property structures. A FooComponent has a representation in the domain.xml if its type/subtype is one we have pulled into the domain model. The only thing we don't know is if the FooComponent instance in question exists. The DeploymentTemplate notion Emanuel brought up is simplified, property only view of a ManagedComponent that defines the minimum set of properties that need to be defined in order to create a deployment. If you are thinking of meta-metadata at admin domain and cluster levels where you define defaults for properties like pool sizes, etc., that is something I would also view as true MDR behavior we would need integrate into the implementation. This is not something we would target for implementing initially for EAP6. As we get into admin clusters and domains I can see that we will have overrides, and perhaps even new metadata that intersects with the domain.xml representations for things like HA features, DNS, networks, etc. We really have no ManagedComponents for these features anyway. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535277#535277] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535274#535274 -------------------------------------------------------------- For 2) how about a DeploymentTemplate would only create a component metadata in the domain.xml, without a physical deployment. This does not handle local deployments, but is maybe closer to what you want to do with JON? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535274#535274] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Scott Stark

Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535273#535273 -------------------------------------------------------------- 1. This is beyond the current doman model discussion. This is truly MDR level overrides of either domain.xml of ManagedComponent properties at a level above the server 2. I'm not envision that we create any components at the domain or higher. We only have overrides of properties to components associated with a deployment. The domain or higher model may define which deployments are active, but not any actual deployments. 3. I assumed the answer was no I belive? 4. The only way this applies is if the metadata for FooComponent intersects with the metadata in the domain. 5. The only question I see is whether a given domain.xml setting actually applies to a deployment. As it stands now we would not know until runtime. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535273#535273] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535272#535272 -------------------------------------------------------------- Like tomcat (server.xml), or hornetQ (hornet-configuration.xml). Otherwise we would need to create MCBeans only to override the configuration. We don't have this notion anywhere at the moment, but i in those cases it could be useful to skip the scanning for beans and overriding the beanmetadata. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535272#535272] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Scott Stark

Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535268#535268 -------------------------------------------------------------- What would be an example of injecting a configuration fragment? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535268#535268] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

1
0
0 / 0

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

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535266#535266 -------------------------------------------------------------- > Scott Stark wrote: > > The following set of steps would each produce new sets of ManagedComponent property changes: > > 1. An initial domain.xml transforms the state of ManagedComponent properties from the new build state into some initial distribution state. There is a V1 repository of ManagedComponent property overrides. > 2. embedded JON/JON updates provide a further set of changes. Where these properties intersect the metadata values of the domain.xml, it would have to be updated if we are going to allow direct editing of a server domain.xml. There is a V2 repository of ManagedComponent property overrides. > 3. A rest client manipulates the current server domain metadata to push further updates. There is a V3 repository of ManagedComponent property overrides. > > There is only one authoritative store of ManagedComponent property edits that the profileservice implementation manages. Any physical domain.xml is a filtered view of this store. It definitely seems like domain.xml is a subset if we support the ability for frameworks to define managed components that are not part of our official domain.xml. This definitely includes runtime-only views, but it really could be anything. There are some general questions I have relating to this (not necessarily expecting that we know the answer to these yet). 1. The current ManagedComponent model is flat, but the things we are talking about in domain.xml hierarchical. For example, JON will need the ability to define a data source at the domain, cluster, or node level. How should this be mapped? I suppose it could be a jmx-style attribute list on the ManagedComponent (type=Datasource, level=domain) 2. Are components created from deployments differentiated from those in the domain? As an example someone includes foo-ds.xml in a deployment. Do we implicitly map this as a node level concept in a domain? 3. Assuming the answer to the latter question in 2 is yes, what happens when JON updates this definition? In the past we talked about having it add the entry to the domain.xml, and subsequent restarts the domain would take precedent. 4. Are components not in the formal domain definition visible to other nodes in the domain? As an example someone creates FooDeployer, and FooDeployer creates FooComponent. I assume the answer to this question is no. 5. If the answer is no, how does a client know that these elements are not part of the "official" api? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535266#535266] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 1 month

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 April 2010