July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-23) Add a core-dist to the core build

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-23: -------------------------------------- Summary: Add a core-dist to the core build Key: WFCORE-23 URL: https://issues.jboss.org/browse/WFCORE-23 Project: WildFly Core Issue Type: Task Security Level: Public (Everyone can see) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha4 Add a core-dist to the core build so that we still have a complete built server with all artefacts, resource, files, etc... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1864: -------------------------------- This is because the bind address is incorrect, so it tries all ports, but none works with the given bind address. > UDP unable to bind to ephemeral port: port out of range:65536 > ------------------------------------------------------------- > > Key: JGRP-1864 > URL: https://issues.jboss.org/browse/JGRP-1864 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.4 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5 > > > It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range: > {noformat} > java.lang.IllegalArgumentException: port out of range:65536 > at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143) > at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185) > at java.net.DatagramSocket.<init>(DatagramSocket.java:284) > at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62) > at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429) > at org.jgroups.protocols.UDP.createSockets(UDP.java:311) > at org.jgroups.protocols.UDP.start(UDP.java:216) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966) > at org.jgroups.JChannel.startStack(JChannel.java:889) > at org.jgroups.JChannel._preConnect(JChannel.java:547) > at org.jgroups.JChannel.connect(JChannel.java:282) > at org.jgroups.JChannel.connect(JChannel.java:273) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3672) Add configuration to enable PeerNameResolvingHandler

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3672?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3672: ------------------------------ Description: To properly enable remote host reverse dns lookup there should be io.undertow.server.handlers.PeerNameResolvingHandler handler in handler chain > Add configuration to enable PeerNameResolvingHandler > ----------------------------------------------------- > > Key: WFLY-3672 > URL: https://issues.jboss.org/browse/WFLY-3672 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > To properly enable remote host reverse dns lookup there should be io.undertow.server.handlers.PeerNameResolvingHandler handler in handler chain -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3672) Add configuration to enable PeerNameResolvingHandler

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3672?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3672: ------------------------------ Component/s: Domain Management Web (Undertow) > Add configuration to enable PeerNameResolvingHandler > ----------------------------------------------------- > > Key: WFLY-3672 > URL: https://issues.jboss.org/browse/WFLY-3672 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3672) Add configuration to enable PeerNameResolvingHandler

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-3672: --------------------------------- Summary: Add configuration to enable PeerNameResolvingHandler Key: WFLY-3672 URL: https://issues.jboss.org/browse/WFLY-3672 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 8.1.0.Final Reporter: Tomaz Cerar Assignee: Tomaz Cerar -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3671) picketlink-deltaspike is missing

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3671?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-3671: --------------------------------- Assignee: Pedro Igor (was: Darran Lofthouse) not sure if we should even bundle this, but it is your baby :) > picketlink-deltaspike is missing > -------------------------------- > > Key: WFLY-3671 > URL: https://issues.jboss.org/browse/WFLY-3671 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Pedro Igor > > I'm using the current snapshot of WFLY 9.0.0.Alpha1. However, there is no picketlink-deltaspike.jar in the modules/system/layers/base directory. This JAR contains the CDI interceptor for PicketLink. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3671) picketlink-deltaspike is missing

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-3671: ---------------------------------------- Summary: picketlink-deltaspike is missing Key: WFLY-3671 URL: https://issues.jboss.org/browse/WFLY-3671 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 9.0.0.Beta1 Reporter: Juergen Zimmermann Assignee: Darran Lofthouse I'm using the current snapshot of WFLY 9.0.0.Alpha1. However, there is no picketlink-deltaspike.jar in the modules/system/layers/base directory. This JAR contains the CDI interceptor for PicketLink. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-230) Javassist throws java.lang.VerifyError with dead code

by Kelvin Law (JIRA)

