EE JNDI services
by David M. Lloyd
I've been working on getting EE JNDI services organized in a
spec-consistent (and start-order-consistent) manner. The first part of
this effort - dividing the EE component service itself into two phases -
was relatively simple and is now complete; however it appears that our
JNDI services are not entirely prepared for this organizational change.
I've attached a diagram which illustrates the desired service layout
for EE components which covers injection and start order, and should be
cycle-proof (we'll know for sure once we implement EJB "eager" singletons).
Anyway please review the graph and let me know if there are any
questions, especially if I've missed any cases, and in the meantime I'll
be working on getting the deployers straightened out. The arrow means
"depends-on".
Some important facts not depicted:
- Components (as can be seen from the graph) are bound into JNDI
possibly before they are started; however attempting to create a new
component instance will block until the "START" phase is complete (note
that for some component types, you can acquire a client proxy without
actually causing instantiation to occur).
- The service naming scheme is not final, especially for JNDI contexts.
- Note that not all env. entries necessarily imply injection; it is also
possible to specify immediate values in the deployment descriptor. To
achieve this in MSC, the env. entry service should have an Injector
which can be immediate for descriptor-provided (or defaulted) values or
it can be a dependency for lookup values.
- Note that all inter-component dependencies are expressed upon JNDI
bindings (jboss.naming.context.* services), not on the actual components
(jboss.deployment.unit.*.component.* services).
--
- DML
13 years, 3 months
Cryptic Error Messages
by Darran Lofthouse
Do we have any plans to capture cryptic error messages experienced while
working with AS7 so we can review if there are better ways the problem
can be reported?
Over the past week I have experienced the two errors at the end of this
e-mail.
The first of these errors was reported because a subsystem had not read
all of it's configuration but the reported error gives the impression
there may be a problem with the actual XML.
The second error although claiming an extension could not be found was
actually because the extension could not be loaded as the module
containing a class used by the extension was not referenced from the
module.xml.
Regards,
Darran Lofthouse.
===== 1 =====
Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[142,91]
Message: Unexpected element '{urn:jboss:domain:osgi:1.0}configuration'
encountered
at
org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:61)
at
org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:383)
===== 2 =====
10:35:08,866 ERROR [org.jboss.msc] MSC-00001: Failed to start service
jboss.as.server-controller: org.jboss.msc.service.StartException in
service jboss.as.server-controller: Failed to start service
at
org.jboss.msc.service.ServiceInstanceImpl$StartTask.run(ServiceInstanceImpl.java:1207)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_23]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
Caused by: java.util.ServiceConfigurationError:
org.jboss.as.controller.NewExtension: Provider
org.jboss.as.webservices.NewWSExtension not found
at java.util.ServiceLoader.fail(ServiceLoader.java:214) [:1.6.0_23]
at java.util.ServiceLoader.access$400(ServiceLoader.java:164) [:1.6.0_23]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:350)
[:1.6.0_23]
13 years, 3 months
Attributes, metrics, additional descriptive information for such
by Brian Stansberry
Emanuel,
FYI I think this pretty much summarizes the various IRC etc discussions
today about metrics. Thoughts?
1) Metrics are represented in the model description at the same level as
"configuration" attributes.
2) Metrics are represented in a "read-resource" result the same as
configuration attributes.
3) Metrics are stored in a ModelNodeRegistration in the same map as
attributes
a) but they need to have a custom read handler registered, as the
default model-reading one won't work
4) Multi-server queries will not be done via the domain/host level
resources. This eliminates the "expense" issue of treating metrics
as attributes on a domain resource (expense due to need to read the
metrics across all servers in order to
generate the full result.) Instead, domain and host level resources will
not have metrics, and attributes will just return
the domain/host level value.
Instead, for multi-server results, wildcards and lists will be used:
e.g. host=*,server=*,subsystem=web,connector=http attribute=pool-size
e.g. host=[hostA,hostB],server=*,subsystem=web,connector=http
attribute=pool-size
e.g. server-group=group1,host=*,server=*,subsystem=web,connector=http
attribute=pool-size
e.g.
server-group=[group1,group2],host=*,server=*,subsystem=web,connector=http attribute=pool-size
This needs thought as to how to implement; sounds nice conceptually.
5) The model description for an attribute will include two additional
pieces of metadata:
storage (alternative term -- applies-to): Either
configuration = Derived from and stored in the persistent configuration
(i.e. domain.xml/host.xml/standalone.xml).
runtime = Derived from and stored in runtime state only, and not in any
persistent configuration.
There's an ongoing debate over "storage" vs "applies-to".
access-type: One of
read-only = Not modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
read-write = Modifiable via a simple write-attribute operation. Value
will not change without some sort of management action.
metric = Value may change without any management action. Not directly
modifiable via a management action.
6) The value for said "storage" and "access-type" fields in the
attribute description will be generated by the
READ_RESOURCE_DESCRIPTION operation handler. It will not come from the
resource's DescriptionProvider (i.e. we
don't rely on developers correctly adding this metadata for each attribute.)
TBD:
1) "storage" vs "applies-to"
2) How to ensure the "storage" and "access-type" fields are correctly
set? Likely replace/overload ModelNodeRegistration's
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler);
with
void registerReadOnlyAttribute(String attributeName, OperationHandler
readHandler, Storage storage);
void registerReadWriteAttribute(String attributeName, OperationHandler
readHandler, OperationHandler writeHandler, Storage storage);
void registerMetric(String attributeName, OperationHandler readHandler);
2) We briefly touched on the concept of a "runtime entity" aka a
"runtime resource". A resource that
only exists in the registry, but has no persistent representation in
domain.xml,
host.xml or standalone.xml.
a) Said runtime resource cannot have attributes with storage=configuration
b) We briefly mentioned having recursive model reads stop at runtime
resources, in order to avoid excessive cost.
3) If we have runtime resources, this status should probably be
reflected in the resource description.
And probably should be stored directly in the ModelNodeRegistration,
e.g. via
ModelNodeRegistration registerSubModel(PathElement address,
DescriptionProvider descriptionProvider, Storage storage);
4) Does storage/applies-to have a 3rd value: "both"? IOW does
"configuration" always imply "runtime"?
5) The "storage/applies-to" concept is relevant to operations in
general, not just reads/write of attributes.
6) We need to know whether execution of an operation (including
write-attribute) on a server puts that server
in a state where it requires a restart. If the operation will always
trigger a restart requirement, we use
the interface implemented by the handler for the operation to determine
this. Some operations may or may
not trigger a restart requirement; it depends on the value of the
parameters and the current state when
they are applied.
Clients are likely to want to know about the restart impact before
executing an operation (i.e. if it will/may/won't
trigger the need to restart). So this should be added to the
operation/attribute description.
7) Some operations can be applied to the runtime even if a previous
operation has triggered the requirement
for a restart is required. Some may always work, some may or may not
work depending on the params and
the runtime state. We currently have no mechanism for informing the
server controller of this kind of thing;
we just disable all runtime updates once restart is required. It would
be better to make this information
available to the server controller. Clients may want to know as well, so
this should be added to the
operation/attribute description.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 3 months
Cryptic Error Messages
by Darran Lofthouse
Do we have any plans to capture cryptic error messages experienced while
working with AS7 so we can review if there are better ways the problem
can be reported?
Over the past week I have experienced the two errors at the end of this
e-mail.
The first of these errors was reported because a subsystem had not read
all of it's configuration but the reported error gives the impression
there may be a problem with the actual XML.
The second error although claiming an extension could not be found was
actually because the extension could not be loaded as the module
containing a class used by the extension was not referenced from the
module.xml.
Regards,
Darran Lofthouse.
===== 1 =====
Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[142,91]
Message: Unexpected element '{urn:jboss:domain:osgi:1.0}configuration'
encountered
at
org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:61)
at
org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:383)
===== 2 =====
10:35:08,866 ERROR [org.jboss.msc] MSC-00001: Failed to start service
jboss.as.server-controller: org.jboss.msc.service.StartException in
service jboss.as.server-controller: Failed to start service
at
org.jboss.msc.service.ServiceInstanceImpl$StartTask.run(ServiceInstanceImpl.java:1207)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_23]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
Caused by: java.util.ServiceConfigurationError:
org.jboss.as.controller.NewExtension: Provider
org.jboss.as.webservices.NewWSExtension not found
at java.util.ServiceLoader.fail(ServiceLoader.java:214) [:1.6.0_23]
at java.util.ServiceLoader.access$400(ServiceLoader.java:164) [:1.6.0_23]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:350)
[:1.6.0_23]
13 years, 3 months
Porting OSGi Subsystem to Detyped Model
by Darran Lofthouse
I am currently porting the OSGi subsystem to the detyped API, the xsd
for the OSGi subsystem allows quite a bit of flexibility so I thought I
would quickly show the resulting add operation from parsing the current
standalone.xml configuration to check if there are any further comments.
Regards,
Darran Lofthouse.
{
"operation" => "add",
"address" => [("subsystem" => "osgi")],
"activation" => "lazy",
"configuration" => {
"pid" =>
"org.apache.felix.webconsole.internal.servlet.OsgiManager",
"configuration_properties" => {"manager.root" => "jboss-osgi"}
},
"properties" => {
"org.jboss.osgi.system.modules" => "org.apache.log4j,
org.jboss.arquillian.api,
org.jboss.arquillian.junit,
org.jboss.arquillian.protocol.osgi,
org.jboss.arquillian.spi,
org.jboss.as.osgi,
org.jboss.shrinkwrap.api,
javax.inject.api,
junit.junit",
"org.osgi.framework.system.packages.extra" =>
"javax.transaction;version=1.1,
org.apache.log4j;version=1.2,
org.jboss.as.osgi.service;version=7.0,
org.jboss.logging;version=3.0,
org.jboss.osgi.deployment.deployer;version=1.0,
org.jboss.osgi.deployment.interceptor;version=1.0,
org.jboss.osgi.spi;version=1.0,
org.jboss.osgi.spi.capability;version=1.0,
org.jboss.osgi.spi.util;version=1.0,
org.jboss.osgi.testing;version=1.0,
org.jboss.osgi.vfs;version=1.0,
org.jboss.arquillian.api, org.jboss.arquillian.junit,
org.jboss.arquillian.osgi,
org.jboss.shrinkwrap.api,
org.jboss.shrinkwrap.api.asset, org.jboss.shrinkwrap.api.spec,
org.jboss.shrinkwrap.impl.base,
org.junit, org.junit.runner, javax.inject"
},
"modules" => {
"org.osgi.compendium" => {"start" => false},
"org.apache.aries.util" => {"start" => false},
"org.jboss.as.osgi.configadmin" => {"start" => true},
"org.apache.felix.configadmin" => {"start" => true},
"org.jboss.osgi.common" => {"start" => true},
"org.apache.aries.jmx" => {"start" => true},
"org.jboss.osgi.jmx" => {"start" => true}
}
}
13 years, 3 months
A domain controller msg bus
by Scott Stark
I'm starting to look into the current domain controller for a prototype
integration of byteman I want to investigate for use in cloud based as7
usage. The idea is to have an byteman rules extension to the domain with
aggregated reporting of the pieces back to a "centralized" location for
processing. A similar usecase exists for log msgs of certain severity or
context (security for example).
I'm guessing we don't want this to be on the domain controller
operations msg bus to avoid its stability and performance being
impacted. I can certainly build this at another layer using service(s)
in domain servers, but would it be beneficial to look into a domain msg
bus(es) notion at this point?
The RHEV layer is heading towards a msg bus as its main mechanism for
configuring/controlling instances it seems. I would expect that at some
point the open jdk vm will better integrate with the kvm and expose this
bus.
13 years, 3 months
Maven Repository Dependencies
by Darran Lofthouse
I was speaking to David yesterday and said I would raise a thread to see
if there is a consistent approach that could be used for defining which
repositories to use to download the dependencies for JBoss AS and the
other smaller components.
Personally I have had problems in the past trying to work with a single
central configuration for repositories so I have been trying to avoid a
central configuration as much as possible.
For the actual AS build the repositories have been defined in the
pom.xml so I was proposing a similar change for other modules that
require some dependency from our Nexus repos e.g.
https://github.com/darranl/jboss-dmr/commit/3b47d97410cdfd25845f1ff2399e1...
Does this make sense for all the smaller projects where required or do
we still want changes to be made to a local settings.xml just to be able
to build?
Regards,
Darran Lofthouse.
13 years, 3 months
detyped checkstyle errors
by Scott Stark
I'm trying to rebuild the detpyed branch of
https://github.com/bstansberry/jboss-as.git, and I'm seeing this fail
due to checkstyle errors when building the jboss-as-domain-client
project. Is this legit or something out of date in the build env. I have
not built on this particular box for a while, so perhaps there is some
older mvn pieces around.
[INFO] Compiling 78 source files to
/Users/git/detyped/domain-client/target/classes
[INFO]
[INFO] --- maven-checkstyle-plugin:2.5:checkstyle (check-style) @
jboss-as-domain-client ---
[INFO] Starting audit...
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:110:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:132:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:142:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:153:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:160:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:189:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/DomainManagementPlan.java:198:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:110:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:132:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:142:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:153:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:160:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:189:5:
Redundant 'public' modifier.
/Users/git/detyped/domain-client/src/main/java/org/jboss/as/domain/client/api/detyped/HostManagementPlan.java:198:5:
Redundant 'public' modifier.
Audit done.
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: Build Configuration ..... SUCCESS [2.289s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [1.603s]
[INFO] JBoss Application Server: Protocol Utilities ...... SUCCESS [3.132s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [13.357s]
[INFO] JBoss Application Server: Domain Client ........... FAILURE [1.439s]
[INFO] JBoss Application Server: Domain Client ........... SKIPPED
...
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 23.618s
[INFO] Finished at: Mon Jan 31 12:42:02 PST 2011
[INFO] Final Memory: 38M/104M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.5:checkstyle
(check-style) on project jboss-as-domain-client: An error has occurred
in Checkstyle report generation. Failed during checkstyle execution:
There are 14 checkstyle errors. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :jboss-as-domain-client
13 years, 3 months