[JBoss JIRA] (WFCORE-3307) Parameters passed to standalone.sh are not printed on startup
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3307?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-3307:
-----------------------------------
Assignee: James Perkins (was: Tomaz Cerar)
> Parameters passed to standalone.sh are not printed on startup
> -------------------------------------------------------------
>
> Key: WFCORE-3307
> URL: https://issues.jboss.org/browse/WFCORE-3307
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 3.0.3.Final
> Environment: linux / windows
> Reporter: kobogian hitis
> Assignee: James Perkins
> Priority: Minor
>
> Parameters passed to standalone.sh should also be printed on startup (like JAVA_OPTS).
> Actually I think something like the output of `ps aux | grep "org.jboss.as.standalone"` should also be printed, when jboss starts.
> Not printing them causes confusion between what is printed and what is actually applied.
> If for example someone runs this: `standalone.sh -Djboss.socket.binding.port-offset=100` and at the same time `-Djboss.socket.binding.port-offset=0` exists in JAVA_OPTS, then the latter will be printed but the first will be used.
> Someone might argue about setting only JAVA_OPTS before running standalone.sh.
> The reason I avoid setting JAVA_OPTS is that if I set them before running standalone.sh, then the default Wildfly opts (-Djava.net.preferIPv4Stack=true" -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true") are never used, which causes other problems. This could be a bug byitself, but for now I consider it as expected behaviour.
> So the most clean approach that I see for setting options in a single place (both with -D and custom flags (e.g. -b)) is appending them as params to standalone.sh (e.g. inside a wrapper script myapp-run.sh).
> It should be possible however to be able to see them being printed somewhere.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFCORE-1828) Make it easier to register add and remove handlers with customized definitions
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1828?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-1828:
-----------------------------------
Assignee: (was: Tomaz Cerar)
> Make it easier to register add and remove handlers with customized definitions
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1828
> URL: https://issues.jboss.org/browse/WFCORE-1828
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> The nice way to build up a ResourceDefinition is with the Parameters object. And that works well with most add and remove handlers where the RD when building up the MRR generates a definition for the handlers.
> But in cases where there needs to be some customization of the add description (e.g. deployment(-overlay) add where the content param can have fields that are not used in the content attribute) then the only option is in some way or other to override registerOperations. That or have the add OSH implement DescriptionProvider. Which we don't want. ;)
> Perhaps add setAddDescription/setRemoveDescription to Parameters, or
> {code}
> public interface SelfDescibingOperationStepHandler extends OperationStepHandler {
> OperationDefinition getDefinition();
> }
> {code}
> Enhancing Parameters sound better.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFLY-4051) Use descriptive error message for duplicate host/context deployments
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4051?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4051:
---------------------------------
Assignee: (was: Tomaz Cerar)
> Use descriptive error message for duplicate host/context deployments
> --------------------------------------------------------------------
>
> Key: WFLY-4051
> URL: https://issues.jboss.org/browse/WFLY-4051
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Priority: Minor
>
> If a user attempts to deploy a web application to a host/context to which another application is deployed, this will fail for obvious reasons.
> What isn't obvious is the error message. Currently, users will see a DuplicateServiceException. Ideally, the error message should indicate that another application is deployed for the same host and context path.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFCORE-2925) Separate heap settings in standalone.conf and domain.conf from rest of JAVA_OPTS
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2925?page=com.atlassian.jira.plugi... ]
Tomaz Cerar reassigned WFCORE-2925:
-----------------------------------
Assignee: James Perkins (was: Tomaz Cerar)
> Separate heap settings in standalone.conf and domain.conf from rest of JAVA_OPTS
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2925
> URL: https://issues.jboss.org/browse/WFCORE-2925
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: James Perkins
>
> Let's do this:
> {code}
> if [ "x$JBOSS_JAVA_SIZING" = "x" ]; then
> JBOSS_JAVA_SIZING="-Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m"
> fi
> if [ "x$JAVA_OPTS" = "x" ]; then
> JAVA_OPTS="$JBOSS_JAVA_SIZING -Djava.net.preferIPv4Stack=true"
> JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
> else
> echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
> fi
> {code}
> That will allow users to easily control memory sizing by setting that specific env var externally while still relying on our defaults for all the other fussy stuff in JAVA_OPTS.
> The JBOSS_JAVA_SIZING name was 20 secs of thought on my part.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFLY-7366) Remove PicketLink
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7366?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-7366:
---------------------------------
Assignee: (was: Tomaz Cerar)
> Remove PicketLink
> -----------------
>
> Key: WFLY-7366
> URL: https://issues.jboss.org/browse/WFLY-7366
> Project: WildFly
> Issue Type: Task
> Components: Security
> Reporter: Tomaz Cerar
>
> Subsystem should be removed in same way we did it with all legacy subsystems like web, messaging, cmp and others.
> This way it would still be possible to manage EAP6.4 hosts with EAP 7.1 domain controller that use picketlink.
> PicketLink subsystem was never supported in EAP, it was added in EAP 6.3 but as unsupported feature.
> in 6.4 it was also deprecated and marked for removal, as such it stayed also in 7.0.
> It was never officially supported in any of EAP releases and it would make sense to remove it in 7.1 as KeyCloak / RH SSO took over as main project/product for single sign on
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months