[JBoss JIRA] (WFLY-9417) No default-response-code during deployment sent
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9417?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9417:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> No default-response-code during deployment sent
> -----------------------------------------------
>
> Key: WFLY-9417
> URL: https://issues.jboss.org/browse/WFLY-9417
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.CR1
> Reporter: Nero M
> Assignee: Stuart Douglas
> Fix For: 12.0.0.Final
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Hi, i am experiencing a strange behaviour with WF11 which was not like this on WF10.
> When a *.dodeploy file exists during server-start. The Default response code
> e.g.
> <host name="default-host" alias="localhost" default-response-code="503">
> Is not sent during the time of deployment. Instead any requests goes into a pending state with (seemingly) no timeout.
> If the *.dodeploy file is created AFTER the server boots up, the default response code is sent until the deployment is complete.
> (After this line): WFLYSRV0025: WildFly Full 11.0.0.CR1 (WildFly Core 3.0.4.Final) started in 6468ms
> I think the server should not "hang" during the deployment-time, just like it was on WF10.
> Is there anything which has to be changed in the standalone xml between 10 and 11 to get the same behaviour?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9415) Add test cases to cover EJB client clustered session creation
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9415?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9415:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Add test cases to cover EJB client clustered session creation
> -------------------------------------------------------------
>
> Key: WFLY-9415
> URL: https://issues.jboss.org/browse/WFLY-9415
> Project: WildFly
> Issue Type: Task
> Components: Clustering, Test Suite
> Affects Versions: 11.0.0.CR1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 12.0.0.Final
>
>
> EJB client session creation involves creating a proxy for a SFSB deployed on a remote server, which has the side effect of creating a session instance on the chosen target node.
> Whether or not the operation is successful depends on three factors:
> * the connections defined in the EJB client configuration
> * the server environment in which the client is executing
> * any strong affinity set by the client
> These tests consider session creation in a clustered environment. The default server environment is a cluster called "ejb" with two nodes, "node-0" and "node-1".
> The following test scenarios are covered:
> 1. "normal" scenario
> * client configuration: points to node-0
> * server environment: module deployed on cluster "ejb" = {node-0, node-1}
> 2. "failover" scenario
> * client configuration: points to node-0
> * server environment: module deployed on cluster "ejb" = {node-1}
> 3. "bad connection" scenario
> * client configuration: points to node-2 (non-existent)
> * server environment: module deployed on cluster "ejb" = {node-0, node-1}
> As mentioned earlier, these tests operate in a single two-node cluster environment. A third singleton, non-clustered node added to the available environment would permit more complex scenarios (where we could test cluster affinity specification more directly).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9702:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> SSO Integration for Programmatic Authentication
> -----------------------------------------------
>
> Key: WFLY-9702
> URL: https://issues.jboss.org/browse/WFLY-9702
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Security, Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 12.0.0.Final
>
>
> At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication.
> In this scenario we don't have either a wrapped mechanism or a CallbackHandler.
> Couple of options: -
> * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on.
> * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication?
> * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process.
> *
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9604) wildfly-11.0.0.Final JPA
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9604?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9604:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> wildfly-11.0.0.Final JPA
> ------------------------
>
> Key: WFLY-9604
> URL: https://issues.jboss.org/browse/WFLY-9604
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Javaee 7, Windows 7, jdk 8 151
> Reporter: Trond Arild Lode Tobiassen Heidelberg
> Labels: task
> Fix For: 12.0.0.Final
>
>
> I am deploying to above. I get this error message:
>
> {"jboss.persistenceunit.registrar#REGDB" => "org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type Caused by: org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type"},
>
>
> I have this code:
>
> @OneToOne(optional = true, cascade = CascadeType.ALL, targetEntity = AbstractPart.class)
> @JoinColumn(name = "PART", unique = false, nullable = true, updatable = false)
> protected X part;
> What about the target= vs the targetEntity=? There is no target attribute or @Type annotation available.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9595) Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9595?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9595:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Incorrect Journal filesize calculation where specified size is lest that the block size when using AIO
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9595
> URL: https://issues.jboss.org/browse/WFLY-9595
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Jeff Mesnil
> Fix For: 12.0.0.Final
>
>
> This issue was discovered as a side effect of: -
> https://github.com/wildfly/wildfly/commit/df9e16241207ebc412ddd16c790c4b7...
> This change updated the size to be 1024 for the tests as a large file was not necessary. For continuous integration the agents have a blocksize of 512 so as the configured size is a multiple of the blocksize this was fine.
> However running the test 'org.jboss.as.test.integration.domain.ExpressionSupportSmokeTestCase' on a machine with a blocksize of 4096 this test would fail as the servers would fail to boot.
> After some debugging it became aparant this was the underlying error: -
> {noformat}
> {"jboss.messaging-activemq.default.jms.manager" => "java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes
> Caused by: java.lang.IllegalArgumentException: File size cannot be less than 1024 bytes"}
> {noformat}
> After further debugging I have tracked it down to this class 'org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager' - I can confirm the configured value does make it to this class but it is the following block of code which then looses the value: -
> {code:java}
> int fileSize = config.getJournalFileSize();
> // we need to correct the file size if its not a multiple of the alignement
> int modulus = fileSize % journalFF.getAlignment();
> if (modulus != 0) {
> int difference = modulus;
> int low = config.getJournalFileSize() - difference;
> int high = low + journalFF.getAlignment();
> fileSize = difference < journalFF.getAlignment() / 2 ? low : high;
> ActiveMQServerLogger.LOGGER.invalidJournalFileSize(config.getJournalFileSize(), fileSize, journalFF.getAlignment());
> }
> Journal localMessage = new JournalImpl(ioExecutors, fileSize, config.getJournalMinFiles(), config.getJournalPoolFiles(), config.getJournalCompactMinFiles(), config.getJournalCompactPercentage(), journalFF, "activemq-data", "amq", journalFF.getMaxIO(), 0);
> {code}
> The file size comes in as 1024, the default is AIO so getAlignment returns the blocksize which in this case is 4096. So modulus and subsequently difference become 1024.
> The file size and difference are both 1024 so low becomes 0, high becomes 4096. Due to the difference being less than half the block size low is selected and the file size is set to 0.
> To select a correct filesize it looks like if low is less than the alignment always select high should be an option.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9801) Wsprovide tool ends with java.security.AccessControlException
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9801?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9801:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Wsprovide tool ends with java.security.AccessControlException
> -------------------------------------------------------------
>
> Key: WFLY-9801
> URL: https://issues.jboss.org/browse/WFLY-9801
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Reporter: Marek Kopecký
> Assignee: R Searls
> Priority: Critical
> Fix For: 12.0.0.Final
>
> Attachments: Echo1-security.policy, Echo1.class, Echo1Impl.class
>
>
> *Description of the issue:*
> wsprovide tool ends with java.security.AccessControlException
> I see this issue on WF master (2018_02_12). This is regression against WF master from 2018_02_05, so priority of this jira is blocker.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # Use these (class files are attached):
> {code:java}
> @WebService(endpointInterface = "org.jboss.as.testsuite.integration.scripts.test.tools.Echo1", targetNamespace = "org.jboss.as.testsuite.integration.scripts.test.tools", serviceName = "Echo1Service")
> public class Echo1Impl implements Echo1 {
> @Override
> public String echoPlus1(String s) {
> return s + "1";
> }
> }
> {code}
> {code:java}
> @WebService
> @SOAPBinding
> public interface Echo1 {
> String echoPlus1(String s);
> }
> {code}
> # cd $\{JBOSS_HOME\}/bin
> # mkdir out
> # ./wsprovide.sh -k -c $\{CLASS_DIR\} -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> *Actual results:*
> {noformat}
> [mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase2 -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> java2ws -s /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -classdir /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -d /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -verbose -cp /home/mkopecky/erase2/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> java2ws - Apache CXF 3.2.2
> java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1Response.java" "read")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.isDirectory(File.java:844)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:202)
> at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generateAndCompile(BeanGenerator.java:91)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:58)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:35)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.generate(JavaToWSDLProcessor.java:156)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:118)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:45)
> at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:83)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:200)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:109)
> at org.jboss.ws.tools.cmd.WSProvide.generate(WSProvide.java:223)
> at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:89)
> at org.jboss.modules.Module.runMainMethod(Module.java:348)
> at org.jboss.modules.Module.run(Module.java:328)
> at org.jboss.modules.Main.main(Main.java:557)
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months