Copying exception call stack from AS8 console is missing text...
by Scott Marlow
Hi,
I tried to copy an exception call stack off the AS8 console but the
clipboard only contains a partial callstack (as if the foreground color
was the same as the background color). When I pasted the exception call
stack into Intellij, I see something like http://pastebin.com/ku4TARFV
The workaround is to not copy exceptions from the console but instead
look in the server.log. Does this deserve a (logging?) jira or should
we live with this behaviour?
Scott
11 years, 8 months
Resolving AS8/OSGi deployment disconnects
by Thomas Diesler
Folks,
we are still having disconnects between the OSGi Bundle lifecycle operations and their respective mapping to the deployment API. Here I'd like to describe how it currently works and how it could possibly get fixed. Related issues are tracked by [1] - further background is described in [2].
Bundle start/stop disconnect
--------------------------------------
A Bundle start/stop operation activates/deactivates the bundle services. The associated class loader and wiring is unaffected.
Approach #1 - start/stop is not mapped to deployment operations
Bundle deploy installs the Bundle to the Framework
Bundle is not resolved/started as part of the deploy operation
No module/classloader is created during deployment
All deployment processing that needs load classes/resources is skipped
No service provided by the bundle deployment is created
Bundle needs to be started/stopped explicitly
Bundle start/stop management operations are specific to bundle deployments
The POST_MODULE processing for OSGi enabled deployments (e.g. webapp) would need to be executed in an OSGi specific processor chain
OSGi enabled POST_MODULE DUPs have their functionality externalised such that it can get reused for start/stop operations
The start/stop processing chain must be traversable in both directions repeatedly
Approach #2 - start/stop is mapped to deployment operations
Bundle deploy installs the Bundle to the Framework and attempts to resolve/start the Bundle
If the Bundle can get resolved, a module/classloader is created as part of the DU processing
In case the Bundle cannot get resolved, DUP processing is deferred and MODULE phase processing is reattempted later based on an external trigger
Has the benefit that any deployment type can also be a Bundle
Bundle stop must reverse work that is done in POST_MODULE DUPs
POST_MODULE DUPs must be traversable in both direction multiple times
Currently, we use approach #2 with limited support from POST_MODULE DUPs (i.e. they are not designed to be executed multiple times for the same deployment). There is also the cleanup phase which breaks multiple executions of POST_MODULE DUPs.
Bundle uninstall disconnect
--------------------------------------
Bundle uninstall only removes the BundleRevision from the runtime if it is no longer in use. The classloader associated with an uninstalled bundle that is still in use remains active.
Approach #1 - "in use" semantic specific to Bundle deployments
An undeploy management operation undeploys the bundle revision but holds in the MODULE phase when the revision is still in use
This is similar to deferred MODULE phase for deploy operation
in use is not respected for non-osgi deployments and hence breaks bundle deployments that depend on them
Approach #2 - "in use" semantic applies to all deployment types
Undeploy will only destroy the Module service if the Module is not in use by another deployment
When Module usage drops to zero, undeploy continues and removes the deployment from management
This approach would map cleanly - there is no cascading destroy effect. i.e. when you undeploy a jar that a webapp depends on
Services provided by the undeployed deployment would always go down, only classloader destruction is deferred
Bundle update disconnect
------------------------------------
A Bundle can have multiple revisions. A call to Bundle.update(…) creates a new revision. There is only ever one current revision (the latest update) associated with a Bundle. Stale revisions continue to exist in the runtime until an explicit refresh of the transitive dependency graph.
Approach #1 - bundle revisions are represented as individual deployments
Each bundle update deploys the revision as a new deployment
The association of revisions to bundle happens in the OSGi layer only
Management sees disconnected deployments with no notion of stale/current or belonging together
Approach #2 - deployment API supports the notion of multiple revisions
deployments, their revisions and respective mapping would be modelled more closely on OSGi requirements
some deployment types might not support revisions
------------------------------------------------------------------------------------------------------------------------------------------------------
I suspect that solving these disconnects can happen in the context of AS9 only.
Looking forward to your feedback
Cheers
--thomas
[1] [AS7-5567] Resolve AS8/OSGi disconnects
[2] AS/OSGi Deployment Lifecycle Requirements
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years, 8 months
undertow error
by Heiko Braun
Can anybody shed some light on this?
11:34:16,243 ERROR [io.undertow.request] (XNIO-1 task-5) Blocking request failed io.undertow.server.HttpServerExchange@4de29a64: java.io.IOException: UT000019: Connection from /127.0.0.1:61588 terminated as request entity was larger than 10485760
It happens when deploying a file through the web console on the recent AS8 master.
/Heiko
11 years, 8 months
Alternate console distribution channel
by Heiko Braun
We've been prototyping an alternative distribution channel for the console and have setup a demo that leverages the mozilla app store to deliver the AS7 web console to users:
https://marketplace.firefox.com/app/kea/?src=mkt-search
It currently requires a patched version of the AS fully support CORS [1], but the general idea is that you can retrieve to through a marketplace like the mozilla one (chrome would be another alternative) and connect to any domain controller, wether it runs locally or remotely.
If want to give it shot, point four firefox browser to the marketplace URL, launch the app and connect to our CORS demo instance that runs on EC2:
http://as7-preview.dyndns.org:9990
user: admin
pass: webstore123!
Shoutouts to Harald for making this happen. He did provide the CORS patch and did all the marketplace integration.
Tell us what you think.
Regards, Heiko
[1] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
11 years, 8 months
Undertow subsystem has landed to master
by Tomaž Cerar
Hi all,
Undertow subsystem that replaces web subsystem was just merged to master.
What does that mean in practice?
All web applications that will be deployed won't be using jbossweb anymore
but new Undertow <https://github.com/undertow-io/undertow>server which was
already used to power our management server.
Undertow brings us:
- performant non-blocking i/o
- servlet 3.1
- EE7 Web Sockets
- "standard" Web Sockets
- and much more.
Currently there are still few features missing that we had in old web
subsystem, but we are working hard to add them.
I would urge everyone to try it out and report any issues you might find to
jira.
But be advised that subsystem configuration and management api are still
not completely done so they will be moving around a bit in coming months.
Onward,
Tomaz
11 years, 8 months
problem with GlobalModuleDependencyProcessor.java committed today
by Frank Langelage
Today's changes to
ee/src/main/java/org/jboss/as/ee/structure/GlobalModuleDependencyProcessor.java
cause problems for me.
Especally these lines
- boolean annotations = module.get(ANNOTATIONS).isDefined() ? module.get(ANNOTATIONS).asBoolean() : false;
- boolean services = module.get(SERVICES).isDefined() ? module.get(SERVICES).asBoolean() : true;
- boolean metaInf = module.get(META_INF).isDefined() ? module.get(META_INF).asBoolean() : false;
+ boolean annotations = module.get(ANNOTATIONS).asBoolean();
+ boolean services = module.get(SERVICES).asBoolean();
+ boolean metaInf = module.get(META_INF).asBoolean();
In deployments folder I have JDBC-drivers (ojdbc6.jar, ifxjdbc_all.jar,
sqljdbc4.jar) and a Datasource definition file (DefaultDS-ds.xml) and
for those I see
22:27:34,851 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001:
Failed to start service
jboss.deployment.unit."DefaultDS-ds.xml".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."DefaultDS-ds.xml".STRUCTURE: JBAS018733: Failed
to process phase STRUCTURE of deployment "DefaultDS-ds.xml"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:248)
at
org.jboss.as.ee.structure.GlobalModuleDependencyProcessor.deploy(GlobalModuleDependencyProcessor.java:65)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 5 more
22:27:35,798 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001:
Failed to start service
jboss.deployment.unit."ifxjdbc_all.jar".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."ifxjdbc_all.jar".STRUCTURE: JBAS018733: Failed to
process phase STRUCTURE of deployment "ifxjdbc_all.jar"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:248)
at
org.jboss.as.ee.structure.GlobalModuleDependencyProcessor.deploy(GlobalModuleDependencyProcessor.java:65)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 5 more
22:27:36,118 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001:
Failed to start service jboss.deployment.unit."sqljdbc4.jar".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."sqljdbc4.jar".STRUCTURE: JBAS018733: Failed to
process phase STRUCTURE of deployment "sqljdbc4.jar"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:248)
at
org.jboss.as.ee.structure.GlobalModuleDependencyProcessor.deploy(GlobalModuleDependencyProcessor.java:65)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 5 more
22:27:36,920 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001:
Failed to start service jboss.deployment.unit."ojdbc6.jar".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."ojdbc6.jar".STRUCTURE: JBAS018733: Failed to
process phase STRUCTURE of deployment "ojdbc6.jar"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907)
[jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_17]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:248)
at
org.jboss.as.ee.structure.GlobalModuleDependencyProcessor.deploy(GlobalModuleDependencyProcessor.java:65)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
[jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 5 more
...
22:27:38,617 INFO [org.jboss.as.server#handleResult] JBAS018559:
Deployed "sqljdbc4.jar" (runtime-name : "sqljdbc4.jar")
22:27:38,619 INFO [org.jboss.as.server#handleResult] JBAS018559:
Deployed "ojdbc6.jar" (runtime-name : "ojdbc6.jar")
22:27:38,620 INFO [org.jboss.as.server#handleResult] JBAS018559:
Deployed "ifxjdbc_all.jar" (runtime-name : "ifxjdbc_all.jar")
22:27:38,621 INFO [org.jboss.as.server#handleResult] JBAS018559:
Deployed "DefaultDS-ds.xml" (runtime-name : "DefaultDS-ds.xml")
22:27:38,625 INFO [org.jboss.as.controller#release] JBAS014774: Service
status report
JBAS014777: Services which failed to start: service
jboss.deployment.unit."ojdbc6.jar".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."ojdbc6.jar".STRUCTURE: JBAS018733: Failed to
process phase STRUCTURE of deployment "ojdbc6.jar"
service jboss.deployment.unit."sqljdbc4.jar".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."sqljdbc4.jar".STRUCTURE: JBAS018733: Failed to
process phase STRUCTURE of deployment "sqljdbc4.jar"
service jboss.deployment.unit."ifxjdbc_all.jar".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."ifxjdbc_all.jar".STRUCTURE: JBAS018733: Failed to
process phase STRUCTURE of deployment "ifxjdbc_all.jar"
service jboss.deployment.unit."DefaultDS-ds.xml".STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."DefaultDS-ds.xml".STRUCTURE: JBAS018733: Failed
to process phase STRUCTURE of deployment "DefaultDS-ds.xml"
11 years, 8 months
Re: [jboss-as7-dev] Hibernate Validator and CDI on AS
by Emmanuel Bernard
(Adding the JBoss AS Dev list)
## JNDI and injection
I think a portable extension is not a problem when it comes to adding Validator and ValidatorFactory as injectable components. There is no performance issue here.
For JNDI, the problem is that other components access JNDI to get a reference to ValidatorFactory before CDI is started, so I envisioned something like that:
- the container adds a LazyValidatorFactory/LazyValidator to JNDI
- when CDI starts and the Hibernate Validator portable extension runs, the correct ValidatorFactory is created and passed to the LazyValidatorFactory as target for the delegation. That way all components have access to the CDI enabled version.
## Method validation and interceptor binding
That is where performance is crucial. We need a special code or a custom portable extension that makes use of the jandex information to find for a given deployment:
- all types directly or indirectly involved with @Valid, @Constraint and @ValidateOnExecution
- all constrained types as defined in XML
- all subtypes of these types
- filter them according to the list of CDI beans
And add interception to these CDI beans assuming they are properly constrained according to the BV rules.
Emmanuel
On 4 avr. 2013, at 08:43, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> All,
>
> I'd like to get a discussion started on the integration of Hibernate Validator and CDI when running on AS.
>
> To give some background, the Bean Validation 1.1 spec defines an integration of BV and CDI:
>
> * Validator and ValidatorFactory are considered managed beans retrievable via @Inject
> * Constraint validators are considered managed beans and thus subject to dependency injection
> * Any managed bean methods with BV constraints on parameters or return value are validated automatically upon invocation using an interceptor
>
> To satisfy these requirements, we have implemented a CDI portable extension in HV 5 which registers beans for validator and factory, sets up the method interceptor etc.
>
> I've got the following questions:
>
> 1) Should this PE used on AS to integrate BV and CDI? If so, IIRC there were problems with PEs contained in AS modules, but I think these should have been fixed in between. Jozef?
>
> I also remember someone thinking about more efficient means of doing the task based on Weld-specific APIs instead of the standardized CDI APIs used by the PE.
>
> 2) The CDI-enabled validator (factory) must be retrievable via JNDI and EE's @Resource injection. Based on my (not overly deep) understanding of how things work in AS, the registration process currently looks like this:
>
> a) The validator factory is created using LazyValidatorFactory/BeanValidationFactoryDeployer, bound to JNDI and attached to the current deployment
>
> b) WeldDeploymentProcessor picks it up from there and makes it available to Weld using the ValidationServices SPI
>
> AFAICS step a) could be used for non-CDI-enabled deployments. For CDI-enabled deployments, the VF created by the PE (assuming it's going to be used) would have to be registered. So I guess the following could be done:
>
> * Make step a) register the VF only for non-CDI-enabled deployments
> * For CDI-enabled deployments, bind the VF from the PE to JNDI e.g. in WeldDeploymentProcessor (or create a new deployment unit processor for this). I'm not sure though whether beans can already be retrieved from Weld at this point during deployment.
>
> This is just a rough idea based on my current understanding, I'm looking forward for your thoughts and ideas how the task should be accomplished.
>
> Thanks,
>
> --Gunnar
>
11 years, 8 months
