[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4962?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4962:
--------------------------------
Fix Version/s: 12.0.3.Final
(was: 12.0.2.Final)
> Add a SecurityMetaData for all deployments
> ------------------------------------------
>
> Key: WFCORE-4962
> URL: https://issues.redhat.com/browse/WFCORE-4962
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 12.0.3.Final
>
>
> For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used.
> At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-4973) NPE due to timeout in LongOutputTestCase
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4973?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4973:
--------------------------------
Fix Version/s: 12.0.3.Final
(was: 12.0.2.Final)
> NPE due to timeout in LongOutputTestCase
> ----------------------------------------
>
> Key: WFCORE-4973
> URL: https://issues.redhat.com/browse/WFCORE-4973
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Major
> Fix For: 12.0.3.Final
>
>
> [ERROR] Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 50.287 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.LongOutputTestCase
> [ERROR] testDisabledOutputPagingViaXml(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.961 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaXml(LongOutputTestCase.java:380)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> [ERROR] testDisabledOutputPagingViaArgument(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.849 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaArgument(LongOutputTestCase.java:368)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13641) WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
by Jens Viebig (Jira)
[ https://issues.redhat.com/browse/WFLY-13641?page=com.atlassian.jira.plugi... ]
Jens Viebig commented on WFLY-13641:
------------------------------------
Your assumptions are mostly correct. But the jar inside the ear is an ejb-jar deployed in the main directory, not in the lib subdirectory.
So if its true that this is not supported, should it even try to create an index ? If you have lots of classes in the jar, you get lots of warnings.
I also like to learn what is the impact of these warnings ? What happens if there is no index created ?
With bean-discovery-mode "all" the beans are detected and can be injected in the WAR, but actually this caused problems with our EJBs and the entity manager and switching to "annotated" helped, see for a detailed description:
[https://groups.google.com/forum/#!topic/wildfly/tKBea3ylOJk]
It could be that this bug is somehow working in our favor in this case, so I would love to learn what should be the expected behaviour
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13641
> URL: https://issues.redhat.com/browse/WFLY-13641
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.0.Final
> Reporter: Jens Viebig
> Assignee: Matěj Novotný
> Priority: Major
>
> When referencing a jar with CDI scan mode "annotaded" inside an ear from an external war via jboss-deployment-structure.xml a warning will be printed for every class:
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> Seems VFS cannot get hold of the classes.
> The warning is logged in ExternalBeanArchiveProcessor which catches an EOFException from the inputstream loading the class. (Line 284). Seems the input stream is not able to load a single byte from the class
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5485) Move test cases from drools-compiler to drools-model-compiler
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5485:
-----------------------------------------
Summary: Move test cases from drools-compiler to drools-model-compiler
Key: DROOLS-5485
URL: https://issues.redhat.com/browse/DROOLS-5485
Project: Drools
Issue Type: Task
Components: core engine, executable model
Affects Versions: 7.39.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
Move test cases from drools-compiler to drools-model-compiler so that we can increase the test coverage for executable-model.
At the moment, I'm not yet sure how many of the test cases can be moved. Basically DRL based test only.
Luca noted:
> there are some tests in -compiler that are not supported in the model compiler (I'm thinking about all the ASM/type generation related). That should be left in -compiler and hopefully moved outside like the traits
If we find test failures by executable-model, we would spawn new JIRAs to deal with them one-by-one.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5029) server group deployment resource doesn't include correct "mananged" value
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFCORE-5029?page=com.atlassian.jira.plug... ]
Chao Wang updated WFCORE-5029:
------------------------------
Summary: server group deployment resource doesn't include correct "mananged" value (was: server group deployment resource doesn't include deployment content attribute and correct "mananged" value)
> server group deployment resource doesn't include correct "mananged" value
> -------------------------------------------------------------------------
>
> Key: WFCORE-5029
> URL: https://issues.redhat.com/browse/WFCORE-5029
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 13.0.0.Beta1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> Unmanaged deploys show a checkmark that they are "managed" if you view the deployment under Server Groups. The deployment does however show correctly that it is un-managed in the Content Repository section.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13600) EJB client over HTTP Fail on Java SE
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13600?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13600:
-----------------------------------
When using http protocol, you will need to set up authentication, on both server side and client side. On the server side, run {{$JBOSS_HOME/bin/add-user.sh}} to set up application users. On the client side, configure it in {{wildfly-config.xml}}:
{code:xml}
<configuration>
<authentication-client xmlns="urn:elytron:client:1.2">
<authentication-rules>
<rule use-configuration="default"/>
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<sasl-mechanism-selector selector="DIGEST-MD5"/>
<set-user-name name="user1"/>
<credentials>
<clear-password password="user1!!!"/>
</credentials>
... ...
</configuration>
</authentication-configurations>
</authentication-client>
</configuration>
{code}
> EJB client over HTTP Fail on Java SE
> ------------------------------------
>
> Key: WFLY-13600
> URL: https://issues.redhat.com/browse/WFLY-13600
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 20.0.0.Final
> Reporter: Gergely Molnár
> Assignee: Cheng Fang
> Priority: Major
>
> Java SE code:
> {code:java}
> public class Application {
> private static final String REMOTE_CALC = "ejb:/remote-ejb/RemoteCalc!" + RemoteCalc.class.getName();
> /**
> * Lookup remote \{@link RemoteCalc}.
> *
> * @return a \{@link RemoteCalc} object
> * @throws NamingException Something is wrong
> */
> public static RemoteCalc getRemoteCalc() throws NamingException {
> Hashtable<String, Object> jndiProps = new Hashtable<>();
> jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> // remote+http connection (work fine)
> //jndiProps.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080/remote-ejb");
> // http connection (fail)
> jndiProps.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/wildfly-services");
> Context context = new InitialContext(jndiProps);
> return (RemoteCalc) context.lookup(REMOTE_CALC);
> }
> /**
> * Call to run (main).
> *
> * @param args parameters (not used)
> * @throws NamingException Something is wrong
> */
> public static void main(String[] args) throws NamingException {
>
> RemoteCalc remoteCalc = getRemoteCalc();
> System.out.println("Remote calc 95 + 76: " + remoteCalc.add(95, 76));
> }
> }
> {code}
> Exception:
> Exception in thread "main" javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "http"
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> at javax.naming.InitialContext.lookup(Unknown Source)
> at com.bosch.emea.bpart.remoteejbclient.Application.getRemoteCalc(Application.java:34)
> at com.bosch.emea.bpart.remoteejbclient.Application.main(Application.java:47)
> Lib:
> {code:java}
> @Remote
> public interface RemoteCalc {
> /**
> * Add two integer.
> *
> * @param a an integer
> * @param b an integer
> * @return a + b
> */
> public int add(int a, int b);
>
> }
> {code}
> Config:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="default" />
> </authentication-rules>
> <authentication-configurations>
> <configuration name="default">
> <sasl-mechanism-selector selector="#ALL" />
> <set-mechanism-properties>
> <property key="wildfly.sasl.local-user.quiet-auth" value="true" />
> </set-mechanism-properties>
> <providers>
> <use-service-loader/>
> </providers>
> </configuration>
> </authentication-configurations>
> </authentication-client>
> </configuration>
> {code}
> Maven dependency:
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-ejb-client-bom</artifactId>
> <version>20.0.0.Final</version>
> <type>pom</type>
> </dependency>
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13641) WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-13641?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-13641:
--------------------------------------
Hi,
so, you have two deployments, an EAR (with lib) and then a separate WAR. WAR declares a dep on EAR/lib via {{jboss-deployment-structure.xml}}. Do I get that right?
Fairly speaking, I am not familiar with how this should (if it should) work together. An opinion of someone well-versed in this would be nice - e.g. can you even load the jandex index of a completely different deployment?
Looking at {{ExtenalBeanArchiveProcessor}}, [the code|https://github.com/wildfly/wildfly/blob/20.0.0.Final/weld/subsystem/...] you mention means that we are unable to load the Jandex index, hence we try to create it on the fly and fail there as well.
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13641
> URL: https://issues.redhat.com/browse/WFLY-13641
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.0.Final
> Reporter: Jens Viebig
> Assignee: Matěj Novotný
> Priority: Major
>
> When referencing a jar with CDI scan mode "annotaded" inside an ear from an external war via jboss-deployment-structure.xml a warning will be printed for every class:
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> Seems VFS cannot get hold of the classes.
> The warning is logged in ExternalBeanArchiveProcessor which catches an EOFException from the inputstream loading the class. (Line 284). Seems the input stream is not able to load a single byte from the class
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months