[JBoss JIRA] (WFCORE-3466) Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
by David Lloyd (JIRA)
David Lloyd created WFCORE-3466:
-----------------------------------
Summary: Add reflection option to org.jboss.as.controller.parsing.ExtensionParsingContext
Key: WFCORE-3466
URL: https://issues.jboss.org/browse/WFCORE-3466
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: David Lloyd
As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to {{ExtensionParsingContext}} which allowed a supplier of a parser to be provided.
This has resulted in an explosion of lambda usage; around 150 calls to this method exist, most of which supply constructor references as the {{Supplier}} argument.
We can theoretically save considerable metaspace by doing one of the following:
* Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate the parser on demand
* Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in this way to construct instances
Performance impact should be very minimal, as the overhead of calling a constructor is less than that of compiling a method reference, and the overhead in metaspace is nearly non-existent in comparison.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-9539) wsconsume.sh does not support the -secmgr setting properly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9539?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-9539:
--------------------------------------
Fix Version/s: 12.0.0.Alpha1
Assignee: R Searls (was: Tomaz Cerar)
Resolution: Done
> wsconsume.sh does not support the -secmgr setting properly
> ----------------------------------------------------------
>
> Key: WFLY-9539
> URL: https://issues.jboss.org/browse/WFLY-9539
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Affects Versions: 10.0.0.Final
> Reporter: R Searls
> Assignee: R Searls
> Fix For: 12.0.0.Alpha1
>
>
> wsconsume.sh, and wsconsume.bat does not properly support the -secmgr flag in the
> generated command. Changes to jboss-module.jar requires the -secmgr flag be positioned
> immediately after the jboss-module.jar declaration.
> {code:java}
> eval \"$JAVA\" $JAVA_OPTS \
> -classpath \""$JBOSS_CLASSPATH"\" \
> org.jboss.modules.Main \
> -secmgr \
> -mp \""$JBOSS_HOME"/modules\" \
> org.jboss.ws.tools.wsconsume \
> '"$@"'
> {code}
> This value is pass to this utility via the JAVA_OPTS env variable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-9538) wsprovide.sh does not support the -secmgr setting properly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9538?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-9538:
--------------------------------------
Assignee: R Searls (was: Tomaz Cerar)
> wsprovide.sh does not support the -secmgr setting properly
> ----------------------------------------------------------
>
> Key: WFLY-9538
> URL: https://issues.jboss.org/browse/WFLY-9538
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.0.0.Final
> Reporter: R Searls
> Assignee: R Searls
>
> wsprovide.sh, wsprovide.bat does not generate the cmd with the -secmgr flag in the
> proper position. Changes to jboss-module.jar requires -segmgr to reside just after
> the jboss-module.jar reference like this.
> {code:java}
> eval \"$JAVA\" $JAVA_OPTS \
> -jar \""$JBOSS_HOME"/jboss-modules.jar\" \
> *-secmgr \ *
> -mp \""$JBOSS_HOME"/modules\" \
> org.jboss.ws.tools.wsprovide \
> '"$@"'
> {code}
> Current the old style and this new style value is passed in via the JAVA_OPTS env var.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not being created
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7247.
----------------------------------
Resolution: Duplicate Issue
Fixed under WFLY-8774
> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
> Key: WFLY-7247
> URL: https://issues.jboss.org/browse/WFLY-7247
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: M Wardell
> Assignee: Stuart Douglas
>
> Found on wildfly 10.1 and 10.0. With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism. Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup. After most startups the JESSSIONIDSSO is reliably generated during login. After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-283:
---------------------------------
That implies that the invalid free is happening inside the GSS library's gss_accept_sec_context function ({{*ftab}} contains a list of functions that are loaded via {{dlsym}} from the target GSS library). It could be a bug in the library, or a parameter that has an invalid value, among other things. You'd have to attach a debugger to know for sure, but that likely will not work unless you have a {{fastdebug}} OpenJDK build on hand...
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
> Attachments: openjdk-patch-native-mechs.patch
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-283:
--------------------------------
[~dmlloyd] By traces the crash occurs in GSSLibStub.c during call acceptSecContext:
{code}
major =
(*ftab->acceptSecContext)(&minor, &contextHdl, credHdl,
&inToken, cb, &srcName, &aMech, &outToken,
&aFlags, &aTime, &delCred);
{code}
(to be sure I have placed TRACE directly before and after - yet before deleteGSSCB/resetGSSBuffer - the crash occures directly in acceptSecContext)
{code}
21:08:34,181 INFO [stdout] (management I/O-2) Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt false ticketCache is null isInitiator false KeyTab is /home/jkalina/work/tutorial-kerberos/kerberos-using-apacheds/remote.keytab refreshKrb5Config is false principal is remote/localhost(a)JBOSS.ORG tryFirstPass is false useFirstPass is false storePass is false clearPass is false
21:08:34,185 INFO [stdout] (management I/O-2) principal is remote/localhost(a)JBOSS.ORG
21:08:34,186 INFO [stdout] (management I/O-2) Will use keytab
21:08:34,186 INFO [stdout] (management I/O-2) Commit Succeeded
21:08:34,186 INFO [stdout] (management I/O-2)
21:08:34,191 INFO [stdout] (management I/O-2) SunNativeGSS: Created GSSLibStub for mech 1.2.840.113554.1.2.2
[GSSLibStub_importName]
[GSSLibStub_importName] 139984261540048
[GSSLibStub_displayName] 139984261540048
21:08:34,194 INFO [stdout] (management I/O-2) SunNativeGSS: Imported remote/localhost(a)JBOSS.ORG w/ type 1.2.840.113554.1.2.1.1
21:08:34,207 INFO [stdout] (management I/O-2) Search Subject for Kerberos V5 ACCEPT cred (remote/localhost(a)JBOSS.ORG, sun.security.jgss.wrapper.GSSCredElement)
[GSSLibStub_acquireCred]
[GSSLibStub_acquireCred] pName=139984261540048, usage=2
[GSSLibStub_acquireCred] [!JK1!] major=0 minor=0
[GSSLibStub_acquireCred] pCred=139984261571568
[GSSLibStub_acquireCred] [!JK2!] major=0 minor=0
21:08:34,244 INFO [stdout] (management task-1) SunNativeGSS: Precomputed mechToken length: 500
21:08:34,245 INFO [stdout] (management task-1) SunNativeGSS: Complete Token length: 515
21:08:34,245 INFO [stdout] (management task-1) SunNativeGSS: acceptSecContext=> inToken len=515
[GSSLibStub_acceptContext]
[GSSLibStub_acceptContext] before2: pCred=139984261571568, pContext=0
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f51050212b2, pid=12158, tid=12329
#
# JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-adhoc.jkalina.9dev)
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.jkalina.9dev, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C [libc.so.6+0x932b2] cfree+0x32
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e" (or dumping to /home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/core.12158)
#
# An error report file with more information is saved as:
# /home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/hs_err_pid12158.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
bin/standalone.sh: line 311: 12158 Aborted (core dumped) "java" -D"[Standalone]" -server -Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.jgss.lib=/usr/lib64/libgssapi_krb5.so.2.2 -Dsun.security.jgss.native=true -Dsun.security.nativegss.debug=true -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n "-Dorg.jboss.boot.log.file=/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/standalone/log/server.log" "-Dlogging.configuration=file:/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/standalone/configuration/logging.properties" -jar "/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/jboss-modules.jar" -mp "/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/modules" org.jboss.as.standalone -Djboss.home.dir="/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT" -Djboss.server.base.dir="/home/jkalina/work/tutorial-kerberos/wildfly-11.0.0.Final-SNAPSHOT/standalone"
{code}
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
> Attachments: openjdk-patch-native-mechs.patch
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (DROOLS-2182) NPE when @Expires is missing on event type
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2182?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2182.
---------------------------------
Resolution: Cannot Reproduce Bug
I definitively cannot reproduce the NPE you reported. If you have a reproducer feel free to attach it to this ticket and reopen it.
> NPE when @Expires is missing on event type
> ------------------------------------------
>
> Key: DROOLS-2182
> URL: https://issues.jboss.org/browse/DROOLS-2182
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.5.0.Final
> Reporter: Christian Bauer
> Assignee: Mario Fusco
>
> This code in {{ClassObjectTypeConf}} assumes that an event class always has an @Expires annotation, which is optional:
> {code}
> Role role = clazz.getAnnotation(Role.class);
> if (role != null) {
> isEvent = role.value() == Type.EVENT;
> if (isEvent) {
> Expires expires = clazz.getAnnotation(Expires.class);
> expirationOffset = TimeIntervalParser.parseSingle( expires.value() );
> }
> }
> {code}
> {code}
> java.lang.NullPointerException
> at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:99)
> at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:69)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:181)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1493)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1453)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1447)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-929) AuthenticationConfiguration uniqueness enhancements
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-929:
---------------------------------
The purpose is so that new instances of the callback handler can be instantiated for each outbound authentication usage, instead of using one callback handler which is shared for every authentication configuration.
However, this relies on some fragile semantics on behalf of the authentication context client: do we construct a new callback handler on every authentication attempt, or do we keep them around to be reused for all authentications for the same session or endpoint? What semantics can the user expect from callback handlers constructed in this way? These questions need to be answered definitively before we can do this.
Also, we have to consider equals/hashCode behavior. In order to reliably cache connections, protocol implementors need the ability to know if a second usage is using the same configuration as a first usage, to know if a separate authentication must be performed or if an existing authentication can be reused. Using Supplier invites lambdas, which have problematic equals/hashCode behavior, potentially breaking this contract and causing many unnecessary authentications to be performed.
> AuthenticationConfiguration uniqueness enhancements
> ---------------------------------------------------
>
> Key: ELY-929
> URL: https://issues.jboss.org/browse/ELY-929
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client
> Reporter: David Lloyd
> Fix For: 1.2.0.Beta12
>
>
> Apply some enhancements to AuthenticationConfiguration uniqueness.
> * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler
> The following also may be possible and useful:
> * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}}
> * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes
by David Lloyd (JIRA)
David Lloyd created LOGTOOL-132:
-----------------------------------
Summary: Support low-metaspace bundles/classes
Key: LOGTOOL-132
URL: https://issues.jboss.org/browse/LOGTOOL-132
Project: Log Tool
Issue Type: Enhancement
Reporter: David Lloyd
Priority: Critical
Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
Introduce a leaner variation on generated classes with the following requirements:
* The generated class must be {{final}}
* The generated class must contain no message strings
* The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
* The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
Here are some implementation ideas:
* Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
* Option 2: The resource files contain key-value pairs, with the key being equal to the method name
** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months