[JBoss JIRA] (JBASMP-65) Could not execute goal add-resource / wildfly-maven-plugin
by Felix Coutinho (JIRA)
Felix Coutinho created JBASMP-65:
------------------------------------
Summary: Could not execute goal add-resource / wildfly-maven-plugin
Key: JBASMP-65
URL: https://issues.jboss.org/browse/JBASMP-65
Project: JBoss AS Maven Plugins
Issue Type: Bug
Components: deploy, wildfly
Affects Versions: 7.5.Final
Environment: Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T14:37:52-03:00)
Maven home: /home/felix/Downloads/apache-maven-3.2.1
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: pt_BR, platform encoding: UTF-8
OS name: "linux", version: "3.8.0-35-generic", arch: "amd64", family: "unix"
Reporter: Felix Coutinho
Assignee: James Perkins
Priority: Blocker
My pom: http://pastebin.com/BJ9zcXrg
felix@felix-DQ77PRO:~/workspaces/java/workspaceGastos/yyy-project$ mvn clean install -X
The debug output:
http://pastebin.com/cM8LbR62
The problem is here:
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null: IllegalArgumentException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:add-resource (add-datasource) on project logr: Could not execute goal add-resource. Reason: null
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Could not execute goal add-resource. Reason: null
at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:118)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asList(ModelValue.java:132)
at org.jboss.dmr.ModelNode.asList(ModelNode.java:1302)
at org.wildfly.plugin.deployment.resource.AddResourceMojo.resourceExists(AddResourceMojo.java:258)
at org.wildfly.plugin.deployment.resource.AddResourceMojo.addCompositeResource(AddResourceMojo.java:180)
at org.wildfly.plugin.deployment.resource.AddResourceMojo.processResources(AddResourceMojo.java:148)
at org.wildfly.plugin.deployment.resource.AddResourceMojo.execute(AddResourceMojo.java:112)
... 21 more
Same problem:
http://stackoverflow.com/questions/22533311/wildfly-maven-plugin-not-depl...
Other:
http://stackoverflow.com/questions/21020926/add-an-xa-datasource-fails-wi...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3147) spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
by Maxim Frolov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3147?page=com.atlassian.jira.plugin.... ]
Maxim Frolov commented on WFLY-3147:
------------------------------------
I asked in WELD-DEV mailing list ([http://lists.jboss.org/pipermail/weld-dev/2014-March/003224.html]), whether this issue might be a bug in _weld-core-impl_.
> spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3147
> URL: https://issues.jboss.org/browse/WFLY-3147
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, EE
> Affects Versions: 8.0.0.Final
> Reporter: Maxim Frolov
> Assignee: Stuart Douglas
>
> A CDI Bean Archive with a _beans.xml_ which contains {{beans/scan/*exclude*}} XML element causes {{NullPointerExcpetion}} during deployment on server with enabled {{<spec-descriptor-property-replacement>}} parameter in server's _standalone.xml_.
> The error stack trace is:
> {noformat}
> 2014-03-21 11:22:52,455 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-11) MSC000001: Failed to start service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "example-ejb.jar" of deployment "example.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
> at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:140)
> at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:117)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.metadata.property.DefaultPropertyReplacer.replaceProperties(DefaultPropertyReplacer.java:52)
> at org.jboss.as.weld.deployment.PropertyReplacingBeansXmlHandler.interpolate(PropertyReplacingBeansXmlHandler.java:64)
> at org.jboss.weld.xml.BeansXmlHandler$4.processStartChildElement(BeansXmlHandler.java:229)
> at org.jboss.weld.xml.BeansXmlHandler.startElement(BeansXmlHandler.java:297)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:93)
> at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:136)
> ... 7 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (SECURITY-810) Lifetime configuration option for Kerberos LoginModule
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-810?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved SECURITY-810.
---------------------------------------
Resolution: Done
Added the following module option to control the lifetime of the created GSSCredential: -
{code}
/**
* The lifetime in seconds of the {@link GSSCredential}, a negative value will set this to GSSCredential.INDEFINITE_LIFETIME.
*
* Defaults to GSSCredential.DEFAULT_LIFETIME
*/
public static final String CREDENTIAL_LIFETIME = "credentialLifetime";
{code}
> Lifetime configuration option for Kerberos LoginModule
> ------------------------------------------------------
>
> Key: SECURITY-810
> URL: https://issues.jboss.org/browse/SECURITY-810
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Reporter: Jesper Pedersen
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_3_0_CR1
>
>
> Add a configuration option to the Kerberos LoginModule that allows to control the lifetime
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3147) spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
by Maxim Frolov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3147?page=com.atlassian.jira.plugin.... ]
Maxim Frolov commented on WFLY-3147:
------------------------------------
Bug in _weld-core-impl_-2.1.2.Final?
The [BeansXmlHandler|https://github.com/weld/core/blob/2.1.2.Final/impl/src/ma...] always calls interpolate(), even if the argument is _null_.
At runtime Wildfly calls interpolate() method which is overridden by [PropertyReplacingBeansXmlHandler|https://github.com/wildfly/wildfly/blob/...], which delegates processing to [DefaultPropertyReplacer|https://github.com/jboss/metadata/blob/8.0.0.Fina...]. Nowehere the null-check is performed.
I think, that the BeansXmlHandler should not call interpolate() method at all if the value of attribute or XML element is absent.
> spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3147
> URL: https://issues.jboss.org/browse/WFLY-3147
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, EE
> Affects Versions: 8.0.0.Final
> Reporter: Maxim Frolov
> Assignee: Stuart Douglas
>
> A CDI Bean Archive with a _beans.xml_ which contains {{beans/scan/*exclude*}} XML element causes {{NullPointerExcpetion}} during deployment on server with enabled {{<spec-descriptor-property-replacement>}} parameter in server's _standalone.xml_.
> The error stack trace is:
> {noformat}
> 2014-03-21 11:22:52,455 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-11) MSC000001: Failed to start service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "example-ejb.jar" of deployment "example.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
> at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:140)
> at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:117)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.metadata.property.DefaultPropertyReplacer.replaceProperties(DefaultPropertyReplacer.java:52)
> at org.jboss.as.weld.deployment.PropertyReplacingBeansXmlHandler.interpolate(PropertyReplacingBeansXmlHandler.java:64)
> at org.jboss.weld.xml.BeansXmlHandler$4.processStartChildElement(BeansXmlHandler.java:229)
> at org.jboss.weld.xml.BeansXmlHandler.startElement(BeansXmlHandler.java:297)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:93)
> at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:136)
> ... 7 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-2713) ViewExpiredException in Chrome on WildFly 8.0.0.CR1
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2713?page=com.atlassian.jira.plugin.... ]
Farah Juma closed WFLY-2713.
----------------------------
Resolution: Out of Date
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
> Key: WFLY-2713
> URL: https://issues.jboss.org/browse/WFLY-2713
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
> Reporter: Pavol Pitonak
> Assignee: Farah Juma
> Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 8.0.0.Beta1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-2713) ViewExpiredException in Chrome on WildFly 8.0.0.CR1
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/WFLY-2713?page=com.atlassian.jira.plugin.... ]
Pavol Pitonak commented on WFLY-2713:
-------------------------------------
No, I cannot reproduce anymore with WildFly 8.0.0.Final.
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
> Key: WFLY-2713
> URL: https://issues.jboss.org/browse/WFLY-2713
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
> Reporter: Pavol Pitonak
> Assignee: Farah Juma
> Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 8.0.0.Beta1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JGRP-1759) BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1759:
--------------------------------
After running another 20 test suite runs, this test *never* failed. I did submit the PR to Byteman though and will use rendezvous with a timeout once this is folded into a new Byteman release. Pushing this to 4.0.
> BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
> ----------------------------------------------------------------
>
> Key: JGRP-1759
> URL: https://issues.jboss.org/browse/JGRP-1759
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Windows 2008, x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang.
> The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks.
> .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JGRP-1759) BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1759:
---------------------------
Fix Version/s: 4.0
(was: 3.5)
> BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks
> ----------------------------------------------------------------
>
> Key: JGRP-1759
> URL: https://issues.jboss.org/browse/JGRP-1759
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Windows 2008, x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang.
> The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks.
> .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months