Denied to access admin web console of EAP6 after removing server-groups
by Claudio Miranda
Hi, related to HAL-336
The class org.jboss.as.console.client.core.bootstrap.LoadMainApp,
method execute() has the following
if(!bootstrapContext.isStandalone()
&& (bootstrapContext.isGroupManagementDisabled() ||
bootstrapContext.isHostManagementDisabled())
)
{
new InsufficientPrivileges().execute();
Just out of curiosity, I set the
bootstrapContext.setGroupManagementDisabled(false) and everything
worked fine on the surface. I was able to add a server group and
server configuration.
What are the consequences if the
bootstrapContext.isGroupManagementDisabled() is removed from above
condition ?
Regards
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
10 years, 11 months
New JNDI-based remote service API (for EJB etc.)
by David M. Lloyd
We've been having some discussions around improving the way that the EJB
invocation API looks, feels, and behaves to produce smaller, simpler,
and perhaps more "expected" code for more common cases. I'm going to
outline some of the design points here so that everyone knows what's
coming and has a chance to ask questions.
Part 1: JNDI API
----------------
Right now connection management is accomplished via a mishmash of APIs
from different client libraries. In most cases the connections are
automatically "managed", but in different ways, and such that each
client really cannot interact with each other.
From the user's perspective, this is really not desirable. Most users
are, for better or worse, expecting to use an API like JNDI to establish
and maintain their connection to the remote system. So the first idea
here is to encapsulate all common Remoting-based services into a single
JNDI context. The user should be able to do something like this:
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "remote+http://myserver.com:8080");
...couple other properties here...
InitialContext c = new InitialContext(env);
Now 'c' is a useful server connection that can be used for various
services. These services would include remote transaction control:
UserTransaction ut = (UserTransaction) c.lookup("UserTransaction");
Remote authentication/authorization:
SomeLoginContextLike lc = (...) c.lookup("AuthenticationService");
lc.login(subject, ...);
subject.doAs(...{
...do stuff...
});
Remote JNDI:
Context rc = (Context) c.lookup("RemoteNaming");
And of course EJBs:
MyEJBRemote rem = (MyEJBRemote)
c.lookup("EJB/MyApp/MyModule/MyEJB!com.mycom.MyEJB");
Please note that none of these JNDI names or APIs are final, just examples.
Once these services use a common infrastructure, a couple of things
become possible:
1) The services shared among a connection can work together more
effectively; for example, a UserTransaction can encapsulate all services
running over that connection, rather than just EJBs. Likewise for the
upcoming authentication service.
2) This API can be expanded to cover transport protocols other than
Remoting-based protocols for use cases in which a single persistent
connection is not the best option.
Part 2: Connection Management
-----------------------------
By using a URI as the connection destination, we can have one unified
configuration infrastructure for connection establishment. We can also
potentially cache and reuse connections with the same URI. In this
case, the user would not need to close the initial context; it could be
maintained indefinitely or closed after a configurable "idle" interval.
Configuration could be set up in a properties file for simple clients.
However there will also (often) be cases where the user simply wants to
establish a connection programmatically in the InitialContext
environment. To support this use case, a context will also be able to
be configured in this way (though there is still a little bit of
figuring out to do to work out a way that won't result in weird behavior
if this method is used when there is also an external configuration).
Part 3: Connection Authentication
---------------------------------
In order for connection reuse to work in the presence of multiple
identities (and make various other things nicer, as an aside), we need
to create a separate concept of connection authentication, to avoid the
situation where we ask for a connection as user A and get user B's
connection instead, or a situation where a user feels they must make one
connection per identity. Thus we need a separate client authentication
context and configuration method to determine the client authentication
method and credentials to use for the connection itself.
Once a connection is established, the authentication service on that
connection can be used to switch between authenticated identities. The
connection itself need only authenticate to an identity which has
adequate authorization to switch to, or authenticate as, those
identities. On the other hand, for simple cases, the client might only
need one identity: in this case the authentication service need not be
used; instead the client authentication context would be set up to
authenticate the desired user from the outset, and no other identity
would be established during its usage.
To switch identities, the user would have to acquire some type of
JAAS-like login context and authenticate a JAAS-like subject with it.
Then the user would use a typical "doAs"-style construct to perform some
body of work as that identity. This will be the subject (!) of a
different email.
Again, there will be cases where an external configuration for this
purpose will be too heavy-handed for the specific use case; in this case
we should allow an environment-based configuration mode.
Part 4: EJB Proxy Behavior
--------------------------
An EJB proxy which was acquired from this sort of connection can attain
an association to the remote system by URI. The identifying
characteristic of the proxy would then be: view type, URI, application
name, module name, EJB name. The 'distinct name' concept will no longer
be necessary and could possibly be deprecated if there is no remaining
use case for it.
The URI is significant primarily when the proxy is realized in a new
context. When the proxy is invoked upon for the first time, it must be
associated with a connection to the target system. The information in
the URI must therefore be sufficient to establish such a connection and
register it with the connection cache in order to allow such proxies to
be useful.
This is simple in the case of a URL; if a proxy is deserialized in an
unknown context, the URL plus any environment security settings may be
used to establish a new connection to allow the proxy to be invoked upon
again automatically (without compromising security in any way).
However on the negative side, if a URL is used for the URI, the URL may
not be valid after deserialization across certain types of NAT
configuration. This is a very real problem in some environments. In
order to mitigate this problem, a discovery mechanism is introduced.
Part 5: Discovery
-----------------
It will be possible for more advanced environments to utilize a URN
instead of a URL for connection establishment. The benefit of doing
this is that the URN given can be resolved in a location-specific
manner. A proxy with a URN of, say, "node:usa-1" might use a discovery
protocol to locate a node named "usa-1", find a URL that can be used to
connect, and establish and maintain the connection automatically. An
EJB proxy associated with this URN may be serialized and deserialized in
a completely different network environment, and the URN may still be
used (but resolved in a different manner) allowing the proxy (and its
connection) to continue to function.
The discovery mechanism should be pluggable to allow support for cloud
environments and potentially the Service Location Protocol (SLP, RFC
2608) for data center environments. Other schemes may be introduced
which do simple name-to-DNS-name mappings or other such simple schemes.
Part 6: Compatibility
---------------------
EJB Proxies acquired using the existing AS 7/WildFly 8 EJB API should
map the EJB locator information to a locator which is compatible with
the URI scheme given here, and vice versa, so that there is a seamless
migration path between old and new location schemes.
The wire protocol should also be made compatible so that old clients
will continue to function against new servers (and the reverse as well,
if possible).
--
- DML
10 years, 12 months
HC and server addresses
by Claudio Miranda
Hi, I was looking for a way to get the HC and server instance ip
address, using the management api.
The server is started as
./domain.sh -b pavlov-0 -bmanagement pavlov-0
-Djboss.domain.base.dir=../lab1-dc
-Djboss.domain.master.address=pavlov-0
I found out the following command
/host=master/core-service=host-environment:read-resource(include-runtime=true,recursive=true,include-defaults=true,include-aliases=true)
The output
{
"outcome" => "success",
"result" => {
"backup-domain-files" => false,
"default-jvm" => "/opt/javavm/bin/java",
"domain-base-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc",
"domain-config-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/configuration",
"domain-config-file" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/lab1-dc/configuration/domain.xml",
"domain-content-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/data/content",
"domain-data-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/data",
"domain-log-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/log",
"domain-servers-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/servers",
"domain-temp-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/../lab1-dc/tmp",
"home-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT",
"host-config-file" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/lab1-dc/configuration/host.xml",
"host-controller-address" => "/127.0.0.1",
"host-controller-port" => 0,
"host-name" => "pavlov",
"initial-running-mode" => "NORMAL",
"is-restart" => false,
"modules-dir" =>
"/home/claudio/alphaworks/projects/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT/modules",
"process-controller-address" => "/127.0.0.1",
"process-controller-port" => 51798,
"qualified-host-name" => "pavlov",
"use-cached-dc" => false
}
}
Looking at the java properties,
jboss.bind.address = pavlov-0
jboss.domain.master.address = pavlov-0
jboss.bind.address.management = pavlov-0
Does the "host-controller-address" property should be pavlov-0 and
"host-controller-port" equal to 9999 ?
Also the "qualified-host-name" and "host-name" equals to pavlov-0 ?
Regards
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
10 years, 12 months
Deploying app on managed domain
by Arun Gupta
I started bin/standalone.sh, deployed a WAR file (name is
http-1.0-SNAPSHOT.war) with just one index.jsp. Accessing
localhost:8080/http shows the expected results. Tried the same with
bin/domain.sh but now localhost:8080/http is giving a 404.
What are the port number of the servers started in this managed domain
? Is Ports +0 and +150 in admin console trying to display that
information ? If yes, then that is not very intuitive and the exact
value of the port should be displayed. If not, what are these values ?
Should this app be accessible on localhost:8080 ?
Tried enabling the app from admin console and got the error:
Failed to enable http-1.0-SNAPSHOT.war.
Unexpected HTTP response: 500
Request
{
"address" => [("deployment" => "http-1.0-SNAPSHOT.war")],
"operation" => "deploy"
}
Response
Internal Server Error
{
"outcome" => "failed",
"failure-description" => "JBAS014884: No operation named 'deploy'
exists at address [(\"deployment\" => \"http-1.0-SNAPSHOT.war\")]",
"rolled-back" => true
}
Is this the correct way to deploy the app on managed domain ?
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
10 years, 12 months
Submitted PR to HAL
by Claudio Miranda
Hi, just to let you know, I submitted a PR to HAL
https://github.com/hal/core/pull/10
They are small enhancements accordingly to
https://issues.jboss.org/browse/HAL-265
The contributions are:
* case insensitive filter and filter for text in the middle for:
environment properties and deployed applications
* test datasource connection for domain mode (it is in runtime -> datasource)
* flush connection for domain mode (it is in runtime -> datasource)
* added help text to ctrl+click assign deployment to multiple groups
Regards
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
10 years, 12 months
(Maven) Modules in Arquillian directory
by Karel Piwko
Hi All,
while focusing on WFLY-2441, I've noticed that only 10 out of 12 modules are
built from Arquillian directory. The rest seem to be some unused code. As my
favorite programming key is 'Del', is there any reason why to keep code that
is very like not used anywhere in the repository, confusing the people?
Namely, it is:
* protocol-servlet
* processor-jsfunit
I can create a JIRA and file a PR if agreed.
Thanks,
Karel
10 years, 12 months
