January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2733) Create PicketLink subsystems

by Kabir Khan (JIRA)

Kabir Khan created WFLY-2733: -------------------------------- Summary: Create PicketLink subsystems Key: WFLY-2733 URL: https://issues.jboss.org/browse/WFLY-2733 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Fix For: 8.0.0.Final At a minimum IDM and Federation -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-263) JASPI Support for Web Services

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-263?page=com.atlassian.jira.plugin.s... ] Alessio Soldano updated WFLY-263: --------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.CR1) (was: 8.0.0.Final) > JASPI Support for Web Services > ------------------------------ > > Key: WFLY-263 > URL: https://issues.jboss.org/browse/WFLY-263 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security, Web Services > Reporter: Anil Saldhana > Assignee: Jim Ma > Fix For: 9.0.0.CR1 > > > Take care of the JASPI requirements for SOAP layer. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.... ] Mustafa Musaji updated WFLY-2732: --------------------------------- Attachment: MDBLifeCycleJAR.zip Attached reproducer with client. You will need to add {code} <jms-queue name="TestQueue"> <entry name="java:jboss/exported/jms/TestQueue"/> <entry name="jms/TestQueue"/> <durable>true</durable> </jms-queue> {code} to your standalone-full.xml and a application user "guest" using the password in the client code. > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods

by Mustafa Musaji (JIRA)

Mustafa Musaji created WFLY-2732: ------------------------------------ Summary: Injected EJB not available to MDB @PreDestroy methods Key: WFLY-2732 URL: https://issues.jboss.org/browse/WFLY-2732 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 8.0.0.CR1 Reporter: Mustafa Musaji Assignee: Stuart Douglas MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-1389) Log API dependencies should be included automatically in deployments

by Scott Hasse (JIRA)

[ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.s... ] Scott Hasse commented on AS7-1389: ---------------------------------- The decision to include visibility to specific third party logging implementations by default seems absolutely against the basic philosophy of modules in a JEE container environment. This sort of logging is simply not a JEE container feature and default visibility should not be provided and the debate should end there. Those wanting to use the vendor-specific non-spec container facility should be the ones configuring an explicit dependency. I find David Lloyd's anecdotal observations on which this decision was based to be simply not accurate in my large enterprise experience where you want to decouple the application from the container excepting for the specified JEE facilities. If someone thinks otherwise I'm certainly interested to understand why. Especially justifying the decision based on portability seems exactly backwards. JBoss is going beyond the specification to provide a vendor-specific facility that in fact reduces portability. Please consider re-thinking this decision moving forward. Scott > Log API dependencies should be included automatically in deployments > -------------------------------------------------------------------- > > Key: AS7-1389 > URL: https://issues.jboss.org/browse/AS7-1389 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.0.0.Final > Reporter: David Lloyd > Assignee: James Perkins > Fix For: 7.1.0.Final > > > The following log APIs should be included by deployments by default: > * {{org.slf4j}} > * {{org.apache.commons.logging}} > * {{org.log4j}} > These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.xml}}. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2731) HTTP upgrade does not accept multiple acceptors

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-2731: --------------------------------- Summary: HTTP upgrade does not accept multiple acceptors Key: WFLY-2731 URL: https://issues.jboss.org/browse/WFLY-2731 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS Affects Versions: 8.0.0.CR1 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 8.0.0.Final The http-acceptors are multiplexed over the HTTP port. If there are multiple http-acceptors registered, a http-connector that uses the HTTP upgrade mechanism will use the first whose handshake is successful and can not chose a given http-acceptor. With native messaging ports, the solution was to use different ports for different acceptors but with HTTP upgrade, everything goes through the HTTP port. HornetQ connectors must pass "http-upgrade-endpoint" when the HTTP upgrade is initiated so that we ensure the handshake is successful only for the matching acceptor corresponding to the "http-upgrade-endpoint" value. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2730) HTTP upgrade does not accept multiple acceptors

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-2730: --------------------------------- Summary: HTTP upgrade does not accept multiple acceptors Key: WFLY-2730 URL: https://issues.jboss.org/browse/WFLY-2730 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS Affects Versions: 8.0.0.CR1 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 8.0.0.Final The http-acceptors are multiplexed over the HTTP port. If there are multiple http-acceptors registered, a http-connector that uses the HTTP upgrade mechanism will use the first whose handshake is successful and can not chose a given http-acceptor. With native messaging ports, the solution was to use different ports for different acceptors but with HTTP upgrade, everything goes through the HTTP port. HornetQ connectors must pass "http-upgrade-endpoint" when the HTTP upgrade is initiated so that we ensure the handshake is successful only for the matching acceptor corresponding to the "http-upgrade-endpoint" value. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use the project classpath

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-373?page=com.atlassian.jira.plugin... ] Matteo Mortari updated DROOLS-373: ---------------------------------- Attachment: drools6scratch-kiemavenclasspath.zip I've made a quick example project, to prove the point, but from my side this still does not work. The project is a KIE project, and has a dependency, enlisted in maven pom as: {code:xml} <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.1</version> </dependency> {code} Then there is a very simple DRL file, for very dummy rules: {code:title=package.drl} package com.acme.drools6scratch_kiemavenclasspath global org.apache.commons.lang3.tuple.ImmutablePair ip; import org.apache.commons.lang3.tuple.* ; rule "prova" when $ip : ImmutablePair() then System.out.println("detected"); end {code} Now. If you run maven lifecycle with the pom in the current state, it will fail with: {noformat} [INFO] --- kie-maven-plugin:6.0.1.Final:build (default-build) @ drools6scratch-kiemavenclasspath --- java.lang.ClassNotFoundException: Unable to find class 'org.apache.commons.lang3.tuple.ImmutablePair' {noformat} Actually, if you enlist the 'commons-lang3' dependency ALSO inside the kie-maven-plugin by removing the commented part in the pom, then kie-maven-plugin will be able to compile without the error above. I think this issue was meant to avoid exactly this situation which happened in 6.0.0 ? I'm using 6.0.1.Final. Maybe I'm doing something wrong from my side, but could you kindly evaluate if actually necessary to put this issue in status reopened, please? Thanks, Ciao! > Kie Maven plugin don't use the project classpath > ------------------------------------------------ > > Key: DROOLS-373 > URL: https://issues.jboss.org/browse/DROOLS-373 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > Attachments: drools6scratch-kiemavenclasspath.zip > > > When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-questio... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use the project classpath

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-373?page=com.atlassian.jira.plugin... ] Matteo Mortari commented on DROOLS-373: --------------------------------------- I'm appending a comment here, to see if it would trigger revaluation of the status of this bug to reopened, because from my test it does not resolve and I will explain why further down below. > Kie Maven plugin don't use the project classpath > ------------------------------------------------ > > Key: DROOLS-373 > URL: https://issues.jboss.org/browse/DROOLS-373 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.0.1.Final > > > When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-questio... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1717 at 1/9/14 9:13 AM: -------------------------------------------------------- Tested perf with UPerf (measures throughput and latency) Environment: - JGroups master (3.5) with JGRP-1767 and JGRP-1768 included - cluster-xx lab, 1Gbps network (~125MB/sec) - 8 nodes: cluster01-08 - fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool* - Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs - numOwners=2 - Configs are: || A || B || C || | ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true| | {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} | The results are (in avg. requests / sec / node): || Invoker threads || SSWT-A || SSWT-B || SSWT-C || TQ-A || TQ-B || TQ-C || SS-A || SS-B || SS-C || | 1 | 4754 | 4545 | 23 | *4809* | 4415 | 4647 | 4698 | *4718* | *4656* | | 4 | 14699 | 14033 | 74 | 15122 | 13864 | *14079* | *15715* | *14275* | 13782 | | 10 | 22948 | 21192 | 227 | *23232* | *22576* | *22312* | 22487 | 21920 | 18403 | | 20 | 24431 | 23738 | 340 | 23988 | *29282* | *25522* | *25673* | 28228 | 20890 | Comments: * SSWT-B: messages are not bundled (even though ignore_don_bundle=true) as the code has an exception for this bundler * SSWT-C: this bundler has a max_bundle_time of 30ms, so each request and response can have up to 30ms added to it, which is very bad for latency ** Running sync RPCs on SSWT without {{+DONT_BUNDLE | +OOB}} doesn't make any sense * With option C, the cost of batching doesn't really show (although it *is* a bit slower than option B), as UPerf doesn't do anything real (unlike Infinispan). ** However, the slower perf of C against B is caused by all requests in a batch being processed *sequentially* and therefore responses sent before the next request is processed slow down overall speed * Infinispan uses option B when invoking sync RPCs was (Author: belaban): Tested perf with UPerf (measures throughput and latency) Environment: - JGroups master (3.5) with JGRP-1767 and JGRP-1768 included - cluster-xx lab, 1Gbps network (~125MB/sec) - 8 nodes: cluster01-08 - fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool* - Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs - numOwners=2 - Configs are: || A || B || C || | ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true| | {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} | The results are (in avg. requests / sec / node): || Invoker threads || SSWT-A || SSWT-B || SSWT-C || TQ-A || TQ-B || TQ-C || SS-A || SS-B || SS-C || | 1 | 4754 | 4545 | 23 | *4809* | 4415 | 4647 | 4698 | *4718* | *4656* | | 4 | 14699 | 14033 | 74 | *15122* | 13864 | *14079* | 15715 | *14275* | 13782 | | 10 | 22948 | 21192 | 227 | *23232* | *22576* | *22312* | 22487 | 21920 | 18403 | | 20 | 24431 | 23738 | 340 | 23988 | *29282* | *25522* | *25673* | 28228 | 20890 | Comments: * SSWT-B: messages are not bundled (even though ignore_don_bundle=true) as the code has an exception for this bundler * SSWT-C: this bundler has a max_bundle_time of 30ms, so each request and response can have up to 30ms added to it, which is very bad for latency ** Running sync RPCs on SSWT without {{+DONT_BUNDLE | +OOB}} doesn't make any sense * With option C, the cost of batching doesn't really show (although it *is* a bit slower than option B), as UPerf doesn't do anything real (unlike Infinispan). ** However, the slower perf of C against B is caused by all requests in a batch being processed *sequentially* and therefore responses sent before the next request is processed slow down overall speed * Infinispan uses option B when invoking sync RPCs > Bundling reduces performance in scenario mimicking Inifinispan > -------------------------------------------------------------- > > Key: JGRP-1717 > URL: https://issues.jboss.org/browse/JGRP-1717 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3 > Reporter: Radim Vansa > Assignee: Bela Ban > Fix For: 3.5 > > Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml > > > In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance. > See attached configurations and results. -- 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, 6 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 January 2014