Terminology: "Managed Domain" and "Standalone Server"
by Heiko Braun
I stumble across these terms constantly. Sometimes referred to as "domain" and "standalone" mode.
In an attempt to nail down the terminology that will be used in the future (blogs, wiki, docs, etc),
I would suggest we refer to:
- "Management Domain" or "Managed Domain"
- "Standalone Server"
Ike
12 years, 10 months
Smoke test failure
by Sebastian Otaegui
Hello,
I have setup a hudson to build as7 and for some reason the smoke tests
module fails four of the tests with this errors in this link.
https://gist.github.com/1030599
Here is the test report:
http://ci.feniix-hq.net/job/jboss-as-7.0.0/org.jboss.as$jboss-as-testsuit...
Any idea what am I doing wrong?
I get the same error if I do the build manually in my workstation (running
linux 64bits).
Thanks in advance
--
Those who do not understand Unix are condemned to reinvent it, poorly.
Any sufficiently recent Microsoft OS contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Unix.
12 years, 10 months
Root Context for http-interface
by Darran Lofthouse
Do we want to do anything about requests to the root context of the
http-interface?
Would only take a few lines to add a redirect to /console or adding the
welcome-contents would not take much.
At the moment http://localhost:9990/ just reports "404 Not Found".
Regards,
Darran Lofthouse.
12 years, 10 months
missing arquillian dependency
by Bill Burke
I'm trying to build from git://github.com/jbossas/jboss-as.git
[ERROR] Failed to execute goal on project
jboss-as-arquillian-container-managed: Could not resolve dependencies
for project
org.jboss.as:jboss-as-arquillian-container-managed:jar:7.0.0.Beta4-SNAPSHOT:
Failed to collect dependencies for
[org.jboss.as:jboss-as-arquillian-common:jar:7.0.0.Beta4-SNAPSHOT
(compile),
org.jboss.as:jboss-as-arquillian-protocol-jmx:jar:7.0.0.Beta4-SNAPSHOT
(compile),
org.jboss.arquillian.junit:arquillian-junit-container:jar:1.0.0.Beta2
(compile),
org.jboss.arquillian.junit:arquillian-junit-core:jar:1.0.0.Beta2
(compile), javax.inject:javax.inject:jar:1 (compile),
org.jboss.arquillian.core:arquillian-core-api:jar:1.0.0.Beta2 (compile),
junit:junit:jar:4.8.2 (test),
org.jboss.as:jboss-as-build-config:jar:7.0.0.Beta4-SNAPSHOT (compile)]:
Failed to read artifact descriptor for
org.jboss.arquillian.junit:arquillian-junit-container:jar:1.0.0.Beta2:
Could not transfer artifact
org.jboss.arquillian.junit:arquillian-junit-container:pom:1.0.0.Beta2
from/to jboss-public-repository-group
(http://repository.jboss.org/nexus/content/groups/public/): Error
transferring file: Connection refused -> [Help 1]
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 10 months
Renaming the http api endpoint
by Heiko Braun
IMO, the HTTP API endpoint (read "web context") should renamed to "http-api" or "detyped-api".
The current context name "domain-api" doesn't make sense in standalone mode.
I know, it's pedantic. Bare with me, I am german.
Ike
12 years, 10 months
AS7-1018, Allow TM to run in local only recover mode; discussion
by Scott Stark
I have the ability to disable the remote interfaces to the recovery
manager working in the following pull request:
https://github.com/jbossas/jboss-as/pull/58
In this request I raise the question of whether the current
configuration is too low level in that it is largely a mapping of the tm
configuration beans, and it takes a combination of two properties to
achieve the result of disabling the recovery manager remote interfaces.
Perhaps just a single enable-remote-access on the recovery-environment
that sets appropriate properties on the underlying
RecoveryEnvironmentBean and CoordinatorEnvironmentBean would be a better
solution.
12 years, 10 months
Documentation scope
by Heiko Braun
Since we cannot list every nitty gritty subsystem configuration option in the admin guide,
I am looking for a reasonable way to split the documentation for high level admin tasks
(i.e. datasource, queues, logging, security, etc) from the low level runtime component configuration options.
One way would be to simply reference the schema and documentation URL for anything that goes beyond
the admin guide contents. But in order for this to be successful, we would need a single place to access
both the AS7 config schema for a subsystem and (if it exists) the projects reference documentation.
What do you guys think?
Does it make sense?
Ike
12 years, 10 months
jboss_7.0.xsd
by Heiko Braun
hbraun:does anyone know where people should get the jboss_7_0.xsd?
[11:52am]hbraun:will it be shipped with the download?
12 years, 10 months
can we align the name of the sample datasource?
by Dan Allen
Can we include a sample datasource named jdbc/sample so that it's possible
to deploy the same example application to JBoss AS and GlassFish without any
other configuration? This is a constant headache for creating quickstart
applications and we have the opportunity to close the gap.
Here's the gap we've been juggling:
JBoss AS < 7: java:/DefaultDS
GlassFish 3: jdbc/__default and jdbc/sample
I believe that in general, the EE spec should strongly recommend (though I
doubt it can require) that the application server provide an sample database
for the purpose of tutorials. We have the opportunity to take a step towards
to realize this goal and standardize on jdbc/sample.
I know this seems trivial, but trust me, it makes a huge difference to help
bring new users on board. They are forced to deal with datasources before
they can learn anything else.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
12 years, 10 months
