[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: 13.0.0.Beta1
(was: 12.0.0.Final)
> 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: 13.0.0.Beta1
>
> 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
[JBoss JIRA] (WFLY-9561) HttpServletRequest.login(username, password) not creating HttpSession if it doesn't already exist. (Elytron)
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9561:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> HttpServletRequest.login(username, password) not creating HttpSession if it doesn't already exist. (Elytron)
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9561
> URL: https://issues.jboss.org/browse/WFLY-9561
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Stanislav Grushevskiy
> Assignee: Darran Lofthouse
> Fix For: 13.0.0.Beta1
>
> Attachments: test.zip
>
>
> If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
> @Path("login")
> public class LoginService {
> @Context
> private HttpServletRequest request;
> @POST
> public void login(LoginForm form) throws ServletException {
> request.login(form.getLogin(), form.getPassword());
> }
> }
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>application-security-domain</security-domain>
> </jboss-web>
> If I add manual interaction with Session in login method, "JSESSIONID" is set.
> OR
> If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
> "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
> Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
> Run "mvn wildfly:deploy".
> Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
> In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (WFLY-9489) Remove need for application-security-domain mapping
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9489?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9489:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> Remove need for application-security-domain mapping
> ---------------------------------------------------
>
> Key: WFLY-9489
> URL: https://issues.jboss.org/browse/WFLY-9489
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 13.0.0.Beta1
>
>
> The application-security-domain resource was added to map from the security domain specified within the deployment to a WildFly Elytron authentication factory with some additional related configuration.
> It should be possible to define all of this within a deployment descriptor.
> Additionally the subsystem includes a default-security-domain attribute, it should likely contain some default Elytron configuration options.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[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: 13.0.0.Beta1
(was: 12.0.0.Final)
> 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: 13.0.0.Beta1
>
>
> 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
[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: 13.0.0.Beta1
(was: 12.0.0.Final)
> 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: 13.0.0.Beta1
>
>
> 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