[JBoss JIRA] (JBEE-190) AuthConfigFactory.getFactory() checking wrong permission.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/JBEE-190?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on JBEE-190:
---------------------------------------
Also if a global factory does not already exist the setFactorySecurityPermission is also required.
> AuthConfigFactory.getFactory() checking wrong permission.
> ---------------------------------------------------------
>
> Key: JBEE-190
> URL: https://issues.jboss.org/browse/JBEE-190
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jaspi-api
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> The method currently performs the following check: -
> {code:java}
> //Validate the caller permission
> SecurityManager sm = System.getSecurityManager();
> if (sm != null)
> sm.checkPermission(new SecurityPermission("getFactory"));
> {code}
> However it is supposed to be using 'getFactorySecurityPermission'.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10092) Wildfly 12 @WebListener don't work
by Wagner Araujo (JIRA)
Wagner Araujo created WFLY-10092:
------------------------------------
Summary: Wildfly 12 @WebListener don't work
Key: WFLY-10092
URL: https://issues.jboss.org/browse/WFLY-10092
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 12.0.0.Final
Environment: Linux Mint 18.3 64 bits
Reporter: Wagner Araujo
Annotation @WebListener don't work, but declaration into web.xml work.
{color:red}{color:#d04437}
DON'T WORK
@WebListener
public class SessaoListener implements HttpSessionListener {
@Inject
private MultiTenant multiTenant;
@Override
public void sessionCreated(HttpSessionEvent httpSessionEvent) {
Locale.setDefault(new Locale("pt", "BR","" + multiTenant.get()));
}
@Override
public void sessionDestroyed(HttpSessionEvent arg0) {
//
}
}{color}{color}
{color:#14892c}
BUT INTO WEB.XML WORK
web.xml
<listener>
<listener-class>br.com.jarch.treinamento.listener.ContextoListener</listener-class>
</listener>
<listener>
<listener-class>br.com.jarch.treinamento.listener.SessaoListener</listener-class>
</listener>
{color}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3707) Logging subsystem does not include the correct restart flag in the subsystems definition
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3707?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3707:
----------------------------------
Summary: Logging subsystem does not include the correct restart flag in the subsystems definition (was: Logging subsystem does not include the correct restart flag in the subsystems description)
> Logging subsystem does not include the correct restart flag in the subsystems definition
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-3707
> URL: https://issues.jboss.org/browse/WFCORE-3707
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> The logging subsystem add handler does not extend the {{AbstractBoottimeAddStepHandler}} and therefore must add the restart level flag. Either the {{LoggingSubsystemAdd}} operation handler needs to extend the {{AbstractBoottimeAddStepHandler}} or the {{LoggingResourceDefinition}} needs to include the restart level flag.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBEE-190) AuthConfigFactory.getFactory() checking wrong permission.
by Darran Lofthouse (JIRA)
Darran Lofthouse created JBEE-190:
-------------------------------------
Summary: AuthConfigFactory.getFactory() checking wrong permission.
Key: JBEE-190
URL: https://issues.jboss.org/browse/JBEE-190
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-jaspi-api
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
The method currently performs the following check: -
{code:java}
//Validate the caller permission
SecurityManager sm = System.getSecurityManager();
if (sm != null)
sm.checkPermission(new SecurityPermission("getFactory"));
{code}
However it is supposed to be using 'getFactorySecurityPermission'.
--
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 Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10091?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda updated WFLY-10091:
-------------------------------------
Description:
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}
was:
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}
jboss-eap-7.2/bin/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}
> 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
> Assignee: Tomaz Cerar
> 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-10091) GC logging is not working on Java 9
by Rostislav Svoboda (JIRA)
Rostislav Svoboda created WFLY-10091:
----------------------------------------
Summary: 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
Assignee: Tomaz Cerar
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}
jboss-eap-7.2/bin/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] (JGRP-2259) Configurator.removeDeprecatedProperties(...) should check for @Deprecated
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-2259?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed JGRP-2259.
------------------------------
Resolution: Rejected
Nevermind - properties containing a deprecated message are already logged in resolveAndAssignField(...), which should be sufficient..
> Configurator.removeDeprecatedProperties(...) should check for @Deprecated
> -------------------------------------------------------------------------
>
> Key: JGRP-2259
> URL: https://issues.jboss.org/browse/JGRP-2259
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Reporter: Paul Ferraro
> Assignee: Bela Ban
>
> Configurator.removeDeprecatedProperties(...) removes and logs warnings for any configuration properties annotated with @DeprecatedProperty. However, this annotation is no longer in use anywhere. However, deprecated properties are consistently annotated with @Deprecated, and thus should be detected as such.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar reopened JGRP-2253:
----------------------------------
I would like to reopen this case. In AWS environment sometimes the FD_SOCK is not working when we kill the process using kill-9 or while terminating the EC2 instance from the console.
Most of the times, It detects the connection breakage immediately with in 3 seconds post crashing the node ( e.g kill -9 -> not gracefully shutting down a node from the cluster).
Sometimes, it do not detect immediately. it takes up to 12 to 13 seconds. So I am assuming that FD configurations are helping to detect the node failure instead of FD SOCK in this case.
There are no warnings related to FD SOCK in the log files.
TCP: Configurations
jgroup-ext-addr is the IP address of the each nodes.
<TCP
external_addr="${jgroup-ext-addr}"
bind_addr="match-interface:eth0"
bind_port="7803"
port_range="0"
diagnostics_port="7806"
recv_buf_size="20M"
send_buf_size="10M"
max_bundle_size="64k"
enable_diagnostics="true"
thread_naming_pattern="cl"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="16"
thread_pool.keep_alive_time="5000" />
FD protocols:
<FD_SOCK start_port="7804" external_addr="${jgroup-ext-addr}" bind_addr="match-interface:eth0" client_bind_port="7805"/>
<FD timeout="3000" max_tries="3" />
<VERIFY_SUSPECT timeout="3000" />
Thanks
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10060) wsconsume script is not working on JDK9+
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10060?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-10060:
------------------------------------
I suggested that maybe {{javaee.api}} would be a good choice. Maybe it's overkill, but OTOH we'd never have a problem like this again. :)
> wsconsume script is not working on JDK9+
> ----------------------------------------
>
> Key: WFLY-10060
> URL: https://issues.jboss.org/browse/WFLY-10060
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Affects Versions: 12.0.0.Final
> Reporter: Jan Blizňák
> Assignee: R Searls
> Attachments: mywsdl2java
>
>
> wsconsume script is not working on JDK9/10/11
> {code:java}
> [jbliznak@rh wildfly-13.0.0.Alpha1-SNAPSHOT]$ java -version
> java version "9.0.4"
> Java(TM) SE Runtime Environment (build 9.0.4+11)
> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
> [jbliznak@rh wildfly-13.0.0.Alpha1-SNAPSHOT]$ bin/wsconsume.sh https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test...
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (jar:file:/tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.3.0.jar!/) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
> WARNING: Please consider reporting this to the maintainers of com.sun.xml.bind.v2.runtime.reflect.opt.Injector
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -compile -exsh false -d /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430 -verbose -classdir /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output -allowElementReferences https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test...
> wsdl2java - Apache CXF 3.2.2
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:6: error: package javax.xml.ws is not visible
> import javax.xml.ws.WebEndpoint;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:7: error: package javax.xml.ws is not visible
> import javax.xml.ws.WebServiceClient;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:8: error: package javax.xml.ws is not visible
> import javax.xml.ws.WebServiceFeature;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:9: error: package javax.xml.ws is not visible
> import javax.xml.ws.Service;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:3: error: package javax.jws is not visible
> import javax.jws.WebMethod;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:4: error: package javax.jws is not visible
> import javax.jws.WebParam;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:5: error: package javax.jws is not visible
> import javax.jws.WebResult;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:6: error: package javax.jws is not visible
> import javax.jws.WebService;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:7: error: package javax.jws.soap is not visible
> import javax.jws.soap.SOAPBinding;
> ^
> (package javax.jws.soap is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:72: error: cannot find symbol
> return super.getPort(EndpointInterfacePort, EndpointInterface.class);
> ^
> symbol: variable super
> location: class org.openuri._2004._04.helloworld.TestService
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:84: error: cannot find symbol
> return super.getPort(EndpointInterfacePort, EndpointInterface.class, features);
> ^
> symbol: variable super
> location: class org.openuri._2004._04.helloworld.TestService
> JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava
> org.apache.cxf.tools.common.ToolException: Failed to compile generated code
> at org.apache.cxf.impl//org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:125)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:303)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
> at org.apache.cxf.impl//org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.jboss.ws.jaxws-client//org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313)
> at org.jboss.ws.tools.common//org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
> at org.jboss.ws.tools.common//org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
> at org.jboss.ws.tools.common//org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month