as7 quickstarts license
by Scott Stark
I noticed the quickstarts:
https://github.com/jbossas/quickstart
don't have any license information. I would assume these should all be
ASLv2 the same as CDI?
I would like to go through these and add the license, so if it is
something other than ASLv2, let me know.
14 years, 10 months
AS7 Utility Script Location
by Darran Lofthouse
As we are progressing the AS7 development more scripts need to be added
to be executed for the end users to use, if we keep adding these to the
bin folder it is potentially getting more and more confusing for end
users to know where to start after unzipping their AS install.
So far we have a group of scripts for JBossWS, Anil is about to add
something to operate in the vault he is providing, I am about to add
something for generating the pre-hashed passwords for the Digest
mechanisms used for domain management and finally we have the CLI.
Any objections / alternative ideas to us adding a util folder to the bin
folder to hold all of these utility scripts?
Regards,
Darran Lofthouse.
14 years, 10 months
Need to restore a page of the Wiki
by Misty Stanley-Jones
I wrote up the "What are RESTful services" section on this page, which has now been deleted: https://docs.jboss.org/author/display/AS7/Java+API+for+RESTful+Web+Servic...
I understand that the docs were restructured, but i wasn't aware of it when I did this (on Friday Brisbane time), and I do not have another copy of the work. I did this on my own time, and if there is any way to get it restored, at least so that someone can copy&paste the text to me so I can put it on the proper page, that would be awesome! Thanks.
--
Misty Stanley-Jones, RHCE
Content Author, ECS Brisbane
☺: misty (Freenode IRC) ✉: misty(a)redhat.com ☏: +61 7 3514 8105 ☏: 88105
14 years, 10 months
Confusion with arguments for domain.sh, domain controller vs. process controller
by Rostislav Svoboda
Hi Brian.
****** Arguments for domain.sh command
I have problem to understand some arguments for domain.sh command:
--pc-address=<address> Address of process controller socket
--pc-port=<port> Port of process controller socket
--interprocess-name=<proc> Name of this process, used to register the socket with the server in the process controller
--interprocess-hc-address=<address> Address this host controller's socket should listen onr
--interprocess-hc-port=<port> Port of this host controller's socket should listen on
For example --pc-address and --pc-port are dynamically generated for host-controller process and when I run for example ./bin/domain.sh --pc-port 50123 I receive java.net.ConnectException: Connection refused.
Are these options really meant to be public? Could you please provide use cases when it's beneficial to use them? There is no information on https://docs.jboss.org/author/display/AS7/.
****** Domain Controller vs. Process Controller
When I start domain.sh command, 4 new java processes are crated.
[rsvoboda@rosta-ntb jboss-as7]$ ps aux | grep java
1) Process containing 'org.jboss.as.process-controller' - this seems to be the main process.
I'm using Domain Controller term when speaking about main process. Is Process Controller equivalent to Domain Controller?
Logging+configuration are speaking about Process Controller.
Getting+started+with+JBoss+AS is speaking about Domain Controller.
Getting+Started+Guide is speaking about both Domain and Process Controller.
2) Process containing 'org.jboss.as.host-controller' - process for host controller
Just occurred to me - Isn't Host Controller on main instance called Domain Controller and Process Controller is only a glue?
This process has defined '--pc-address rosta-ntb --pc-port 34876' and it seems it can't be overridden as mentioned before.
3+4) 2 process for server-one and server-two.
Maybe adding description of java processes to the Admin Guide would be nice.
Thanks,
Rosta
14 years, 10 months
transaction integration
by Jonathan Halliday
I've recently created a bunch of JIRAs for the simpler bits of the
transaction integration work. However, there are some design issues that
need discussion before the work can be codified into JIRAs...
First up, distributed transactions. By that I mean ones involving
business logic in more that one JVM. The simpler case of 'distributed'
in the multiple resource manager sense already more or less works.
The transaction system can run in two modes - jta, which does not
support transactions spanning multiple jvms, or jts, which does.
Right now the AS decides which mode to boot depending on the presence of
an ORB, since that is used as the transport for distributed transaction
coordination. This is itself potentially a problem, since it's possible
that a user wants the ORB for non-transaction use only and does not want
to pay the performance penalty for running jts mode transactions that
never actually leave the local jvm. Even for local use the jts is
substantially slower than jta. So, you may want to consider allowing the
currently automated jta/jts choice to be overridden by the user. Another
interesting possibility is to use the module system to run two isolated
copies of the transaciton engine, one in jta and one in jts mode, then
allow applications to determine which they want and bind the JNDI
lookups accordingly. But I digress.
There is an interdependency between the ORB and the transaction system,
in that the ORB runs a set of iniializers at startup and when the jts is
enabled these must include the jts service inializers. However, the
transaction system depends on the ORB... (AS7-1494)
Assuming the user does require distributed transactions and the server
is running magically running with the jts enabled, we come to the
problem of distributed transaction boundary demarcation and context
propagation.
Whilst the transaction control traffic always runs over CORBA, the
business logic, typically EJB calls, may not. As far as I can tell
there is as yet no spec or documentation on what we intend to support
here or how tx context propagation and inflow is intended to work.
There is also the question of the extent to which we'll support tx use
by external or legacy clients, be they Java or CORBA. i.e. client to
server or server to older server, rather than between two AS7 instances.
The ClientUserTransaction proxy arrangement in the old AS pre-dated
the jts integration and never worked cleanly with it. We need to come up
with something better.
Who is handling the requirements and design for this in AS7?
Thanks
Jonathan.
--
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)
14 years, 10 months
-preview.xml configuration files removed in AS 7.1.0 final ?
by Francesco Marchioni
Dear devs,
I just wondered if in the AS 7.1.0 Alpha || Beta || Final the preview
configuration files will be merged into the main standalone.xml/domain.xml
file,
or they will just stay there to provide a "smaller" application server
configuration ?
Thanks in advance
Francesco
14 years, 10 months
Status 2011-09-19
by Kabir Khan
Last week:
Add basic subsystem tests to all subsystems. Where they do not pass validation, disable it and open a JIRA asigned to the subsystem lead.
Basic test to validate description providers for non-subsystem parts of the model.
Read only attributes and ops for JMX when running in domain mode, opened pull request.
Attempted to reproduce problem accessing remoting too early from tests which
This week:
Bad start to week - got wrist problems so am having today off, have mailed Bruno/Jason/Brian with more info
Refactor the subsystem tests to be able to have operation validation for non-subsystem parts of the model
Hopefully get started with https://issues.jboss.org/browse/AS7-842
14 years, 10 months
7.0.2 Pre-Release Tag
by Jason T. Greene
In preparation of 7.0.2 I have created a pre release tag here:
https://github.com/jbossas/jboss-as/tree/7.0.2.Final-prerelease
Note that it excludes most of the management refactors that have been
taking place in master.
Please test it out and raise the red flag if you see a critical issue!
Thanks!
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
14 years, 10 months
i18n Logging ID's and Levels
by James Perkins
I'd like to open a discussion on which messages should get logging id's
and which level some messages should be logged at.
ID's:
I previously stated in another email that all logging levels of INFO or
higher should get a logging id, but should they? Do we need an id for
"Server is started"?
Logging Levels:
We need to come up with some standard levels for logged messages. For
example "Starting subsystem xxx" seems to be a DEBUG level on some
subsystems, an INFO level on some and others don't even log the message
at all.
Any other additional questions and/or thoughts?
--
James R. Perkins
JBoss by Red Hat
14 years, 10 months
Graceful Shutdown
by David M. Lloyd
We've worked out the rough outline of how graceful shutdown will work in
AS7.
The process of graceful shutdown actually is reflected by a number of
states:
1. Running - all services acting normally
2. Suspending - services refuse new "permits" (see below), existing
permits are allowed to be retained (and threads running under such a
permit may still acquire new permits)
3. Suspended - no permits are present and none may be issued
4. Shutting Down - our existing server stop process
The following transitions are allowed:
1. Running → Suspending: Transition occurs at user request (to suspend
or gracefully shut down).
2. Suspending → Suspended: Transition occurs when all permits are cleared.
3. Suspending → Running: Transition occurs at user request (to exit
suspend mode or cancel graceful shutdown before it completes).
4. Suspended → Running: Transition occurs at user request (to exit
suspend mode).
5. Suspended → Shutting Down: Transition occurs automatically (if a
graceful shutdown was requested) or at user request (if a shut down
request of any kind is entered in the Suspended state).
6. Running → Shutting Down: Transition occurs at user request (to shut
down the server "un-gracefully").
These "permits" are issued by the "Shutdown Manager", whose job is to
manage these states. They are issued corresponding to the following events:
1. The invocation of an EJB method
2. The creation of a web session
3. A creation of a transaction
4. Probably some situations involving HQ and/or JCA
When a permit cannot be issued due to the server shutting down, a
standard exception message should be produced so that the user can see a
familiar error message regardless of what mechanism is used to access
the server.
--
- DML
14 years, 10 months
