July 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-508) JSR-352 Batch Applications API support

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-508?page=com.atlassian.jira.plugin.s... ] Cheng Fang commented on WFLY-508: --------------------------------- jboss-batch-api_1.0_spec 1.0.0.Beta1 and jberet-core 1.0.0.Alpha2 were released last week for integration to WildFly. 2nd PR https://github.com/wildfly/wildfly/pull/4812 > JSR-352 Batch Applications API support > -------------------------------------- > > Key: WFLY-508 > URL: https://issues.jboss.org/browse/WFLY-508 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > Assignee: Cheng Fang > Fix For: 8.0.0.Beta1 > > > Support the Batch Applications for the Java Platform 1.0 spec as per Java EE 7 specification. > spec, RI & TCK page: http://java.net/projects/jbatch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1322) Cannot set up serverBindAddress for secondarySocket in bisocket transport

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1322?page=com.atlassian.jira.plugin... ] Ron Sigal updated JBREM-1322: ----------------------------- Fix Version/s: 2.5.4.SP5 Assignee: Ron Sigal > Cannot set up serverBindAddress for secondarySocket in bisocket transport > ------------------------------------------------------------------------- > > Key: JBREM-1322 > URL: https://issues.jboss.org/browse/JBREM-1322 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 2.5.4.SP4 > Reporter: Igor Kostromin > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > > Using IS_CALLBACK_SERVER = true. > In BisocketClientInvoker.java:355 > InvokerLocator getSecondaryLocator() throws Throwable { > ... > 355: Object o = invoke(r); > ... > } > It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to > Object o = invoke(r); > // DZ: patch to use original server address for creating secondary connection > // instead of address retrieved from server (because server will return jboss bind address > // that can be local address, inaccessible from client) > InvokerLocator patchedLocator = new InvokerLocator( (( InvokerLocator ) o).getOriginalURI().replace( > (( InvokerLocator ) o).getHost(), this.getLocator().getHost() ) > ); > log.debug("secondary locator: " + o); > log.debug("patched secondary locator: " + patchedLocator); > return patchedLocator; > and rebuild jboss-remoting project. > For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-328) Reintroduce the feature to allow EJB invocations over HTTP

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-328?page=com.atlassian.jira.plugin.s... ] Brad Maxwell edited comment on WFLY-328 at 7/19/13 2:30 PM: ------------------------------------------------------------ ( *** NOTE *** ) Jaikiran's comment, this depends on Undertow - "With the recent feature in WildFly (backed by Undertow) to support a single port of communication, it is now possible (in fact default) for EJB invocations to happen over the http port." Undertow is NOT GA yet and is a replacement for JBossWeb For JBoss EAP product questions, please open a support case for updated information. was (Author: bmaxwell): *** NOTE *** Jaikiran's comment, this depends on Undertow - "With the recent feature in WildFly (backed by Undertow) to support a single port of communication, it is now possible (in fact default) for EJB invocations to happen over the http port." Undertow is NOT GA yet and is a replacement for JBossWeb For JBoss EAP product questions, please open a support case for updated information. > Reintroduce the feature to allow EJB invocations over HTTP > ---------------------------------------------------------- > > Key: WFLY-328 > URL: https://issues.jboss.org/browse/WFLY-328 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: jaikiran pai > Assignee: Eduardo Martins > Fix For: 8.0.0.Alpha3 > > > There have been requests from users to resurrect the feature from previous JBoss AS versions to allow EJB invocation over HTTP. Most recent discussion about this is here http://lists.jboss.org/pipermail/jboss-as7-dev/2012-April/005808.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-328) Reintroduce the feature to allow EJB invocations over HTTP

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-328?page=com.atlassian.jira.plugin.s... ] Brad Maxwell commented on WFLY-328: ----------------------------------- *** NOTE *** Jaikiran's comment, this depends on Undertow - "With the recent feature in WildFly (backed by Undertow) to support a single port of communication, it is now possible (in fact default) for EJB invocations to happen over the http port." Undertow is NOT GA yet and is a replacement for JBossWeb For JBoss EAP product questions, please open a support case for updated information. > Reintroduce the feature to allow EJB invocations over HTTP > ---------------------------------------------------------- > > Key: WFLY-328 > URL: https://issues.jboss.org/browse/WFLY-328 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: jaikiran pai > Assignee: Eduardo Martins > Fix For: 8.0.0.Alpha3 > > > There have been requests from users to resurrect the feature from previous JBoss AS versions to allow EJB invocation over HTTP. Most recent discussion about this is here http://lists.jboss.org/pipermail/jboss-as7-dev/2012-April/005808.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1663: -------------------------------- A timer usually has only a few tasks in it, so additional threads are spawned to handle tasks if the pool is full. It is critical that a timer task (1) never blocks and (2) is never lost, so we cannot simply discard it. What do you do to end up with 19'000 threads in the timer ? > TimeScheduler3 could spawn too many threads > ------------------------------------------- > > Key: JGRP-1663 > URL: https://issues.jboss.org/browse/JGRP-1663 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3.3 > Reporter: Igor Mazur > Assignee: Bela Ban > Priority: Optional > Fix For: 3.4 > > > With default timer thread pool settings this code could spawn thousands of threads: > protected void submitToPool(final Task entry) { > try { > pool.execute(entry); > } > catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort" > Thread thread=timer_thread_factory != null? > timer_thread_factory.newThread(entry, "Timer temp thread") > : new Thread(entry, "Timer temp thread"); > thread.start(); > } > } > On my environment I got 19000 threads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1663: --------------------------- Fix Version/s: 3.4 > TimeScheduler3 could spawn too many threads > ------------------------------------------- > > Key: JGRP-1663 > URL: https://issues.jboss.org/browse/JGRP-1663 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3.3 > Reporter: Igor Mazur > Assignee: Bela Ban > Priority: Optional > Fix For: 3.4 > > > With default timer thread pool settings this code could spawn thousands of threads: > protected void submitToPool(final Task entry) { > try { > pool.execute(entry); > } > catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort" > Thread thread=timer_thread_factory != null? > timer_thread_factory.newThread(entry, "Timer temp thread") > : new Thread(entry, "Timer temp thread"); > thread.start(); > } > } > On my environment I got 19000 threads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1668) Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC}

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/WFLY-1668?page=com.atlassian.jira.plugin.... ] Peter Skopek edited comment on WFLY-1668 at 7/19/13 2:13 PM: ------------------------------------------------------------- Fixed in component source. PR added. was (Author: pskopek): Fixed in component source. Waiting for next release of PicketBox 4.0.19. > Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC} > ------------------------------------------------------------------------------------ > > Key: WFLY-1668 > URL: https://issues.jboss.org/browse/WFLY-1668 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Josef Cacek > Assignee: Peter Skopek > > Mechanism to obtain passwords from external sources for login modules works only with option {EXT} - non-cached. New feature to cache passwords with command option {EXTC[:timeout]} doesn't work. > Problem is propably in LdapExtLoginModule method createLdapInitContext, that doesn't deal with commands that starts with "{EXTC" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1668) Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC}

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/WFLY-1668?page=com.atlassian.jira.plugin.... ] Peter Skopek commented on WFLY-1668: ------------------------------------ Fixed in component source. Waiting for next release of PicketBox 4.0.19. > Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC} > ------------------------------------------------------------------------------------ > > Key: WFLY-1668 > URL: https://issues.jboss.org/browse/WFLY-1668 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Josef Cacek > Assignee: Peter Skopek > > Mechanism to obtain passwords from external sources for login modules works only with option {EXT} - non-cached. New feature to cache passwords with command option {EXTC[:timeout]} doesn't work. > Problem is propably in LdapExtLoginModule method createLdapInitContext, that doesn't deal with commands that starts with "{EXTC" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1668) Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC}

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1668?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1668: ----------------------------------------------- Peter Skopek <pskopek(a)redhat.com> made a comment on [bug 982539|https://bugzilla.redhat.com/show_bug.cgi?id=982539] Tag for picketbox: https://svn.jboss.org/repos/picketbox/tags/4.0.17.SP1/ PR for EAP 6.1.1: https://github.com/jbossas/jboss-eap/pull/248 > Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC} > ------------------------------------------------------------------------------------ > > Key: WFLY-1668 > URL: https://issues.jboss.org/browse/WFLY-1668 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Josef Cacek > Assignee: Peter Skopek > > Mechanism to obtain passwords from external sources for login modules works only with option {EXT} - non-cached. New feature to cache passwords with command option {EXTC[:timeout]} doesn't work. > Problem is propably in LdapExtLoginModule method createLdapInitContext, that doesn't deal with commands that starts with "{EXTC" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1724) Could not load Logmanager "org.jboss.logmanager.LogManager"

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-1724?page=com.atlassian.jira.plugin.... ] David Lloyd resolved WFLY-1724. ------------------------------- Resolution: Won't Fix We cannot support the SNMP management agent. We need some other solution for SNMP-based management that hooks in after the server bootstrap is complete (e.g. maybe an enhancement to the jmx subsystem). > Could not load Logmanager "org.jboss.logmanager.LogManager" > ----------------------------------------------------------- > > Key: WFLY-1724 > URL: https://issues.jboss.org/browse/WFLY-1724 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 8.0.0.Alpha1 > Environment: RHEL 6.4 > Oracle JDK 7_25 > Reporter: Jack Gibson > Assignee: David Lloyd > > Set system properties to enable SNMP for the JVM fails > -Dcom.sun.management.snmp.port=162 > -Dcom.sun.management.snmp.acl.file=$HOME/snmp.acl > Could not load Logmanager "org.jboss.logmanager.LogManager" > java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at java.util.logging.LogManager$1.run(LogManager.java:183) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.logging.LogManager.<clinit>(LogManager.java:173) > at java.util.logging.Logger.demandLogger(Logger.java:336) > at java.util.logging.Logger.getLogger(Logger.java:390) > at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:72) > at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:57) > at sun.management.snmp.AdaptorBootstrap.<clinit>(AdaptorBootstrap.java:61) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:270) > at sun.management.Agent.loadSnmpAgent(Agent.java:293) > at sun.management.Agent.startAgent(Agent.java:230) > at sun.management.Agent.startAgent(Agent.java:369) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 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 2013