[JBoss Tools Development] - Has some way that the editor only shows me some part of a file that is passed as input?
by Agustin Quimcinho
Agustin Quimcinho [http://community.jboss.org/people/agunin] created the discussion
"Has some way that the editor only shows me some part of a file that is passed as input?"
To view the discussion, visit: http://community.jboss.org/message/577393#577393
--------------------------------------------------------------
Has some way that the editor only shows me some part of a file that is passed as input?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/577393#577393]
Start a new discussion in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
- 2
- 2
[EJB Development] - Migrate from Weblogic to Jboss 5.0.1 as
by Marek Waja
Marek Waja [http://community.jboss.org/people/dew] created the discussion
"Migrate from Weblogic to Jboss 5.0.1 as"
To view the discussion, visit: http://community.jboss.org/message/577580#577580
--------------------------------------------------------------
Hello,
I am novice in Jboss and I have a problem.
I have EAR application for weblogic.
This EAR contains two enterprise java beans (EJB) JARs and one WAR archive.
EJB contain deployment descriptors:
ejb-jar.xml
and specific files for Weblogic:
weblogic-ejb-jar.xml
weblogic-cmp-rdbms.xml
I need create appropriate specific deployment desriptor for JBoss:
I found there are:
jboss.xml
jbosscmp-jdbc.xml
persistence.xml
But I am not sure how use persistence.xml?
Next. I have problem with tag <automatic-key-generation> in weblogic-cmp-rdbms.xml.
How can I generate key for jboss??
And in file weblogic-ejb-jar.xml are tags:
<entity-descriptor>
<persistence>
<persistence-use>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>7.0</type-version>
<type-storage>META-INF/weblogic-cmp-rdbms-jar.xml</type-storage>
</persistence-use>
</persistence>
</entity-descriptor>
<entity-descriptor>
<persistence>
<persistence-use>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>7.0</type-version>
<type-storage>META-INF/weblogic-cmp-rdbms-jar.xml</type-storage>
</persistence-use>
</persistence>
</entity-descriptor>
What tags are equals for Jboss.
Thank you very much
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/577580#577580]
Start a new discussion in EJB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
- 1
- 0
[JBoss Web Services Development] - failed to create jaxb context
by Gary Pinkham
Gary Pinkham [http://community.jboss.org/people/garyp] created the discussion
"failed to create jaxb context"
To view the discussion, visit: http://community.jboss.org/message/577276#577276
--------------------------------------------------------------
I created a web service client using wsconsume. wrote a unit test and it worked fine.. could see the call going out and the data coming back.. I then created a custom Action for JBoss ESB to perform the call to the Web Service and this fails with "failed to create jaxb context" Any ideas what might be causing the hangup when calling from an ESB action as opposed to the command line unit test client? (I copied the code over so I know it's the same client code)..
Thanks!
Gary
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/577276#577276]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
- 1
- 2
[JBoss AS7 Development] - JBoss AS7 User Guide
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"JBoss AS7 User Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16068
--------------------------------------------------------------
This is a brief guide intended to help users who wish to experiment with JBoss AS 7 as it undergoes development. Feedback on its content is most appreciated, either via comments on this page, via forum posts in this "JBoss AS7 Development" section of the wiki, or by posts to the https://lists.jboss.org/mailman/listinfo/jboss-development jboss-development mailing list.
AS 7 is currently in "Alpha" status, so users should not expect all (or even most) of the capabilities of more stable AS 5 and 6 releases to be present. Users should also be aware that significant changes may be made from one alpha release to another.
h2. Getting JBoss AS 7
AS 7 is available from the http://www.jboss.org/jbossas/downloads.html jboss.org download page. As in earlier JBoss AS releases, installation consists of unzipping the release distribution.
Users are encouraged to check out the AS 7 source and build it themselves. This is quite quick and painless once git is installed on your system, and getting git set up is also quite easy to do. See the http://community.jboss.org/docs/DOC-15596 Hacking On JBoss AS 7 wiki page for more details on working with the AS 7 source.
h2. Quick Start
Once you have the distribution unzipped, you need to decide whether you want to work in "domain mode" or "standalone mode". See "Domain Mode vs. Standalone Mode" below for more on what those choices mean.
If you want to work in domain mode, open a terminal and cd into the distribution's bin directory, and run the "domain" launch script:
$ cd bin
$ ./domain.sh
On Windows:
> cd bin
> domain.bat
This will launch a total of 5 processes on your system: three JBoss AS server instances; a Domain Controller process that acts as a central management point for all servers that belong to the same "domain"; and a lightweight Process Controller process that is responsible for spawning the other 4 processes and monitoring their lifecycle.
If you want to work in standalone mode, open a terminal and cd into the distribution's bin directory, and run the "standalone" launch script:
$ cd bin
$ ./standalone.sh
On Windows:
> cd bin
> standalone.bat
This will launch a single process on your system, a standalone JBoss AS server instance.
If you have the AS 7 source checked out, there are a number of demos that can be run from the source checkout's demos module. See below for details.
h2. Domain Mode vs. Standalone Mode
One of the primary new features of AS 7 is the ability to manage multiple AS instances from a single control point. A collection of such servers are referred to as members of a "domain", with a single Domain Controller process acting as the management control point. Domains can span multiple physical (or virtual) machines, with all AS instances on a given host under the control of a Host Controller process. The Host Controllers interact with the Domain Controller to control the lifecycle of the AS instances running on that host and to assist the Domain Controller in managing them.
When you launch JBoss AS in "domain mode" (via the domain.sh or domain.bat launch scripts) your intent is to launch a Domain Controller, a Host Controller and usually at least one AS instance.
For more on running servers in domain mode, a roughly 20 minute video is available online (divided in two pieces):
http://www.youtube.com/watch?v=phV3QiKQf2E http://www.youtube.com/watch?v=phV3QiKQf2E
http://www.youtube.com/watch?v=gCeQ2KIO0qc http://www.youtube.com/watch?v=gCeQ2KIO0qc
For many use cases, the centralized managment capability available via domain mode is not necessary. For these use cases, the AS can also be run in "standalone mode". In standalone mode each AS instance is an independent process, much like an AS 3, 4, 5, or 6 instance is. Standalone instances can be launched via the standalone.sh or standalone.bat launch scripts.
If more than one standalone instance is launched and multi-server management is desired, it is the user's responsibility to coordinate management across the servers.
The current AS 7 alpha release does not support HA functionality. However, it's important to understand that once HA functionality is added, it will be orthogonal to "domain mode" vs. "standalone mode". That is, a group of servers running in standalone mode will be able to be configured to form an HA cluster. The domain and standalone modes determine how the servers are managed, not what capabilities they provide.
A given server instance cannot be switched between domain mode and standalone mode; i.e. you cannot launch domain.sh, stop the processes, and then launch standalone.sh and expect any relationship between what was running. The configurations are separate. We may in future releases include some tooling to ease the task of translating a given server configuration from domain mode to standalone mode.
h2. Contents of the AS 7 Distribution
The AS 7 distribution includes the following directories:
*bin* -- location of the launch scripts
*docs* -- license files, documentation, schemas, examples, etc. The amount of content in this directory will increase as development continues.
*modules* -- AS 7 is based on a modular classloading architecture. The various modules used in the server are stored here. Generally speaking, this is not an area that would be modified by end users.
*domain* -- only relevant when domain mode is used. Configuration files, deployment content, and writeable areas used by the domain mode processes that run off of this installation. See below for further details.
*standalone* -- only relevant when standalone mode is used. Configuration files, deployment content, and writeable areas used by the single standalone server that runs off this installation. See below for further details.
h3. Contents of the "domain" Directory
Only relevant when domain mode is used.
*configuration* -- configuration files for the domain and for the Host Controller and any servers running off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*content* -- an internal working area for the Host Controller that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.
*log* -- location where the Process Controller and Host Controller write their log files.
*servers* -- writeable area used by each AS instance. Each AS instance will have its own subdirectory, created when the server is first started. In each server's subdirectory there will be the following subdirectories:
data -- information written by the server that needs to survive a restart of the server
log -- the server's log files
tmp -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h3. Contents of the "standalone" Directory
Only relevant when standalone mode is used.
*configuration* -- configuration files for the standalone server that runs off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*data* -- information written by the server that needs to survive a restart of the server
*deployments* -- an area where end user deployment content can be placed if automatic detection and deployment of that content into the server's runtime is desired. The server's management API exposes other means for installing deployment content, and use of that API in preference to the deployments directory is preferred. We realize however, that at this early stage in AS 7's development the tooling around the deployment API is in its infancy, so many users will utilize the deployments directory to deploy content. Note that "domain mode" does not support deploying content based on scanning a filesystem.
*log* -- the server's log files
*tmp* -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h2. "Domain Mode" Configuration Files
Located in the *domain/configuration* directory.
*domain.xml* -- primary configuration file for the domain. Among other things, includes the configuration of the various "profiles" that AS instances can be configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. an embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Includes the definition of groups of sockets that those subsystems may open. And includes definition of "server groups", to which a profile, a group of socket definitions and zero or more deployments are mapped. Each individual server will be mapped (in host.xml, see below) to a server group; the configuration of that server group largely defines the configuration of the individual server.
A domain.xml file must be located in the domain/configuration directory of an installation that's meant to run the Domain Controller. It does not need to be present in installations that are not meant to run a Domain Controller; i.e. those whose Host Controller is configured to contact a remote Domain Controller. The presence of a domain.xml file on such a server does no harm; it will be ignored.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <domain> element, to learn more about configuration of a Domain Controller.
*host.xml* -- configuration file for the Host Controller that runs off of this particular installation. Each installation must have a host.xml file. Contains configuration information that is specific to the particular installation. Primarily:
* the listing of the names of the actual AS server instances that are meant to run off of this installation, along with the server group they belong to.
* configuration of how the Host Controller is to contact the Domain Controller to register itself and access the domain configuration. This may either be configuration of how to find and contact a remote Domain Controller, or a configuration telling the Host Controller to itself act as the Domain Controller.
* configuration of items that are specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml. Abstract path names in domain.xml can be mapped to actual filesystem paths in host.xml.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <host> element, to learn more about configuration of a Host Controller.
*logging.properties* -- Contains the logging configuration for the Host Controller and Process Controller that run off of this installation. Also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.
h2. "Standalone Mode" Configuration Files
Located in the *standalone/configuration* directory.
*standalone.xml* -- primary configuration file for the AS instance. Among other things, includes the configuration of the "profile" that the AS instance is configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. an embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Also includes the definition of the sockets that those subsystems may open.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.
h2.
Available Subsystems
AS 7 is under active development. Not all capabilities present in more mature releases of the AS 5 and 6 series are available in AS 7 yet. Following is a brief listing of the subsystems available in the various AS 7 releases. Items listed below may not be entirely feature complete.
h4. 7.0.0.Alpha1
* logging -- configuration of logging appenders, categories, etc
* threads -- thread pool management
* sockets -- socket binding management
* naming -- local JNDI. Note that direct remote access to JNDI is not supported in Alpha1 (see the client.jms demo for an example of a clever hack to get remote access to JNDI via an MBeanServerConnection)
* transactions -- JTA
* jmx -- MBeanServer with remote access capability
* web -- basic servlet and JSP support
* messaging -- HornetQ server
* JMS -- JMS queues, topics and connection factories
* JCA connectors
* Datasources
* JCA resource adapter deployments
* osgi -- OSGI bundle deployment
* remoting -- JBoss Remoting 3 connectors
* managed beans -- EE 6 managed bean deployments
* SAR deployments -- both legacy mbean deployments and those based on the JDK 6 ServiceLoader concept. Note that not all legacy sar capabilities are supported
* Filesystem based hot deployment scanning (standalone mode only) -- note that exploded deployments are not currently supported
h2. Demos in the Source Checkout
The source checkout includes a "demos" module that includes a number of demos that can be run from maven. Building the module will output a usage note that explains how to run the demos:
usage:
[echo] To run an example:
[echo] 1) In a separate console window,start either a standalone JBoss AS instance or a JBoss AS domain
[echo] 2) Run mvn package -Dexample=<example.name> where "exammple.name is the name of the example
[echo]
[echo] Valid example names to run against a standalone JBoss AS instance are
[echo] sar - deploys mbeans packaged in a sar
[echo] managedbean - deploys a managed bean
[echo] serviceloader - deploys a serviceloader style service
[echo] messaging - deploys HornetQ native sender and receiver
[echo] jms - deploys HornetQ JMS sender and receiver
[echo] jms.client - Uses HornetQ JMS API from the client
[echo] rar - deploys a resource adapter
[echo] ds - deploys a test bean for data sources
[echo] war - deploys a simple servlet and connects to it
[echo] client.messaging - creates a HornetQ core queue using the management API
[echo] client.jms - creates a JMS queue using the management API
[echo] web.connector - creates and removes a jboss web connector
[echo]
[echo] Valid example names to run against a JBoss AS domain are
[echo] domain.configs - reads the domain config and any available host controller configs
[echo] domain.ds - deploys deploys a test bean for data sources
[echo] domain.messaging - deploys HornetQ native sender and receiver
[echo] domain.rar - deploys deploys a resource adapter
[echo] domain.servers - shows domain, host controller and server configs, starts/stops servers
The primary point of the demos is to look at the source code and see how they use the AS's management API to deploy content and/or alter the configuration of the running server(s). To see how an example works, look at the relevant demos/src/main/java/org/jboss/as/demos/<example.name>/runner.ExampleRunner.java file.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16068]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
- 1
- 0
[Javassist Development] - hierarchy in org.hibernate.proxy.pojo.javassist.SerializableProxy ?
by Cédric Teyton
Cédric Teyton [http://community.jboss.org/people/twizol] created the discussion
"hierarchy in org.hibernate.proxy.pojo.javassist.SerializableProxy ?"
To view the discussion, visit: http://community.jboss.org/message/577192#577192
--------------------------------------------------------------
15:03:04,842 INFO [STDOUT] Hibernate: select compte0_.idCompte as idCompte0_0_, compte0_.login as login0_0_, compte0_.password as password0_0_ from compte compte0_ where compte0_.idCompte=?
15:03:05,237 INFO [STDOUT] Hibernate: select contact0_.idContact as idContact1_, contact0_.adresse as adresse1_, contact0_.codePostal as codePostal1_, contact0_.compte_idCompte as compte10_1_, contact0_.fax as fax1_, contact0_.groupe_idGroupe as groupe11_1_, contact0_.mail as mail1_, contact0_.nom as nom1_, contact0_.prenom as prenom1_, contact0_.tel as tel1_, contact0_.ville as ville1_ from contact contact0_ where contact0_.compte_idCompte=? order by contact0_.prenom
15:03:05,302 ERROR [[ContactBookControllerContact]] Servlet.service() for servlet ContactBookControllerContact threw exception
java.lang.reflect.UndeclaredThrowableException
at $Proxy92.getContacts(Unknown Source)
at contact.book.web.ContactBookControllerContact.doPost(ContactBookControllerContact.java:164)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841)
at org.jboss.serial.io.MarshalledObjectForLocalCalls.get(MarshalledObjectForLocalCalls.java:60)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
... 22 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
... 31 more
Caused by: java.io.IOException: The hierarchy of org.hibernate.proxy.pojo.javassist.SerializableProxy is different in your current classPath
at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:80)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:380)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841)
at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)
at java.util.ArrayList.readObject(ArrayList.java:593)
... 36 moreHello
Hi everybody,
I'm currently working on a Jboss application, holding a basic "Contact Book". Everything was working fine with Hibernate and my EJb, and right now this is happening when i try to retrieve from my Web Application a list of persistent objects located in my database :
15:03:04,842 INFO [STDOUT] Hibernate: select compte0_.idCompte as idCompte0_0_, compte0_.login as login0_0_, compte0_.password as password0_0_ from compte compte0_ where compte0_.idCompte=?
15:03:05,237 INFO [STDOUT] Hibernate: select contact0_.idContact as idContact1_, contact0_.adresse as adresse1_, contact0_.codePostal as codePostal1_, contact0_.compte_idCompte as compte10_1_, contact0_.fax as fax1_, contact0_.groupe_idGroupe as groupe11_1_, contact0_.mail as mail1_, contact0_.nom as nom1_, contact0_.prenom as prenom1_, contact0_.tel as tel1_, contact0_.ville as ville1_ from contact contact0_ where contact0_.compte_idCompte=? order by contact0_.prenom
15:03:05,302 ERROR [[ContactBookControllerContact]] Servlet.service() for servlet ContactBookControllerContact threw exception
*java.lang.reflect.UndeclaredThrowableException*
at $Proxy92.getContacts(Unknown Source)
at contact.book.web.ContactBookControllerContact.doPost(ContactBookControllerContact.java:164)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:662)
*Caused by: java.io.IOException*
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841)
at org.jboss.serial.io.MarshalledObjectForLocalCalls.get(MarshalledObjectForLocalCalls.java:60)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
... 22 more
*Caused by: java.lang.reflect.InvocationTargetException*
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
... 31 more
*Caused by: java.io.IOException: The hierarchy of org.hibernate.proxy.pojo.javassist.SerializableProxy is different in your current classPath*
at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:80)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:380)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:841)
at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)
at java.util.ArrayList.readObject(ArrayList.java:593)
... 36 more
To be really honest, i don't understand what this error means...
Could someone please help to me figure out this?
Thanks a lot !
Cédric
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/577192#577192]
Start a new discussion in Javassist Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
- 1
- 0
[JBoss AS7 Development] - JBoss AS7 User Guide
by Radim Hanus
Radim Hanus [http://community.jboss.org/people/rhanus] modified the document:
"JBoss AS7 User Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16068
--------------------------------------------------------------
This is a brief guide intended to help users who wish to experiment with JBoss AS 7 as it undergoes development. Feedback on its content is most appreciated, either via comments on this page, via forum posts in this "JBoss AS7 Development" section of the wiki, or by posts to the https://lists.jboss.org/mailman/listinfo/jboss-development jboss-develoment mailing list.
AS 7 is currently in "Alpha" status, so users should not expect all (or even most) of the capabilities of more stable AS 5 and 6 releases to be present. Users should also be aware that significant changes may be made from one alpha release to another.
h2. Getting JBoss AS 7
AS 7 is available from the http://www.jboss.org/jbossas/downloads.html jboss.org download page. As in earlier JBoss AS releases, installation consists of unzipping the release distribution.
Users are encouraged to check out the AS 7 source and build it themselves. This is quite quick and painless once git is installed on your system, and getting git set up is also quite easy to do. See the http://community.jboss.org/docs/DOC-15596 Hacking On JBoss AS 7 wiki page for more details on working with the AS 7 source.
h2. Quick Start
Once you have the distribution unzipped, you need to decide whether you want to work in "domain mode" or "standalone mode". See XXX for more on what those choices mean.
If you want to work in domain mode, open terminal and cd into the distribution's bin directory, and run the "domain" launch script:
$ cd bin
$ ./domain.sh
On Windows:
> cd bin
> domain.bat
This will launch a total of 5 processes on your system: three JBoss AS server instances; a Domain Controller process that acts as a central management point for all servers that belong to the same "domain"; and a lightweight Process Controller process that is responsibility for spawning the other 4 processes and monitoring their lifecycle.
If you want to work in standalone mode, open terminal and cd into the distribution's bin directory, and run the "standalone" launch script:
$ cd bin
$ ./standalone.sh
On Windows:
> cd bin
> standalone.bat
This will launch a single process on your system, a standalone JBoss AS server instance.
If you have the AS 7 source checked out, there are a number of demos that can be run from the source checkout's demos module. See below for details.
h2. Domain Mode vs. Standalone Mode
One of the primary new features of AS 7 is the ability to manage multiple AS instances from a single control point. A collection of such servers are referred to as members of a "domain", with a single Domain Controller process acting as the management control point. Domains can span multiple physical (or virtual) machines, with all AS instances on a given host under the control of a Host Controller process. The Host Controllers interact with the Domain Controller to control the lifecycle of the AS instances running on that host and to assist the Domain Controller in managing them.
When you launch JBoss AS in "domain mode" (via the domain.sh or domain.bat launch scripts) your intent is to launch a Domain Controller, a Host Controller and usually at least one AS instance.
For more on running servers in domain mode, a roughly 20 minute video is available online (divided in two pieces):
http://www.youtube.com/watch?v=phV3QiKQf2E http://www.youtube.com/watch?v=phV3QiKQf2E
http://www.youtube.com/watch?v=gCeQ2KIO0qc http://www.youtube.com/watch?v=gCeQ2KIO0qc
For many use cases, the centralized managment capability available via domain mode is not necessary. For these use cases, the AS can also be run in "standalone mode". In standalone mode each AS instance is an independent process, much like an AS 3, 4, 5, or 6 instance is. Standalone instances can be launched via the standalone.sh or standalone.bat launch scripts.
If more than one standalone instance is launched and multi-server management is desired, it is the user's responsibility to coordinate management across the servers.
The current AS 7 alpha release does not support HA functionality. However, it's important to understand that once HA functionality is added, it will be orthogonal to "domain mode" vs. "standalone mode". That is, a group of servers running in standalone mode will be able to be configured to form an HA cluster. The domain and standalone modes determine how the servers are managed, not what capabilities they provide.
A given server instance cannot be switched between domain mode and standalone mode; i.e. you cannot launch domain.sh, stop the processes, and then launch standalone.sh and expect any relationship between what was running. The configurations are separate. We may in future releases include some tooling to ease the task of translating a given server configuration from domain mode to standalone mode.
h2. Contents of the AS 7 Distribution
The AS 7 distribution includes the following directories:
*bin* -- location of the launch scripts
*docs* -- license files, documentation, schemas, examples, etc. The amount of content in this directory will increase as development continues.
*modules* -- AS 7 is based on a modular classloading architecture. The various modules used in the server are stored here. Generally speaking, this is not an area that would be modified by end users.
*domain* -- only relevant when domain mode is used. Configuration files, deployment content, and writeable areas used by the domain mode processes that run off of this installation. See below for further details.
*standalone* -- only relevant when standalone mode is used. Configuration files, deployment content, and writeable areas used by the single standalone server that runs off this installation. See below for further details.
h3. Contents of the "domain" Directory
Only relevant when domain mode is used.
*configuration* -- configuration files for the domain and for the Host Controller and any servers running off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*content* -- an internal working area for the Host Controller that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.
*log* -- location where the Process Controller and Host Controller write their log files.
*servers* -- writeable area used by each AS instance. Each AS instance will have its own subdirectory, created when the server is first started. In each server's subdirectory there will be the following subdirectories:
data -- information written by the server that needs to survive a restart of the server
log -- the server's log files
tmp -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h3. Contents of the "standalone" Directory
Only relevant when standalone mode is used.
*configuration* -- configuration files for the standalone server that runs off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*data* -- information written by the server that needs to survive a restart of the server
*deployments* -- an area where end user deployment content can be placed if automatic detection and deployment of that content into the server's runtime is desired. The server's management API exposes other means for installing deployment content, and use of that API in preference to the deployments directory is preferred. We realize however, that at this early stage in AS 7's development the tooling around the deployment API is in its infancy, so many users will utilizes the deployments directory to deploy content. Note that "domain mode" does not support deploying content based on scanning a filesystem.
*log* -- the server's log files
*tmp* -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide.
h2. "Domain Mode" Configuration Files
Located in the *domain/configuration* directory.
*domain.xml* -- primary configuration file for the domain. Among other things, includes the configuration of the various "profiles" that AS instances can be configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Includes the definition of groups of sockets that those subsystems may open. And includes definition of "server groups", to which a profile, a group of socket definitions and zero or more deployments are mapped. Each individual server will be mapped (in host.xml, see below) to a server group; the configuration of that server group largely defines the configuration of the individual server.
A domain.xml file must be located in the domain/configuration directory of an installation that's meant to run the Domain Controller. It does not need to be present in installations that are not meant to run a Domain Controller; i.e. those whose Host Controller is configured to contact a remote Domain Controller. The presence of a domain.xml file on such a server does no harm; it will be ignored.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <domain> element, to learn more about configuration of a Domain Controller.
*host.xml* -- configuration file for the Host Controller that runs off of this particular installation. Each installation must have a host.xml file. Contains configuration information that is specific to the particular installation. Primarily:
* the listing of the names of the actual AS server instances that are meant to run off of this installation, along with the server group they belong to.
* configuration of how the Host Controller is to contact the Domain Controller to register itself and access the domain configuration. This may either be configuration of how to find and contact a remote Domain Controller, or a configuration telling the Host Controller to itself act as the Domain Controller.
* configuration of items that are specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml. Abstract path names in domain.xml can be mapped to actual filesystem paths in host.xml.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <host> element, to learn more about configuration of a Host Controller.
*logging.properties* -- Contains the logging configuration for the Host Controller and Process Controller that run off of this installation. Also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.
h2. "Standalone Mode" Configuration Files
Located in the *standalone/configuration* directory.
*standalone.xml* -- primary configuration file for the AS instance. Among other things, includes the configuration of the "profile" that the AS instance is configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. and embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Also includes the definition of the sockets that those subsystems may open.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/domain/src/main/resources... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.
h2.
Available Subsystems
AS 7 is under active development. Not all capabilities present in more mature releases of the AS 5 and 6 series are available in AS 7 yet. Following is a brief listing of the subsystems available in the various AS 7 releases. Items listed below may not be entirely feature complete.
h4. 7.0.0.Alpha1
* logging -- configuration of logging appenders, categories, etc
* threads -- thread pool management
* sockets -- socket binding management
* naming -- local JNDI. Note that direct remote access to JNDI is not supported in Alpha1 (see the client.jms demo for an example of a clever hack to get remote access to JNDI via an MBeanServerConnection)
* transactions -- JTA
* jmx -- MBeanServer with remote access capability
* web -- basic servlet and JSP support
* messaging -- HornetQ server
* JMS -- JMS queues, topics and connection factories
* JCA connectors
* Datasources
* JCA resource adapter deployments
* osgi -- OSGI bundle deployment
* remoting -- JBoss Remoting 3 connectors
* managed beans -- EE 6 managed bean deployments
* SAR deployments -- both legacy mbean deployments and those based on the JDK 6 ServiceLoader concept. Note that not all legacy sar capabilities are supported
* Filesystem based hot deployment scanning (standalone mode only) -- note that exploded deployments are not currently supported
h2. Demos in the Source Checkout
The source checkout includes a "demos" module that includes a number of demos that can be run from maven. Building the module will output a usage note that explains how to run the demos:
usage:
[echo] To run an example:
[echo] 1) In a separate console window,start either a standalone JBoss AS instance or a JBoss AS domain
[echo] 2) Run mvn package -Dexample=<example.name> where "exammple.name is the name of the example
[echo]
[echo] Valid example names to run against a standalone JBoss AS instance are
[echo] sar - deploys mbeans packaged in a sar
[echo] managedbean - deploys a managed bean
[echo] serviceloader - deploys a serviceloader style service
[echo] messaging - deploys HornetQ native sender and receiver
[echo] jms - deploys HornetQ JMS sender and receiver
[echo] jms.client - Uses HornetQ JMS API from the client
[echo] rar - deploys a resource adapter
[echo] ds - deploys a test bean for data sources
[echo] war - deploys a simple servlet and connects to it
[echo] client.messaging - creates a HornetQ core queue using the management API
[echo] client.jms - creates a JMS queue using the management API
[echo] web.connector - creates and removes a jboss web connector
[echo]
[echo] Valid example names to run against a JBoss AS domain are
[echo] domain.configs - reads the domain config and any available host controller configs
[echo] domain.ds - deploys deploys a test bean for data sources
[echo] domain.messaging - deploys HornetQ native sender and receiver
[echo] domain.rar - deploys deploys a resource adapter
[echo] domain.servers - shows domain, host controller and server configs, starts/stops servers
The primary point of the demos is to look at the source code and see how they use the AS's management API to deploy content and/or alter the configuration of the running server(s). To see how an example works, look at the relevant demos/src/main/java/org/jboss/as/demos/<example.name>/runner.ExampleRunner.java file.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16068]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
- 1
- 0
[JBoss AS7 Development] - AS 7 "Detyped" Management API
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"AS 7 "Detyped" Management API"
To view the document, visit: http://community.jboss.org/docs/DOC-16235
--------------------------------------------------------------
+*This document is currently a draft, and is subject to considerable modification.*+
This document is meant to describe the design of the management API of an AS 7 domain and of a single AS 7 server instance running in standalone mode.
The API is described as "detyped" to reflect the fact that the API only exposes a small number of types besides JDK classes.
The goals are to:
* Define a Java-based API that can be consumed by a remote java client that requires only a small number of types besides JDK classes to be on the client classpath. Any complex types involved in the API are expressed in terms of a fixed set of general purpose classes. The types needed on the client classpath are:* A library containing the small set of general purpose types (see discussion of MetaValue, MetaType below), plus some helper utilities (e.g. Builder classes) to assist in building up objects of those types.
* 4 interface classes, each of which describes the methods exposed by one of the server side "controllers". The parameters and return types in these interfaces should be expressed in terms of the general purpose types. The methods in these interfaces will be limited and general purpose in nature, i.e. there will not be a myriad of detailed methods like "setHttpPort(int port)". The 4 types of "controllers" are:* DomainController. Primary management point for an AS 7 domain. Responsible for all configurations in the domain.xml file. The DomainController is also intended to function as the central management point for all hosts and servers in the domain, delegating to internal APIs exposed by the HostControllers or ServerControllers as necessary. However, a running AS 7 domain does not require a running DomainController, so the HostControllers and ServerControllers will also expose a management API.
* HostController. Responsible for controlling one or more AS 7 server instances on a physical or virtual host. Responsible for all configurations in the host.xml file for that host. Will also expose some host-specific management operations, e.g. start/stop/restart a server.
* ServerController (domain mode): Provides a read-only view of an individual server's configuration. Provides access to any metrics exposed by the server. Provides access to any non-configuration-related management operations exposed by the server (e.g. remove message X from JMS queue Y.) Does not expose any ability to update the server's persistent configuration, as all aspects of a server's persistent configuration are the responsibility of either the DomainController or the host's HostController.
* ServerController (standalone mode): Sole management point for a standalone AS 7 server instance.
* Internal implementation classes related to the protocol for communicating with the "controllers". These are not part of the API but need to be on the client classpath.
* On the server side, provide a straightforward mapping of the core detyped Java API to JMX. The intent is that most (hopefully all) attributes and operations exposed via the core API will be available via JMX.
* On the server side, provide a straightforward mapping of the core detyped Java API to REST. The intent is that most (hopefully all) attributes and operations exposed via the core API will be available via REST.
* Handle different types of management actions:* Reads of persistent configuration attributes
* Writes of persistent configuration attributes
* Reads of server level runtime state (i.e. metrics/statistics)
* Updates to server level runtime state that do not impact persistent configuration
* Discovery of what the manageable resources exposed by the system are, and what attributes and operations are supported by those resources.
* Provide clean handling for operations that inherently impact multiple servers (i.e. updates to the domain.xml configuration model and any host.xml configuration.) Allow the end user to specify how those changes are applied to various server groups and the servers within those groups in a "management operation plan". After the operation is executed, provide detailed information on how the operation was executed on the various controllers and servers involved.* For management operation plans involving updates to persistent configuration, the plan will include information on what should happen in case the update cannot be applied successfully to one or more servers; i.e. whether the update should be applied to other servers where it has not yet been attempted or rolled back on servers where it has successfully been applied.
* Hide some of the API complexity involved in the above by having a default update plan that concurrently applies the operation to all relevant server groups and all servers within the domain.
* Management operation plans should include support for multiple operations that update persistent configuration that are to be performed as an atomic unit.
* +TODO: is it necessary to support plans with multiple operations that are *not* atomic; i.e. where failure of one operation will not cause the others to be rolled back? We currently do, but this adds conceptual complexity and clutters the API a bit.
+
* Provide the ability to target operations that are not inherently multi-server in nature against a particular server. Such operations are:
* Reads of persistent configuration attributes
* Reads of server level runtime state (i.e. metrics/statistics)
* Updates to server level runtime state that do not impact persistent configuration
Other goals include:
* Support for notifications. The detyped Java management API should include a general mechanism by which managed resources can advertise the availability of notifications. The detyped Java API should include a generic mechanism by which clients register a listener for notifications. This implies a persistent connection between the client and the server.
* Ability to get progress events as multi-server operations are executed. Some operations may take a considerable amount of time to execute across the domain (e.g. a large, complex deployment applied to many servers); allowing callers to register a listener for progress events would be nice. The AS 7 Alpha1 domain deployment plan handling had a prototype of that kind of capability.
h3. MetaValues
Method parameters and return types in the detyped API are expressed in terms of a limited number of general purpose classes known as "MetaValues". The types of MetaValues are:
* SimpleValue -- a simple wrapper around one of a fixed list of JDK types (String, primitive wrapper types, Date, BigDecimal, BigInteger.
* ArrayValue -- an array of other meta values, all of which are of the same type.
* CollectionValue -- a collection of other meta values, all of which are of the same type.
* MapValue -- a Map<MetaValue,MetaValue>.
* CompositeValue -- a sort of Map<String, MetaValue> where the type of the MetaValue associated with a given key is fixed, but different keys can have values of different types. This type is used to model complex Java types, where each key/value pair in the map is analogous to a field in an ordinary Java type.
* TableMetaValue -- a table where each row is a CompositeValue with an identical mapping of allowed keys and value types. The table definition includes an ordered list of which which keys are "index fields". A particular CompositeValue can be retrieved from the table by providing a list of MetaValues, each of which corresponds to one field in the index.
In practice, the most commonly used types are SimpleValue, CollectionValue and CompositeValue.
h3. MetaTypes
A MetaValue includes a read-only property of type "MetaType". Accessing a MetaValue's MetaType allows the caller to determine information about the value's type, in an analogue to how using reflection can determine information about an ordinary java object. A MetaType can also be used to validate a MetaValue; i.e. the MetaType can check that the value's composition is consistent with the MetaType's definition.
+An important problem to solve is making MetaTypes easy to use for end users. See below for more on this issue.+
Each of the value types described above has a corresponding MetaType.
* SimpleValue exposes a SimpleMetaType. SimpleMetaType just exposes the class name of the wrapped value (java.lang.String, java.util.Date etc). There is a constant value (e.g. SimpleMetaType.STRING) for each of the legal types.
* CollectionMetaType exposes the (single) MetaType of the MetaValues that comprise a CollectionValue.
* ArrayMetaType exposes the (single) MetaType of the MetaValues that comprise an ArrayValue.
* CompositeMetaType defines what the valid keys are in a CompositeValue, as well as what the MetaType must be for each key's value. It also includes a text description of each key. (+Note: I think it should also expose whether a given key/value pair is optional.+)
* TableMetaType defines what the (single) CompositeMetaType is for the rows in a TableValue, along with what keys comprise the index.
As mentioned above, an important problem to solve is making MetaTypes easy to use for end users. There are a number of requirements that need to be met:
1. Every MetaValue emitted by the server must have a valid MetaType associated with it. Clients should be able to use the MetaType to introspect the value.
2. Clients should not have to have a reference to a MetaType in order to construct a MetaValue. For example, say a particular operation exposed by a managed resource takes a parameter named "socket" whose type is a CompositeValue, and that value's MetaType defines a key named "name" that requires a String value, a key named "port" that requires an int value and an optional (nillable) key named "properties" that requires a Map<String, String>. A client should be able to construct a valid value simply by indicating that a CompositeValue is needed and by assigning appropriate values to "name" and "port". They should not need to provide the MetaType. There are a couple possible ways this might be handled:1. Don't require MetaValue to expose MetaType. Have a separate interface/class hierarchy, e.g. TypedMetaValue that exposes the MetaType. Servers always produce TypedMetaValue's, but clients can construct objects of a simpler MetaValue class hierarchy that don't expose (or require) the MetaType. This approach is conceptually complex though and breaks down in cases like TableValue, whose semantics require type information.
2. Provide a sort of DSL/builder pattern to create MetaValues. The builder accumulates the information to create the MetaType at the same time it accumulates the information to compose the value. In the build() operation it actually constructs the MetaType and passes it to the constructor of the MetaValue. Emanuel Muckenhuber is exploring this approach.
3. Clients (and the server) should be able to validate MetaValues they create against the expected MetaType. This validation should not overly rely on an exact match of MetaTypes (e.g. value.getMetaType().equals(anotherMetaType)). It should account for the possibility that the value's MetaType may not include optional information. For example, a client may create a CompositeValue to act as the "socket" parameter described above. The MetaType for that CompositeValue may not include information about the optional "properties" key. A validation of that value against the full formal definition of the parameter should not fail, since "properties" is optional. A missing "name" however should result in a validation failure.
h3. Managed Resources
The API exposed by each controller (DomainController, HostController, domain-mode or standalone ServerController) is expressed in terms of attributes and operations exposed by a set of ManagedResources. A ManagedResource is conceptually similar to a JMX MBean, with the significant difference that ManagedResources are organized in a tree structure, whereas MBean need not have any inherent organization.
ManagedResources expose a set of read-only attributes and a set of operations. Attributes expose the persistent configuration of the resource. Operations can be read-only (e.g. a metric), write-only, or read-write. Unlike in JMX, attributes are not read-write. The value of some attributes may be mutable, but can only be mutated via an operation. (The operation to mutate attribute "foo" may be named "setFoo", but it's still an operation.) Attributes are not used for metrics; they are only used to represent the persistent configuration of the resource. Metrics are retrieved using operations. (The operation to retrieve a metric "threadCount" may be called "getThreadCount" and not take any parameters, but it is still an operation.)
Each resource also exposes meta-information about itself that clients can use to discover what attributes and operations are exposed by the resource. This meta-information is encapsulated in a ManagedResourceInfo object. A ManagedResourceInfo object is conceptually very similar to a javax.management.MBeanInfo.
ManagedResources are organized in a tree structure. Each ManagedResource (except root resources; see below) must expose an attribute whose value is of some SimpleMetaType that acts as the unique identifier for the resource compared to all similar resources under the resource's parent resource. (+TODO: consider requiring this value to be of SimpleMetaType.STRING.+) The name of this attribute is arbitrary. The name of the attribute must be exposed via the resource's ManagedResourceInfo object, via the getIdAttributeName() method.
Each controller (DomainController, HostController, domain-mode or standalone ServerController) is responsible for managing a resource tree. Each resource tree is rooted in a root ManagedResource. A ManagedResource exposes an isRoot()method that must return true for the root resource and false for all others. For a root resource, the ManagedResourceInfo.getIdAttributeName() method must return null, as a root resource does not require a unique identifier.
Besides attributes and operations, a ManagedResource offers a read-only view of the child resources organized under it in the tree. Child resources are organized by type, with all resources of a given type exposing ManagedResourceInfo objects that are equal to each other. For each child resource type, the parent resource maintains a simple string identifier that represents the collection of resources of that type. For example, a ManagedResource representing a JBoss Web web server subsystem might have child resources that represent JBoss Web connectors, and would use the string "connectors" as the identifier for that collection of resources.
The ManagedResourceInfo for a resource includes metadata about what types are child resources are available, what the name of the identifier is the parent uses for the collection of each type of child, and the cardinality of the relationship (typically 0..1 or 0..*). The lower limit *must be zero* otherwise a parent resource cannot exist without children, yet child resources cannot exist without a parent. (+TODO there may be ways around this if it proves to be a problem.+)
Adding and removing child resources is accomplished by invoking operations on the parent. (+TODO: another possibility is the (Domain/Host/Server)Controller API expose special "add" methods.+)
h4. Addressing a ManagedResource
>From the above, a fairly simple scheme for addressing any resource in the tree becomes apparent. An address for a resource is an array or List of simple string pairs. The first string in the pair is the identifier the parent uses for the collection of child resources of the child's type. The second string is the value of whatever attribute the child resource identifies as its "id attribute".
So, for example, the address of the resource representing an HTTP connector in the domain model might be expressed as:
{profiles/web},{subsystems/web},{connectors/http}
It's easy to see how that cold easily be mapped to a REST resource URL:
http://127.0.0.1/domain/profiles/web/subsystems/web/connectors/http (http://some.host.com/domain/profiles/web/subsystems/web/connectors/http)
It also maps readily to a JMX ObjectName, where each ManagedResource is exposed in JMX as an MBean:
jboss.as.domain:profiles=web,subsystems=web,connectors=http
A not so nice thing in the above is an English issue where the plural form of a property name is not the same as its singular form, and in some contexts the singular form is more natural, e.g. in a key/value pair
jboss.as.domain:profile=web,subsystem=web,connector=http
There are a couple possibilities here; one is to always use the singular form, on the theory that a singular form in a REST URL is less unnatural than a plural form in an ObjectName. Another possibility is to have the ManagedResourceInfo metadata that describes the parent/child relationship include information about both the singular and plural forms. Different addressing systems would use the more "natural" form; parents can resolve children using either form.
h4. Client-side View of a ManagedResource
The management API provides a read-only view of the current state of a ManagedResource's attributes. This is via the ManagedResource class in the detyped API library. The ManagedResource class is simply another type of MetaValue. The ManagedResourceInfo object it exposes is another type of MetaType.
h3. Reading Attributes
Directly via *Controller API:
EntityAddress address = EntityAddress.fromString("profile/web/subsystem/web/connnector/http");
MetaValue m = domainController.getAttribute(address, "socket");
String socketName = (String) ((SimpleValue) m).getValue(); // yuck! how about SimpleMetaType.STRING.getValue(m);
(+TODO: quite likely EntityAddress can be replaced with a simple String+).
Indirectly via ManagedResource:
EntityAddress address = EntityAddress.fromString("profile/web/subsystem/web/connnector/http");
ManagedResource connector = domainController.getManagedResource(address);
MetaValue m = connector.getAttribute("socket");
String socketName = (String) ((SimpleValue) m).getValue(); // yuck! how about SimpleMetaType.STRING.getValue(m);
h3. Invoking Operations
The operations exposed by a resource are described in its ManagedResourceInfo, via the ManagedResourceOperationInfo objects returned by its getOperations() method. The main information provided by a ManagedResourceOperationInfo object is the name of the operation and a description of the metatype of the parameters the operation takes.
Invoking an operation consists of creating MetaValues for the parameters, and passing them, along with the name of the operation and the address of the target resource, to the invoke method.
EntityAddress address = EntityAddress.fromString("profile/web/subsystem/foobar");
MetaValue foo = createFooMetaValue();
MetaValue bar = createFooMetaValue();
domainController.invokeOnDomain("setFooBar", address, foo, bar);
(+TODO: clarify why I said "invokeOnDomain" above vs a more general "invoke" -- basically we need to distinguish operations that affect the domain, vs those that effect a single host, vs those that effect a single server, as the structure of the result varies. The "invokeOnDomain" is a nod in that direction.+)
The return type of the invocation depends on whether the operation targets the domain, a host or a single server. All operations have a core return type of some MetaValue; the MetaType of that MetaValue varies from one operation to another and is described in the ManagedResourceOperationInfo object that describes the operation. However, for operations that impact more than a single server, the core return value from each server needs to be encapsulated in a larger data structure that describes the overall impact of the operation across the domain.
For example, an operation that effects a domain level resource would be executed by the DomainController as follows:
* Handle the operation on the DomainController itself. For example, update the DC's copy of the domain configuration.
* Ask all registered HostControllers to handle the operation (e.g. update their copy of the domain configuration) and reply with the list of servers that would be affected by the operation.
* Execute tasks asking the HostControllers to instruct individual servers to execute the operation and reply with any return value.
As a result, the return value provided by the DC would need to include the following information:
* Failure information describing any failure to apply the operation on the domain controller. (TBD: just a String or some exception type. My inclination is to use a String, which loses stack trace information, but avoids all issues with server exception types leaking to the client. Stack traces can be logged on the server side, where they are more relevant.)
* Failure information describing any failure to roll back the operation on the domain controller. (The rollback would occur following a successful application on the DC, but a failure on a HostController or server.)
* Map<String, failure information> describing any failures to handle the operation on a HostController.
* Map<String, failure information> describing any failures to roll back the operation on a HostController. (The rollback would occur following a successful application on the HostController, but a failure on another HostController or a server.)
* Results by server
* Identity of the server* name
* host name (to allow correlation of results by host)
* server group name (to allow correlation of results by server group)
* Failure information describing any failure to handle the operation on the server
* Failure information describing any failure to roll back the operation on the server
* The return value of the operation.
A similar process applies to operations that affect a host's configuration. Return values would include:
* Failure information describing any failure to apply the operation on the HostController.
* Failure information describing any failure to roll back the operation on the HostController. (The rollback would occur following a successful application on the HostController, but a failure on a server.)
* Results by server
* Identity of the server* name
* host name (to allow correlation of results by host)
* server group name (to allow correlation of results by server group)
* Failure information describing any failure to handle the operation on the server
* Failure information describing any failure to roll back the operation on the server
* The return value of the operation.
An operation targetted at a single server would have a simpler return type:
* Failure information describing any failure to handle the operation on the server
* Failure information describing any failure to roll back the operation on the server
* The return value of the operation.
+TODO: decide how to represent all of the above. The domain-client module currently has a class for this for domain level deployment operations that could be adapted for general use. It can all be represented in a complex detyped object as well (CompositeValues and CollectionValues nested in other CompositeValues). That's painful for the end user, but reduces the number of client-side classes. For now the assumption is they will become complex detyped objects.+
h3. Management Operations Plans++
+TODO+
h3. Notifications++
+TODO
+
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16235]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
- 1
- 0
[JBoss AS7 Development] - JBoss Modules Surefire Plugin
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] modified the document:
"JBoss Modules Surefire Plugin"
To view the document, visit: http://community.jboss.org/docs/DOC-16240
--------------------------------------------------------------
This is a fork of org.apache.maven.plugins:maven-surefire-plugin:2.6:test.
h4. Configuration
It has the configuration options of the 'real' surefire plugin ( http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html), although your mileage may vary if you start playing with the fork modes. The plugin takes a module definition file and creates a directory structure containing modules in the jboss-modules format
It has the configuration options of the http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html original surefire plugin, although your mileage may vary if you start playing with the fork modes. The plugin takes a module definition file and creates a directory structure containing modules in the jboss-modules format.
For the forked module there are some more options for configuring the modules:
*roots:*
Points to a list of exisiting module root directories, such as jboss-as7/modules
* *Type:* java.io.File[]
* *Required:* No
*cleanModulesDirectory:*
If true (default) clean out the modules directory created by the plugin each time we run the tests.
* *Type:* boolean
* *Required:* No
* *Expression:* ${jboss.modules.clean}
* *Default:* true
*modulesDirectory:*
The absolute path of the modules output directory created from +*moduleDefinitionFile*+
* *Type:* java.io.File
* *Required:* No
* *Expression:* ${jboss.modules.directory}
* *Default:* ${project.build.directory}/modules
*logModule:*
The name of the -logmodule parameter passed in to JBoss Modules (i.e. the name of the module containg the jboss logmanager). This is needed if the target project uses java.util.Logging or jboss logging, and the jboss log manager is not on the system classpath.
* *Type:* java.lang.String
* *Required:* No
* *Expression:* ${jboss.modules.logmodule}
*logConfiguration:*
The JBoss logging configuration if any. This must be set if the target project uses jboss logging and you want any output to be displayed
* *Type:* java.io.File
* *Required:* No
* *Expression:* ${logging.configuration}
*moduleDefinitionFile:*
The path of the module definition file.
* Type java.io.File
* Required: Yes
* Expression: ${jboss.modules.definition}
* Default: ${project.build.testOutputDirectory}/modules/module-def.xml
In addition, when using jboss logging you will need to set the following system properties in your pom when using this plugin (full example later):
<systemProperties>
<property>
<name>java.util.logging.manager</name>
<value>org.jboss.logmanager.LogManager</value>
</property>
<property>
<name>jboss.home.dir</name>
<value>${jboss.home}</value>
</property>
<property>
<name>org.jboss.boot.log.file</name>
<value>${jboss.home}/standalone/log/boot.log</value>
</property>
</systemProperties>
*h4. Module Definition File
*
This sets up the modules used for running your tests, which are then copied to *+modulesDirectory+* from the plugin settings. The plugin automatically sets up a module called +jboss.surefire.module+ for you which contains the plugin classes, junit and your project's target/classes and target/test-classes directories. If you want to set up more modules you can define those in the *+moduleDefinitionFile+*. The schema is very simple, and rather than duplicating the work done by jboss-modules the validation of most of the stuff is delegated to jboss-modules when loading the modules. Here is an example:
<?xml version="1.0" encoding="UTF-8"?>
<modules xmlns="urn:jboss:surefire-module:1.0" targetNs="urn:jboss:module:1.0">
<test-module-dependencies>
<module name="org.jboss.as.standalone"/>
<module name="org.jboss.modules"/>
<module name="org.jboss.threads"/>
<module name="my.test.module"/>
</test-module-dependencies>
<module name="my.test.module">
<resources>
<resource-root path="$some.group:some-artifact$"/>
</resources>
</module>
</modules>
+targetNs+ is the schema of the targetted jboss-modules version.
+test-module-dependencies+ adds the listed dependencies to the +jboss.surefire.module+ module directly into the dependencies section of the created module. In this case we follow the jboss-modules 1.0 schema. In this case the +modulesDirectory+/jboss/surefire/module/main/module.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<module name="jboss.surefire.module" xmlns="urn:jboss:module:1.0">
<main-class name="org.apache.maven.surefire.booter.SurefireBooter"/>
<resources>
<resource-root path="surefire-api-2.6.jar"/>
<resource-root path="surefire-booter-1.0.0.Alpha1.jar"/>
<resource-root path="junit-4.8.1.jar"/>
<resource-root path="test-classes"/>
</resources>
<dependencies>
<module name="org.jboss.as.standalone"/>
<module name="org.jboss.modules"/>
<module name="org.jboss.threads"/>
<module name="org.jboss.threads"/>
</dependencies>
</module>
You can have as many +modules/module entries as you like and they just get copied across. The $some.group:some.artifact$+ value gets resolved from your project's dependencies into the path to that dependency in your local maven repository. In this case (assuming your pom has a dependency on some.group:some-artifact:1.3.0, which then gets copied from the local maven repository to the module directory) +modulesDirectory+/my/test/module/main/module.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<module name="my.test.module" xmlns="urn:jboss:module:1.0">
<resources>
<resource-root path="some-artifact-1.3.0.jar'/>
</resources>
</module>
h4. Consuming the plugin from a pom
Normally you want to turn off the normal surefire plugin since that does not understand modular classloading
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<!-- Disable the standard surefire plugin since that runs tests without modular classloading -->
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
Then enable and configure the jboss modules surefire plugin (${jboss.home} is configured elsewhere in the pom and points to a built JBoss AS 7 instance)
<plugin>
<groupId>org.jboss.maven.surefire.modular</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>1.0.0.Alpha1</version>
<executions>
<execution>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- standard surefire options -->
<redirectTestOutputToFile>true</redirectTestOutputToFile>
<enableAssertions>true</enableAssertions>
<systemProperties>
<property>
<name>java.util.logging.manager</name>
<value>org.jboss.logmanager.LogManager</value>
</property>
<property>
<name>jboss.home.dir</name>
<value>${jboss.home}</value>
</property>
<property>
<name>org.jboss.boot.log.file</name>
<value>${jboss.home}/standalone/log/boot.log</value>
</property>
</systemProperties>
<includes>
<include>org/jboss/as/test/surefire/**/*TestCase.java</include>
</includes>
<!-- Extra forked plugin options -->
<logModule>org.jboss.logmanager</logModule>
<logConfiguration>${jboss.home}/standalone/configuration/logging.properties</logConfiguration>
<roots>
<root>${jboss.home}/modules</root>
</roots>
</configuration>
</plugin>
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16240]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
- 1
- 0
[JBoss AS7 Development] - AS 7 "Detyped" Management API
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"AS 7 "Detyped" Management API"
To view the document, visit: http://community.jboss.org/docs/DOC-16235
--------------------------------------------------------------
This document is meant to describe the design of the management API of an AS 7 domain and of a single AS 7 server instance running in standalone mode.
The API is described as "detyped" to reflect the fact that the API only exposes a small number of types besides JDK classes.
The goals are to:
* Define a Java-based API that can be consumed by a remote java client that requires only a small number of types besides JDK classes to be on the client classpath. Any complex types involved in the API are expressed in terms of a fixed set of general purpose classes. The types needed on the client classpath are:* A library containing the small set of general purpose types (see discussion of MetaValue, MetaType below), plus some helper utilities (e.g. Builder classes) to assist in building up objects of those types.
* 4 interface classes, each of which describes the methods exposed by one of the server side "controllers". The parameters and return types in these interfaces should be expressed in terms of the general purpose types. The methods in these interfaces will be limited and general purpose in nature, i.e. there will not be a myriad of detailed methods like "setHttpPort(int port)". The 4 types of "controllers" are:* DomainController. Primary management point for an AS 7 domain. Responsible for all configurations in the domain.xml file. The DomainController is also intended to function as the central management point for all hosts and servers in the domain, delegating to internal APIs exposed by the HostControllers or ServerControllers as necessary. However, a running AS 7 domain does not require a running DomainController, so the HostControllers and ServerControllers will also expose a management API.
* HostController. Responsible for controlling one or more AS 7 server instances on a physical or virtual host. Responsible for all configurations in the host.xml file for that host. Will also expose some host-specific management operations, e.g. start/stop/restart a server.
* ServerController (domain mode): Provides a read-only view of an individual server's configuration. Provides access to any metrics exposed by the server. Provides access to any non-configuration-related management operations exposed by the server (e.g. remove message X from JMS queue Y.) Does not expose any ability to update the server's persistent configuration, as all aspects of a server's persistent configuration are the responsibility of either the DomainController or the host's HostController.
* ServerController (standalone mode): Sole management point for a standalone AS 7 server instance.
* Internal implementation classes related to the protocol for communicating with the "controllers". These are not part of the API but need to be on the client classpath.
* On the server side, provide a straightforward mapping of the core detyped Java API to JMX. The intent is that most (hopefully all) attributes and operations exposed via the core API will be available via JMX.
* On the server side, provide a straightforward mapping of the core detyped Java API to REST. The intent is that most (hopefully all) attributes and operations exposed via the core API will be available via REST.
* Handle different types of management actions:* Reads of persistent configuration attributes
* Writes of persistent configuration attributes
* Reads of server level runtime state (i.e. metrics/statistics)
* Updates to server level runtime state that do not impact persistent configuration
* Discovery of what the manageable resources exposed by the system are, and what attributes and operations are supported by those resources.
* Provide clean handling for operations that inherently impact multiple servers (i.e. updates to the domain.xml configuration model and any host.xml configuration.) Allow the end user to specify how those changes are applied to various server groups and the servers within those groups in a "management operation plan". After the operation is executed, provide detailed information on how the operation was executed on the various controllers and servers involved.* For management operation plans involving updates to persistent configuration, the plan will include information on what should happen in case the update cannot be applied successfully to one or more servers; i.e. whether the update should be applied to other servers where it has not yet been attempted or rolled back on servers where it has successfully been applied.
* Hide some of the API complexity involved in the above by having a default update plan that concurrently applies the operation to all relevant server groups and all servers within the domain.
* Management operation plans should include support for multiple operations that update persistent configuration that are to be performed as an atomic unit.
* +TODO: is it necessary to support plans with multiple operations that are *not* atomic; i.e. where failure of one operation will not cause the others to be rolled back? We currently do, but this adds conceptual complexity and clutters the API a bit.
+
* Provide the ability to target operations that are not inherently multi-server in nature against a particular server. Such operations are:
* Reads of persistent configuration attributes
* Reads of server level runtime state (i.e. metrics/statistics)
* Updates to server level runtime state that do not impact persistent configuration
Other goals include:
* Support for notifications. The detyped Java management API should include a general mechanism by which managed resources can advertise the availability of notifications. The detyped Java API should include a generic mechanism by which clients register a listener for notifications.
h3. MetaValues
Method parameters and return types in the detyped API are expressed in terms of a limited number of general purpose classes known as "MetaValues". The types of MetaValues are:
* SimpleValue -- a simple wrapper around one of a fixed list of JDK types (String, primitive wrapper types, Date, BigDecimal, BigInteger.
* ArrayValue -- an array of other meta values, all of which are of the same type.
* CollectionValue -- a collection of other meta values, all of which are of the same type.
* MapValue -- a Map<MetaValue,MetaValue>.
* CompositeValue -- a sort of Map<String, MetaValue> where the type of the MetaValue associated with a given key is fixed, but different keys can have values of different types. This type is used to model complex Java types, where each key/value pair in the map is analogous to a field in an ordinary Java type.
* TableMetaValue -- a table where each row is a CompositeValue with an identical mapping of allowed keys and value types. The table definition includes an ordered list of which which keys are "index fields". A particular CompositeValue can be retrieved from the table by providing a list of MetaValues, each of which corresponds to one field in the index.
In practice, the most commonly used types are SimpleValue, CollectionValue and CompositeValue.
h3. MetaTypes
A MetaValue includes a read-only property of type "MetaType". Accessing a MetaValue's MetaType allows the caller to determine information about the value's type, in an analogue to how using reflection can determine information about an ordinary java object. A MetaType can also be used to validate a MetaValue; i.e. the MetaType can check that the value's composition is consistent with the MetaType's definition.
+An important problem to solve is making MetaTypes easy to use for end users. See below for more on this issue.+
Each of the value types described above has a corresponding MetaType.
* SimpleValue exposes a SimpleMetaType. SimpleMetaType just exposes the class name of the wrapped value (java.lang.String, java.util.Date etc). There is a constant value (e.g. SimpleMetaType.STRING) for each of the legal types.
* CollectionMetaType exposes the (single) MetaType of the MetaValues that comprise a CollectionValue.
* ArrayMetaType exposes the (single) MetaType of the MetaValues that comprise an ArrayValue.
* CompositeMetaType defines what the valid keys are in a CompositeValue, as well as what the MetaType must be for each key's value. It also includes a text description of each key. (+Note: I think it should also expose whether a given key/value pair is optional.+)
* TableMetaType defines what the (single) CompositeMetaType is for the rows in a TableValue, along with what keys comprise the index.
As mentioned above, an important problem to solve is making MetaTypes easy to use for end users. There are a number of requirements that need to be met:
1. Every MetaValue emitted by the server must have a valid MetaType associated with it. Clients should be able to use the MetaType to introspect the value.
2. Clients should not have to have a reference to a MetaType in order to construct a MetaValue. For example, say a particular operation exposed by a managed resource takes a parameter named "socket" whose type is a CompositeValue, and that value's MetaType defines a key named "name" that requires a String value, a key named "port" that requires an int value and an optional (nillable) key named "properties" that requires a Map<String, String>. A client should be able to construct a valid value simply by indicating that a CompositeValue is needed and by assigning appropriate values to "name" and "port". They should not need to provide the MetaType. There are a couple possible ways this might be handled:1. Don't require MetaValue to expose MetaType. Have a separate interface/class hierarchy, e.g. TypedMetaValue that exposes the MetaType. Servers always produce TypedMetaValue's, but clients can construct objects of a simpler MetaValue class hierarchy that don't expose (or require) the MetaType. This approach is conceptually complex though and breaks down in cases like TableValue, whose semantics require type information.
2. Provide a sort of DSL/builder pattern to create MetaValues. The builder accumulates the information to create the MetaType at the same time it accumulates the information to compose the value. In the build() operation it actually constructs the MetaType and passes it to the constructor of the MetaValue. Emanuel Muckenhuber is exploring this approach.
3. Clients (and the server) should be able to validate MetaValues they create against the expected MetaType. This validation should not overly rely on an exact match of MetaTypes (e.g. value.getMetaType().equals(anotherMetaType)). It should account for the possibility that the value's MetaType may not include optional information. For example, a client may create a CompositeValue to act as the "socket" parameter described above. The MetaType for that CompositeValue may not include information about the optional "properties" key. A validation of that value against the full formal definition of the parameter should not fail, since "properties" is optional. A missing "name" however should result in a validation failure.
h3. Managed Resources
The API exposed by each controller (DomainController, HostController, domain-mode or standalone ServerController) is expressed in terms of attributes and operations exposed by a set of ManagedResources. A ManagedResource is conceptually similar to a JMX MBean, with the significant difference that ManagedResources are organized in a tree structure, whereas MBean need not have any inherent organization.
ManagedResources expose a set of read-only attributes and a set of operations. Attributes expose the persistent configuration of the resource. Operations can be read-only (e.g. a metric), write-only, or read-write. Unlike in JMX, attributes are not read-write. The value of some attributes may be mutable, but can only be mutated via an operation. (The operation to mutate attribute "foo" may be named "setFoo", but it's still an operation.) Attributes are not used for metrics; they are only used to represent the persistent configuration of the resource. Metrics are retrieved using operations. (The operation to retrieve a metric "threadCount" may be called "getThreadCount" and not take any parameters, but it is still an operation.)
Each resource also exposes meta-information about itself that clients can use to discover what attributes and operations are exposed by the resource. This meta-information is encapsulated in a ManagedResourceInfo object. A ManagedResourceInfo object is conceptually very similar to a javax.management.MBeanInfo.
ManagedResources are organized in a tree structure. Each ManagedResource (except root resources; see below) must expose an attribute whose value is of some SimpleMetaType that acts as the unique identifier for the resource compared to all similar resources under the resource's parent resource. (+TODO: consider requiring this value to be of SimpleMetaType.STRING.+) The name of this attribute is arbitrary. The name of the attribute must be exposed via the resource's ManagedResourceInfo object, via the getIdAttributeName() method.
Each controller (DomainController, HostController, domain-mode or standalone ServerController) is responsible for managing a resource tree. Each resource tree is rooted in a root ManagedResource. A ManagedResource exposes an isRoot()method that must return true for the root resource and false for all others. For a root resource, the ManagedResourceInfo.getIdAttributeName() method must return null, as a root resource does not require a unique identifier.
Besides attributes and operations, a ManagedResource offers a read-only view of the child resources organized under it in the tree. Child resources are organized by type, with all resources of a given type exposing ManagedResourceInfo objects that are equal to each other. For each child resource type, the parent resource maintains a simple string identifier that represents the collection of resources of that type. For example, a ManagedResource representing a JBoss Web web server subsystem might have child resources that represent JBoss Web connectors, and would use the string "connectors" as the identifier for that collection of resources.
The ManagedResourceInfo for a resource includes metadata about what types are child resources are available, what the name of the identifier is the parent uses for the collection of each type of child, and the cardinality of the relationship (typically 0..1 or 0..*). The lower limit *must be zero* otherwise a parent resource cannot exist without children, yet child resources cannot exist without a parent. (+TODO there may be ways around this if it proves to be a problem.+)
Adding and removing child resources is accomplished by invoking operations on the parent. (+TODO: another possibility is the (Domain/Host/Server)Controller API expose special "add" methods.+)
h4. Addressing a ManagedResource
>From the above, a fairly simple scheme for addressing any resource in the tree becomes apparent. An address for a resource is an array or List of simple string pairs. The first string in the pair is the identifier the parent uses for the collection of child resources of the child's type. The second string is the value of whatever attribute the child resource identifies as its "id attribute".
So, for example, the address of the resource representing an HTTP connector in the domain model might be expressed as:
{profiles/web},{subsystems/web},{connectors/http}
It's easy to see how that cold easily be mapped to a REST resource URL:
http://127.0.0.1/domain/profiles/web/subsystems/web/connectors/http (http://some.host.com/domain/profiles/web/subsystems/web/connectors/http)
It also maps readily to a JMX ObjectName, where each ManagedResource is exposed in JMX as an MBean:
jboss.as.domain:profiles=web,subsystems=web,connectors=http
A not so nice thing in the above is an English issue where the plural form of a property name is not the same as its singular form, and in some contexts the singular form is more natural, e.g. in a key/value pair
jboss.as.domain:profile=web,subsystem=web,connector=http
There are a couple possibilities here; one is to always use the singular form, on the theory that a singular form in a REST URL is less unnatural than a plural form in an ObjectName. Another possibility is to have the ManagedResourceInfo metadata that describes the parent/child relationship include information about both the singular and plural forms. Different addressing systems would use the more "natural" form; parents can resolve children using either form.
h4. Client-side View of a ManagedResource
The management API provides a read-only view of the current state of a ManagedResource's attributes. This is via the ManagedResource class in the detyped API library. The ManagedResource class is simply another type of MetaValue. The ManagedResourceInfo object it exposes is another type of MetaType.
h3. Reading Attributes
Directly via *Controller API:
EntityAddress address = EntityAddress.fromString("profile/web/subsystem/web/connnector/http");
MetaValue m = domainController.getAttribute(address, "socket");
String socketName = (String) ((SimpleValue) m).getValue(); // yuck! how about SimpleMetaType.STRING.getValue(m);
(+TODO: quite likely EntityAddress can be replaced with a simple String+).
Indirectly via ManagedResource:
EntityAddress address = EntityAddress.fromString("profile/web/subsystem/web/connnector/http");
ManagedResource connector = domainController.getManagedResource(address);
MetaValue m = connector.getAttribute("socket");
String socketName = (String) ((SimpleValue) m).getValue(); // yuck! how about SimpleMetaType.STRING.getValue(m);
h3. Invoking Operations
The operations exposed by a resource are described in its ManagedResourceInfo, via the ManagedResourceOperationInfo objects returned by its getOperations() method. The main information provided by a ManagedResourceOperationInfo object is the name of the operation and a description of the metatype of the parameters the operation takes.
Invoking an operation consists of creating MetaValues for the parameters, and passing them, along with the name of the operation and the address of the target resource, to the invoke method.
EntityAddress address = EntityAddress.fromString("profile/web/subsystem/foobar");
MetaValue foo = createFooMetaValue();
MetaValue bar = createFooMetaValue();
domainController.invoke("
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16235]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
- 1
- 0
[JBoss Web Development] - JASYPT integration with JBOSS 5.1 Authentication
by Nishern Govender
Nishern Govender [http://community.jboss.org/people/nishern] created the discussion
"JASYPT integration with JBOSS 5.1 Authentication"
To view the discussion, visit: http://community.jboss.org/message/576913#576913
--------------------------------------------------------------
Hi,
Is there a way to integrate JASYPT with the Authentication part of JAAS, on JBoss 5.1 (without using Spring or any other frame work).
I basically want to use the encryption and salting features from JASYPT for user passwords on login.
Thanks,
Nish
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/576913#576913]
Start a new discussion in JBoss Web Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
- 1
- 0