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/535134#535134
--------------------------------------------------------------
I think the mapping onto profileservice itself should be quite separate from the domain model
So in a nutshel the operations related to profileservice should be not more than:
a) createNewDeployment()
b) addRequirement()
c) addCapability()
d) addMetaDataOverrideFragment()
e) addConfigurationFragment()
a,b,c should be fairly easy - since this is what a profile does.
d) would define a meta-data override of a existing deployment - like <component-ref />
e) is something where we don't have a notion for it now. This would be a service configuration e.g. <connector /> which does not neccearily create a bean nor deployment. Maybe this just maps to a injection of the metadata from the repository.
(d) and (e) would populate the unprocessed domain.xml fragements to a MetaDataRepository in a domain scope. This is needed since we have to distribute this to the whole domain - so we cannot do system property replacement there, as system properties in some cases could be just for a single instance/node e.g. ports-01.
Additionally we also need to populate the MetaDataRepository with default values, those have to be kept separate until the point we actually do transformations/injections of the domain metadata itself. Basically to reduce the size of the domain.xml to configuration overrides - additionally we can compare and only store changed values back to the domain.xml
> Scott Stark wrote:
>
> The relatively easy part is deciding what features we want to support via the model. The issues to resolve are how to:
> 1. Map this metadata onto the admin API of the profileservice. In general the domain.xml is a subset of the full metadata the service supports. The ManagedComponent view of the deployment metadata is the full featured configuration.
> 2. Provide a plug in to handle the mapping of the domain.xml metadata onto the ManagedComponent associated with the domain.xml element namespace. Currently the ManagedComponent is a view that is generated after deployment.
> 3. Deal with the different mechanisms for producing the runtime components from metadata. Some layers are using BeanMetaDataFactorys, jboss-managed plugins, custom deployers to manipulate metadata. Pulling in the domain.xml element override at the correct phase in the deployment chain is an issue.
> 4. Dealing with rollbacks of the domain.xml if we allow direct editing of the a domain.xml file. If the domain.xml is essentially a subset of admin edits of the available ManagedComponents, a rollback needs to write out a revised domain.xml that corresponds to the previous subset view.
>
I think (2) is where we should start - where each domain.xml fragment could map to e.g. a ManagedComponent. Based on this we can do the association between the domain.xml override and default values/additional handling and value transformation. We can also create dependencies on the actual profile handling this namespace. For metrics and other runtime views, we would need to do some merging of MOs once the beans are available and the mgtView is getting loaded.
(3) is the tricky part of overriding. Most probably this should be plugable and additional handler would be linked with the domain fragment itself.
However if we differentiate between: a), d), e) - this also gets easier, since we know what to do.
for createNewDeployment() it would mean that the fragment will be a predetermined attachment e.g. creating a DataSource, ThreadPool.
addMetaDataOverrideFragment() is the most expensive operation since we need to scan all attachment to identify a <component-ref /> and update the metadata passed through the deployer.
with addConfigurationFragment() you should most probably just ask the repository for the metadata itself - where we just do merging default values and value transformation (system property replacement, ports) - so you can either decide to reuse the domain metadata directly or transform it yourself.
(4) mostly relates to the persistence part. Where we need a way to compare and determine which values changed. During runtime this is easier since the fragments would correspond to a ManagedComponent. Where the persistence itself is the most critical piece.
I don't clearly see how preserving comments would fit into a static meta data model. Maybe we can reuse the SchemaBinding to partially update the xml. So not marshalling the whole xml, just take what changed and apply it to the existing xml or something else? This is something we need to validate and check asap and then see how this fits into what you have started.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535134#535134]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Transactions Development] - beanifying the config
by Jonathan Halliday
Jonathan Halliday [http://community.jboss.org/people/jhalliday] replied to the discussion
"beanifying the config"
To view the discussion, visit: http://community.jboss.org/message/535132#535132
--------------------------------------------------------------
> There are some properties that simply cannot be changed once the system is running. So if we must have setters they should do nothing or print a warning and do nothing.
Still not getting it are you. Initially they don't have a value. If the setter does nothing they will never have a value. Thus it's not possible to even start the system properly without working setters on the EnvironmentBeans. What you really mean is that once the component that uses that value has read the bean and initialized itself accordingly, it should never re-read the bean. That's how it works now, so no problem there. The only snag is that the setter can still be called after startup but will have no appreciable effect, which is a bit confusing for the user if they have not bothered to read the docs that explain that's the expected behavior.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535132#535132]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[Management Development] - domain.xml work
by Scott Stark
Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] created the discussion
"domain.xml work"
To view the discussion, visit: http://community.jboss.org/message/535088#535088
--------------------------------------------------------------
Here is an initial example of the domain.xml effort. The notion is that the domain.xml is a static metadata model of an API for configuring the server. This can be use for a rest client, command line client, junit client, etc.
The relatively easy part is deciding what features we want to support via the model. The issues to resolve are how to:
1. Map this metadata onto the admin API of the profileservice. In general the domain.xml is a subset of the full metadata the service supports. The ManagedComponent view of the deployment metadata is the full featured configuration.
2. Provide a plug in to handle the mapping of the domain.xml metadata onto the ManagedComponent associated with the domain.xml element namespace. Currently the ManagedComponent is a view that is generated after deployment.
3. Deal with the different mechanisms for producing the runtime components from metadata. Some layers are using BeanMetaDataFactorys, jboss-managed plugins, custom deployers to manipulate metadata. Pulling in the domain.xml element override at the correct phase in the deployment chain is an issue.
4. Dealing with rollbacks of the domain.xml if we allow direct editing of the a domain.xml file. If the domain.xml is essentially a subset of admin edits of the available ManagedComponents, a rollback needs to write out a revised domain.xml that corresponds to the previous subset view.
<?xml version="1.0" encoding="UTF-8"?>
<!--
The JBoss ApplicationServer domain configuration file.
-->
<domain xmlns="urn:jboss:profileservice:domain:1.0"
xmlns:xi=" http://www.w3.org/2001/XInclude http://www.w3.org/2001/XInclude">
<server name="server1" xmlns="urn:jboss:profileservice:server:1.0">
<properties>
<property name="timeout">3000</property>
<!-- Enable EAR classloader isolation. -->
<property name="classloaderIsolation">true</property>
</properties>
<shutdown-timeout>3600000</shutdown-timeout>
</server>
<jdbc-resources xmlns="urn:jboss:profileservice:jdbc-resources:1.0">
<jdbc-resource jndi-name="jdbc/TimerPool" pool-name="TimerPool" enabled="true">
<min-pool-size>1</min-pool-size>
<max-pool-size>10</max-pool-size>
<username>userx</username>
<password>passy</password>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<properties>
<entry key="query-timeout" value="30" />
<entry key="new-connection-sql" value="select * from x" />
</properties>
</jdbc-resource>
<jdbc-resource jndi-name="java:DefaultDS" pool-name="DefaultDS" enabled="true">
<min-pool-size>1</min-pool-size>
<max-pool-size>10</max-pool-size>
<username>sa</username>
<password></password>
<connection-url>jdbc:hsqldb:hsql://${jboss.bind.address}:1701</connection-url>
<driver-class>org.hsqldb.jdbcDriver</driver-class>
<type-mapping>Hypersonic SQL</type-mapping>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<properties>
<entry key="query-timeout" value="30" />
<entry key="new-connection-sql" value="select * from x" />
<entry key="idle-timeout-minutes" value="0" />
<entry key="track-statements" value="true" />
<entry key="security-domain" value="HsqlDbRealm" />
<entry key="prepared-statement-cache-size" value="32" />
</properties>
</jdbc-resource>
</jdbc-resources>
<jms-resources xmls="urn:jboss:profileservice:jms-resources:1.0">
<topic name="topic/MyTopic" />
<queue name="queue/MyQueue">
<depends name="someDependencyRealNameNotJMXObjectName" />
</queue>
</jms-resources>
<threads xmlns="urn:jboss:profileservice:threads:1.0">
<!-- The system thread group for all JBoss threads. -->
<thread-group name="SystemThreadGroup" group-name="System Threads" daemon="true"/>
<!--
~ This thread pool is for SHORT-RUNNING tasks that block very little or not at all. Long-running
~ tasks submitted to this pool may cause starvation and extended blocking.
-->
<thread-group name="ShortTasksThreadGroup" group-name="Short Tasks Threads">
<parent-thread-group name="SystemThreadGroup"/>
</thread-group>
<!--
~ This thread pool is for LONG-RUNNING tasks that may block for extended periods, such as
~ blocking I/O network connection threads. Short-running tasks submitted to this pool may
~ cause excessive lock contention and performance degradation.
-->
<thread-group name="LongTasksThreadGroup" group-name="Long Tasks Threads">
<parent-thread-group name="SystemThreadGroup"/>
</thread-group>
<!-- A simple direct executor which is always available for use. -->
<executor name="DirectExecutor" type="direct">
</executor>
<executor name="BoundedThreadPool" type="bounded-queue-thread-pool">
<entry key="blocking" value="true" />
<entry key="thread-factory" value="ShortTasksThreadFactory"/>
<entry key="queue-length.count" value="500"/>
<entry key="queue-length.per-cpu" value="200"/>
<entry key="core-threads.count" value="5"/>
<entry key="core-threads.per-cpu" value="2"/>
<entry key="max-threads.count" value="10"/>
<entry key="max-threads.per-cpu" value="3"/>
<entry key="keepalive.time" value="30"/>
<entry key="keepalive.time-unit" value="seconds"/>
<!--
<task-filter>
<clear-context-classloader/>
<clear-tls/>
</task-filter>
-->
</executor>
<executor name="LongRunningTasksThreadPool" type="queueless-thread-pool">
<entry key="blocking" value="true" />
<entry key="thread-factory" value="LongTasksThreadFactory"/>
<!--
<task-filter>
<clear-context-classloader/>
<clear-tls/>
</task-filter>
-->
</executor>
<thread-factory name="ShortTasksThreadFactory">
<thread-group name="ShortTasksThreadGroup"/>
</thread-factory>
<thread-factory name="LongTasksThreadFactory">
<thread-group name="LongTasksThreadGroup"/>
</thread-factory>
</threads>
<system-properties>
<entry key="tmp.dir" value="/usr/tmp"/>
</system-properties>
<!-- TODO, metadata for the various cotainers, transport, apps, etc -->
</domain>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535088#535088]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Making JavassistTypeInfo serializable
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"Making JavassistTypeInfo serializable"
To view the discussion, visit: http://community.jboss.org/message/535046#535046
--------------------------------------------------------------
> Kabir Khan wrote:
>
> Looking at https://jira.jboss.org/jira/browse/JBREFLECT-16 https://jira.jboss.org/jira/browse/JBREFLECT-16 I wanted to do the same as I did to make the reflect flavour properly serializable, which was simply to add this to ClassInfo, as mentioned here http://community.jboss.org/message/534270#534270:
> [...]
> If I do the same for JavassistTypeInfo, then that will load the class. Is that a bad thing? Probably...
>
> The alternative for this simple implementation to work is to save the name and the classloader, and classloaders are not serializable.
>
> Or am I missing something? When deserializing a class should that happen in the same classloader (or one with access to similar classes if serialized out of the vm) as the one that serialized it in the first place? If the answer is yes, then I can go forward with this.
>
Yes, it +should+, however that is really up to the serialization implementation to get right. In most cases, folks just use the thread's context classloader or just one static classloader for deserialization. Perhaps in our modular future, we'll see a trend of classes being annotated with identifiers which will locate the correct corresponding classloader on the receiving side.
In other words... don't sweat it, it should be OK.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535046#535046]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years