[JBoss JIRA] Created: (JBESB-193) Need support for notification generatoin from within ActionProcessor.process method
by Tom Fennelly (JIRA)
Need support for notification generatoin from within ActionProcessor.process method
-----------------------------------------------------------------------------------
Key: JBESB-193
URL: http://jira.jboss.com/jira/browse/JBESB-193
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 4.1
Reporter: Tom Fennelly
Assigned To: Mark Little
Fix For: 4.1
In version 4.0, the Action Processing pipeline management code raises notifications in response to an exception from the ActionProcessor.process method. The pipeline managemnt code calls the getOkNotification (no exception) or getErrorNotification (exception) to get the notification message.
For many reasons, this is a very flawed model. Notifications should be raised from within the process method by means of attaching the notifications (error or otherwise) to the message (the mechanism is a design issue). Once the process method returns, the pipline processing management code can check the message for notifications. If there are errors, it can/should (?) abort the message processing, send the error notification (by whatever notification options are configured on the listener) and signal the failure to the calling process (by whatever failure config is configured on the listener).
The getOk and getErro methods can then be removed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1 week, 6 days
[JBoss JIRA] Created: (JGRP-1257) ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded
by Andres Garcia Garcia (JIRA)
ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded
---------------------------------------------------------------------------------
Key: JGRP-1257
URL: https://jira.jboss.org/browse/JGRP-1257
Project: JGroups
Issue Type: Bug
Affects Versions: 2.11, 2.8, 2.7
Environment: Windows XP SP3, Java 1.6
Reporter: Andres Garcia Garcia
Assignee: Bela Ban
Recently I updated my jgroups version from 2.4.x to 2.11. Suddenly my applications thrown this exception.
org.jgroups.ChannelException: unable to setup the protocol stack: Given final block not properly padded
at org.jgroups.JChannel.init(JChannel.java:1574)
at org.jgroups.JChannel.<init>(JChannel.java:257)
at org.jgroups.JChannel.<init>(JChannel.java:240)
at org.jgroups.demos.Draw.<init>(Draw.java:52)
at org.jgroups.demos.Draw.main(Draw.java:141)
Caused by: java.security.UnrecoverableKeyException: Given final block not properly padded
at com.sun.crypto.provider.SunJCE_z.a(DashoA13*..)
at com.sun.crypto.provider.JceKeyStore.engineGetKey(DashoA13*..)
at java.security.KeyStore.getKey(Unknown Source)
at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:269)
at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:231)
at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:641)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:468)
at org.jgroups.JChannel.init(JChannel.java:1570)
... 4 more
The ENCRYPT protocol config is
<ENCRYPT sym_init="448"
sym_algorithm="Blowfish"
encrypt_entire_message="true"
key_store_name="cloudencrypt.keystore"
store_password="password"
alias="test"/>
I tested the same code with different versions. 2.6.15 GA is the last working version, and every version I tested from 2.7 GA to 2.11 GA throw the same exception. I made a little use case with it. Maybe I am missing something?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2 weeks, 1 day
[JBoss JIRA] Created: (AS7-782) Hudson/Jenkins won't work in AS7b3
by Fred Bricon (JIRA)
Hudson/Jenkins won't work in AS7b3
----------------------------------
Key: AS7-782
URL: https://issues.jboss.org/browse/AS7-782
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.Beta3
Environment: Fedora 14, JDK 1.6.0_24, JBoss AS7 beta 3
Reporter: Fred Bricon
Assignee: Jason Greene
After patching AS7b3 with the latest jboss-vfs from github/master and
deploying hudson ( http://search.maven.org/remotecontent?filepath=org/jvnet/hudson/main/huds...) or jenkins on AS7, an exception is thrown when accessing the homepage (or any page) :
{noformat}
17:39:33,429 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/hudson-war-2.0.0].[Stapler]] (http-localhost.localdomain-127.0.0.1-8080-2) "Servlet.service()" pour la servlet Stapler a généré une exception: java.net.MalformedURLException: unknown protocol: jndi
at java.net.URL.<init>(URL.java:574) [:1.6.0_24]
at java.net.URL.<init>(URL.java:464) [:1.6.0_24]
at java.net.URL.<init>(URL.java:413) [:1.6.0_24]
at org.kohsuke.stapler.Stapler.selectResourceByLocale(Stapler.java:227) [stapler-1.155.jar:]
at org.kohsuke.stapler.Stapler.openResourcePathByLocale(Stapler.java:203) [stapler-1.155.jar:]
at org.kohsuke.stapler.Stapler.service(Stapler.java:145) [stapler-1.155.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) [hudson-core-2.0.0.jar:]
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:162) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:658) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
{noformat}
I first mentioned this issur on irc (see http://echelog.matzon.dk/logs/browse/jboss-as7/1305151200 [13:42:43] -> [13:48:58])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2 weeks, 4 days
[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender
by Bela Ban (JIRA)
Optimization: make threads return immediately if NAKACK has another active thread for the same sender
-----------------------------------------------------------------------------------------------------
Key: JGRP-457
URL: http://jira.jboss.com/jira/browse/JGRP-457
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.5
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3 months, 3 weeks
[JBoss JIRA] (WFLY-9727) WildFly Randomly Terminates after 5-10 minutes
by Daniel Wiseman (JIRA)
[ https://issues.jboss.org/browse/WFLY-9727?page=com.atlassian.jira.plugin.... ]
Daniel Wiseman commented on WFLY-9727:
--------------------------------------
[~dmlloyd] I added that flag to my VM arguments in my WildFly server's launch configuration settings within Eclipse, started up my server, and I can no longer load any page from my project from my browser. In the my WildFly logs I noticed a service monitor within my project failed due to an IOException:
{{Caused by: java.io.IOException: Operation failed with status WAITING
at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:247)
at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:158)
at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:105)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at com.soasta.common.diagnostics.jmx.Wildfly10Server.connect(Wildfly10Server.java:90)
at com.soasta.monitor.resource.ConnectTask.taskExecute(ConnectTask.java:74)
... 1 more}}
> WildFly Randomly Terminates after 5-10 minutes
> ----------------------------------------------
>
> Key: WFLY-9727
> URL: https://issues.jboss.org/browse/WFLY-9727
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Environment: Running WildFly 10.x from within Eclipse Oxygen (4.7.2) on 2015 MacBook Pro running OS X El Capitan (10.11.6)
> Reporter: Daniel Wiseman
> Assignee: Jason Greene
> Priority: Blocker
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time:
> {{Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
> Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)}}
> This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-9747) wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet commented on WFLY-9747:
----------------------------------------
*Workaround*
Add this dependency after the wildfly-arquillian-container-managed 2.1.0.Final dependency:
{code}
<dependency>
<!-- TODO Workaround to fix wildfly-arquillian-container-managed https://issues.jboss.org/browse/WFLY-9747 -->
<groupId>org.wildfly.security</groupId>
<artifactId>wildfly-elytron</artifactId>
<version>1.1.0.Final</version>
<scope>test</scope>
</dependency>
{code}
> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9747
> URL: https://issues.jboss.org/browse/WFLY-9747
> Project: WildFly
> Issue Type: Bug
> Reporter: Geoffrey De Smet
> Assignee: Jason Greene
>
> On a pretty vanilla war file with a bit JAX-RS and arquillian, I get this error when trying to run an arquillian test (that worked before we upgraded the wildfly version):
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest Time elapsed: 0.448 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
> <properties>
> <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
> <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
> <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
> </properties>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.jboss.arquillian</groupId>
> <artifactId>arquillian-bom</artifactId>
> <version>${version.org.jboss.arquillian}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> <dependency>
> <groupId>org.wildfly.arquillian</groupId>
> <artifactId>wildfly-arquillian-container-managed</artifactId>
> <version>${version.org.wildfly.arquillian}</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-client</artifactId>
> <version>${version.org.jboss.resteasy}</version>
> </dependency>
> ...
> {code}
> and this child pom:
> {code}
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.junit</groupId>
> <artifactId>arquillian-junit-container</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.shrinkwrap.resolver</groupId>
> <artifactId>shrinkwrap-resolver-depchain</artifactId>
> <type>pom</type>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.wildfly.arquillian</groupId>
> <artifactId>wildfly-arquillian-container-managed</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-client</artifactId>
> <scope>test</scope>
> </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-9747) wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet edited comment on WFLY-9747 at 1/31/18 2:20 PM:
-----------------------------------------------------------------
org.wildfly.security.permission.AbstractNameSetOnlyPermission comes from wildfly-elytron.jar and if I compare a working project with older version with my non-working project, I notice that my newer project has the older wildfly-elytron jar:
{code}
// Working project with wildfly and arquillian
[INFO] | +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] | | +- org.wildfly.security:wildfly-elytron:jar:1.1.0.Final:test
{code}
{code}
// My failing project with wildfly and arquillian
[INFO] +- org.wildfly.arquillian:wildfly-arquillian-container-managed:jar:2.1.0.Final:test
...
[INFO] | +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] | | +- org.wildfly.security:wildfly-elytron:jar:1.0.2.Final:test
{code}
Manually hacking that to add wildfly-elytron 1.1.0.Final makes the error disappear.
Solution proposal C)
Have wildfly-arquillian-protocol-jmx depnd on wildfly-elytron 1.1.0.Final instead of 1.0.2.Final.
was (Author: ge0ffrey):
org.wildfly.security.permission.AbstractNameSetOnlyPermission comes from wildfly-elytron.jar and if I compare a working project with older version with my non-working project, I notice that my newer project has the older wildfly-elytron jar:
{code}
// Working project with wildfly and arquillian
[INFO] | +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] | | +- org.wildfly.security:wildfly-elytron:jar:1.1.0.Final:test
{code}
{code}
// My project with wildfly and arquillian
[INFO] +- org.wildfly.arquillian:wildfly-arquillian-container-managed:jar:2.1.0.Final:test
...
[INFO] | +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] | | +- org.wildfly.security:wildfly-elytron:jar:1.0.2.Final:test
{code}
Manually hacking that to add wildfly-elytron 1.1.0.Final makes the error disappear.
Solution proposal C)
Have wildfly-arquillian-protocol-jmx depnd on wildfly-elytron 1.1.0.Final instead of 1.0.2.Final.
> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9747
> URL: https://issues.jboss.org/browse/WFLY-9747
> Project: WildFly
> Issue Type: Bug
> Reporter: Geoffrey De Smet
> Assignee: Jason Greene
>
> On a pretty vanilla war file with a bit JAX-RS and arquillian, I get this error when trying to run an arquillian test (that worked before we upgraded the wildfly version):
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest Time elapsed: 0.448 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
> <properties>
> <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
> <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
> <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
> </properties>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.jboss.arquillian</groupId>
> <artifactId>arquillian-bom</artifactId>
> <version>${version.org.jboss.arquillian}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> <dependency>
> <groupId>org.wildfly.arquillian</groupId>
> <artifactId>wildfly-arquillian-container-managed</artifactId>
> <version>${version.org.wildfly.arquillian}</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-client</artifactId>
> <version>${version.org.jboss.resteasy}</version>
> </dependency>
> ...
> {code}
> and this child pom:
> {code}
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.arquillian.junit</groupId>
> <artifactId>arquillian-junit-container</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.shrinkwrap.resolver</groupId>
> <artifactId>shrinkwrap-resolver-depchain</artifactId>
> <type>pom</type>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.wildfly.arquillian</groupId>
> <artifactId>wildfly-arquillian-container-managed</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.jboss.resteasy</groupId>
> <artifactId>resteasy-client</artifactId>
> <scope>test</scope>
> </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years