[JBoss JIRA] (WFLY-8512) Private undertow capability service values expose org.jboss.msc.service.Service methods
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8512?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-8512:
---------------------------------
Assignee: (was: Tomaz Cerar)
> Private undertow capability service values expose org.jboss.msc.service.Service methods
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8512
> URL: https://issues.jboss.org/browse/WFLY-8512
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Priority: Minor
>
> Undertow new exposes UndertowService, Server, Host, etc. to other subsystems as service values of public capabilities. However, these objects all implement Service, and thus expose start/stop methods to their dependents. This is poor encapsulation. Ideally, we should extract interfaces from these objects such that the corresponding capabilities only expose methods in explicitly in their contract.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9577) Upgrade procrun to latest version
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9577?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-9577:
------------------------------
Summary: Upgrade procrun to latest version (was: Application Error when stopping Windows service)
> Upgrade procrun to latest version
> ---------------------------------
>
> Key: WFLY-9577
> URL: https://issues.jboss.org/browse/WFLY-9577
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: Windows 10, Windows Server 2012 R2
> Reporter: Markus Stier
> Assignee: Tomaz Cerar
>
> I've installed Wildflay as a Windows Service using the provided scripts in <Root>\docs\contrib\scripts\service. When stopping the windows service with
> {code}
> net stop <servicename>
> {code}
> the service terminates with an application error 1000.
> {code}
> Name der fehlerhaften Anwendung: wildfly-service.exe, Version: 1.0.15.0, Zeitstempel: 0x51543b9d
> Name des fehlerhaften Moduls: ntdll.dll, Version: 6.3.9600.18821, Zeitstempel: 0x59ba86db
> Ausnahmecode: 0xc0000005
> Fehleroffset: 0x00000000000356a0
> ID des fehlerhaften Prozesses: 0x608
> Startzeit der fehlerhaften Anwendung: 0x01d3637dd37fa9c8
> Pfad der fehlerhaften Anwendung: ....\wildfly-service.exe
> Pfad des fehlerhaften Moduls: C:\Windows\SYSTEM32\ntdll.dll
> Berichtskennung: ee6df2e2-d0eb-11e7-80e2-00505698739a
> {code}
> This is a known bug in the Apache Commons Daemon Service Runner version which is used in the wildfly distribution. See https://issues.apache.org/jira/browse/DAEMON-336
> The bug is fixed in version 1.1.x. Please update the Daemon Service to this version.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-2260) Validate presence of required attributes in PersistentResourceXmlParser/Description
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2260?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-2260:
-----------------------------------
Assignee: (was: Tomaz Cerar)
> Validate presence of required attributes in PersistentResourceXmlParser/Description
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2260
> URL: https://issues.jboss.org/browse/WFCORE-2260
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
>
> One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.
> See JBEAP-8437 for an example of where that no longer happens.
> Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand. (Of course being generic is a great advantage once it's done right since it gets applied consistently.)
> Things that generic support would need to understand:
> 1) Attributes with alternatives are not required if the alternative is set.
> 2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.
> Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)
> This is NOT meant for WildFly Core 3.0.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10091) GC logging is not working on Java 9
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10091?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFLY-10091:
----------------------------------
Assignee: (was: Tomaz Cerar)
> GC logging is not working on Java 9
> -----------------------------------
>
> Key: WFLY-10091
> URL: https://issues.jboss.org/browse/WFLY-10091
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Reporter: Rostislav Svoboda
> Priority: Blocker
>
> GC logging is not working on Java 9. This is related to the fact G1 GC is default and there are changes in configuration option.
> {code}
> GC_LOG="true" ./standalone.sh
> {code}
> Java 8:
> {code}
> JAVA_OPTS: -server -verbose:gc -Xloggc:"/Users/rsvoboda/TESTING/7.2.0.CD12.CR1/jboss-eap-7.2/standalone/log/gc.log"
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5
> -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M
> -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
> Java 9:
> {code}
> JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-8817) The jboss.dist system property is not used in testsuite/integration/elytron module
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8817?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-8817.
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 11.0.0.Final)
Resolution: Done
> The jboss.dist system property is not used in testsuite/integration/elytron module
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8817
> URL: https://issues.jboss.org/browse/WFLY-8817
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Josef Cacek
> Assignee: Tomaz Cerar
> Priority: Critical
> Fix For: 12.0.0.Final
>
>
> Elytron testsuite module doesn't work correctly with the {{jboss.dist}} system property.
> The {{jboss.dist}} system property is used by QE to run the AS testsuite against the correct bits (e.g. comming from PROD team). The {{testsuite/integration/elytron}} module seems not to be taking this property into account. It seems it always uses output of {{wildfly-server-provisioning-maven-plugin}} to test against.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month