[ https://issues.jboss.org/browse/JASSIST-230?page=com.atlassian.jira.plugi... ] Kelvin Law commented on JASSIST-230: ------------------------------------ package com.abc.test; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; import javassist.CannotCompileException; import javassist.ClassPool; import javassist.CtClass; import javassist.CtMethod; import javassist.CtNewMethod; public class Test { /** * @param args * @throws CannotCompileException * @throws InstantiationException * @throws IllegalAccessException * @throws SecurityException * @throws NoSuchMethodException * @throws InvocationTargetException * @throws IllegalArgumentException */ public static void main(final String[] args) throws CannotCompileException, IllegalAccessException, InstantiationException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException { // TODO Auto-generated method stub // Javassist throws VerifyError on JRE7 String method = "public void evaluate(){if (false) {int i = 0;}}"; // Javassist works on JRE 7 // String method = // "public void evaluate(){if (false == true) {int i = 0;}}"; ClassPool pool = ClassPool.getDefault(); CtClass newClass = pool.makeClass("MyExpression"); CtMethod newmethod; newmethod = CtNewMethod.make(method, newClass); newClass.addMethod(newmethod); Class<?> cClass = newClass.toClass(); Object o = cClass.newInstance(); Method m = cClass.getMethod("evaluate"); m.invoke(o); } } > Javassist throws java.lang.VerifyError with dead code > ----------------------------------------------------- > > Key: JASSIST-230 > URL: https://issues.jboss.org/browse/JASSIST-230 > Project: Javassist > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 3.18.2-GA > Reporter: Kelvin Law > Assignee: Shigeru Chiba > > I found the root cause of the Javassist throws java.lang.VerifyError with JRE 7, but the exact same binary works on JRE6 > It is because of dead code like the following: > if (false) { > do something; > } > These code is generated by the template: > if (${transitory}) { > do something; > } > The reason why we have such dead code in our generated java classes is, it is far more easier to code and maintain condition checking in runtime logic(in Java) instead of template logic (template expression). And we think that the if (false) statement does not make significant performance degradation in runtime. > Although these code could be avoided, this is comply with Java 1.4/5/6/7 syntax standard thus it works with Javassist on JRE 6. Obviously It is a bug in Javassist. > I have the following: tentative solution: > Rewrite the if (${transitory}) with if (${transitory == true}) > I tested the above solution and found that Javassist works with that. No more java.lang.VerifyError. And I believe it does not make significant performance degradation in runtime. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-230) Javassist throws java.lang.VerifyError with dead code

by Kelvin Law (JIRA)

Kelvin Law created JASSIST-230: ---------------------------------- Summary: Javassist throws java.lang.VerifyError with dead code Key: JASSIST-230 URL: https://issues.jboss.org/browse/JASSIST-230 Project: Javassist Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.18.2-GA Reporter: Kelvin Law Assignee: Shigeru Chiba I found the root cause of the Javassist throws java.lang.VerifyError with JRE 7, but the exact same binary works on JRE6 It is because of dead code like the following: if (false) { do something; } These code is generated by the template: if (${transitory}) { do something; } The reason why we have such dead code in our generated java classes is, it is far more easier to code and maintain condition checking in runtime logic(in Java) instead of template logic (template expression). And we think that the if (false) statement does not make significant performance degradation in runtime. Although these code could be avoided, this is comply with Java 1.4/5/6/7 syntax standard thus it works with Javassist on JRE 6. Obviously It is a bug in Javassist. I have the following: tentative solution: Rewrite the if (${transitory}) with if (${transitory == true}) I tested the above solution and found that Javassist works with that. No more java.lang.VerifyError. And I believe it does not make significant performance degradation in runtime. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-22) Port version 1.6 of the management schema upstream.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-22?page=com.atlassian.jira.plugin.... ] Darran Lofthouse moved WFLY-2956 to WFCORE-22: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-22 (was: WFLY-2956) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Alpha4 (was: 9.0.0.CR1) > Port version 1.6 of the management schema upstream. > --------------------------------------------------- > > Key: WFCORE-22 > URL: https://issues.jboss.org/browse/WFCORE-22 > Project: WildFly Core > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.0.0.Alpha4 > > > EAP will be introducing version 1.6 of the management schema, this needs porting upstream. > At the same point the coding convention we have adopted has been based around a linear progression of the configuration schemas, when version 1.5 was ported this still worked as 1.5 contained a subset of the changes that went into 2.0. > 1.6 is going to be a special case as it will build on 1.5 so is already a subset of 2.0 but will also only contain a subset of changes that go into 3.0 - the risk however is our switch statements are built around dropping into a default block that is hit for all schema versions not explicitly listed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2014