September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8272) Change property name on JSFUrlIntegrationDeployer

by Stan Silvert (JIRA)

Change property name on JSFUrlIntegrationDeployer ------------------------------------------------- Key: JBAS-8272 URL: https://jira.jboss.org/browse/JBAS-8272 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M4 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 6.0.0.CR1 Change property name from JSFImplName to JSFConfigName. This makes it consistent with the property names on JSFImplManagementDeployer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8405) Add MyFaces 2.0 support to JSF Deployer

by Stan Silvert (JIRA)

Add MyFaces 2.0 support to JSF Deployer --------------------------------------- Key: JBAS-8405 URL: https://jira.jboss.org/browse/JBAS-8405 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JSF Affects Versions: 6.0.0.M4 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 6.0.0.CR1 This will be included in CR1. There are some optimizations for annotation scanning that will be implemented in MyFaces 2.0.2, but we will ship MyFaces 2.0.1 for now. Mojarra will remain as the default JSF implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8401) exception is thrown by javax.ejb.EJBLocalObject.isIdentical -- ejb2.x

by Thunder Lei (JIRA)

exception is thrown by javax.ejb.EJBLocalObject.isIdentical -- ejb2.x --------------------------------------------------------------------- Key: JBAS-8401 URL: https://jira.jboss.org/browse/JBAS-8401 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2, EJB3 Affects Versions: JBossAS-5.0.0.GA Environment: Microsoft Windows XP [Version 5.1.2600] jdk160_10 Reporter: Thunder Lei Assignee: Alexey Loubyansky I am new to JBoss community. If I don't report the issues correctly, pls help correct me. I develop a stateless session bean, in which EJB2.x and EJB3 interfaces coexist. In short, it works, but with two issues. 1. unable to override 2.x local home jndi name. In jboss.xml (jboss_5_0.dtd), the local home jndi is NOT allowed, so you have to refer to the default local home jndi -- beanName/local 2. when calling method on remote business interface, it works, but EJB exception is thrown by javax.ejb.EJBLocalObject.isIdentical. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
6
0 / 0

[JBoss JIRA] Commented: (JGRP-1038) FC2

by Bela Ban (JIRA)

[ https://jira.jboss.org/browse/JGRP-1038?page=com.atlassian.jira.plugin.sy... ] Bela Ban commented on JGRP-1038: -------------------------------- Looks like FC2 handles only *unicasts*, not multicasts. Is this what FC2's supposed to do ? If so, it could be an alternative to UFC... A good perf test would be UnicastTestRpcDist. > FC2 > --- > > Key: JGRP-1038 > URL: https://jira.jboss.org/browse/JGRP-1038 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.11 > > Attachments: FC2.java, FCOverloadTest.java, Results.txt > > > [Email Gray Watson] > So we implemented our own FC2 because of problems with FC. I've been writing > tests and trying (with some success) to reproduce the issues we faced. > Initially when we were doing performance tests in our cluster of ~20 big-ish > linux servers with UDP/FC, we saw severe performance tests with "decent" > sized messages. Often we have large SQL responses which are in the 1+mb > range and can be as high as 10+mb. I decided to write the attached > FCOverloadTest to demonstrate some of the issues and to compare FC and FC2. > The default FC setting max_credits=500000 in udp.xml results in terrible > performance -- 952 seconds to send 10x 5mb messages to 10 hosts (500mb). > Less than optimal. > The simple solution, on the surface, is to increase the credits 1 or 2 > orders of magnitude. 5000000 takes 160 secs, and 50000000 takes 32 secs. > Fine. But this in effect removes most of the flow-control. The larger the > max-credits, the more messages queue up. > What I thought would be a better flow-control model was per-recipient, where > each sender would keep a "water-level" of the outstanding packets needed to > be ack'd. When the water level got too high it would pause the sender until > the receiver had ack'd the water level back down. This is what FC2 tried to > accomplish. I've attached my test results, the FCOverloadTest, and FC2. > FC2 looks to do less UNICAST retransmits, sends fewer packets, and is > faster. It needs some review however. > I'd like to know other folks' experiences with flow-control. Are people > really using the udp.xml settings in production? What message sizes do you > have? > The next step in my testing is to write some unit tests which shut down and > start up notes while the system is loaded with an attempt to reproduce the > cluster pauses with FC that we have seen which would be deadly to our > application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (SECURITY-519) EJBXACMLUtil should consider overloaded methods

by Anil Saldhana (JIRA)

EJBXACMLUtil should consider overloaded methods ----------------------------------------------- Key: SECURITY-519 URL: https://jira.jboss.org/browse/SECURITY-519 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: PicketBox_v3_0_beta5 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: PicketBox_v3_0_beta6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-8247) Track EJB3 upgrades to AS trunk

by jaikiran pai (JIRA)

Track EJB3 upgrades to AS trunk ------------------------------- Key: JBAS-8247 URL: https://jira.jboss.org/browse/JBAS-8247 Project: JBoss Application Server Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: EJB3 Reporter: jaikiran pai Assignee: jaikiran pai Track EJB3 bom upgrades to AS trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Assigned: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6

by Heiko Braun (JIRA)

[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ] Heiko Braun reassigned JBAS-8276: --------------------------------- Assignee: Heiko Braun (was: Marius Bogoevici) > Weld Extension vs. Tomcat deployer in JBoss 6 > --------------------------------------------- > > Key: JBAS-8276 > URL: https://jira.jboss.org/browse/JBAS-8276 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M4 > Reporter: Heiko Braun > Assignee: Heiko Braun > > When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension: > 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app > 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-8396) Don't set the NamingManager.InitialContextFactoryBuilder if already set in NamingSubsystemElement

by Kabir Khan (JIRA)

Don't set the NamingManager.InitialContextFactoryBuilder if already set in NamingSubsystemElement ------------------------------------------------------------------------------------------------- Key: JBAS-8396 URL: https://jira.jboss.org/browse/JBAS-8396 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Naming Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 7.0.0.M1 In unit tests we might need to reuse this, and with the jdk implementation MM.setICFB() throws an error if already set -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1861) Ruleflow diagram not proprly displayed

by Jaroslaw Kijanowski (JIRA)

Ruleflow diagram not proprly displayed -------------------------------------- Key: JBRULES-1861 URL: https://jira.jboss.org/jira/browse/JBRULES-1861 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.M3 Reporter: Jaroslaw Kijanowski Assignee: Michael Neale Attachments: expected.png, rf.png -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2167) @TransactionAttribute declared in superclass is ignore & @TransactionAttribute conflict to Deployment Descriptor

by e t (JIRA)

@TransactionAttribute declared in superclass is ignore & @TransactionAttribute conflict to Deployment Descriptor ---------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2167 URL: https://jira.jboss.org/browse/EJBTHREE-2167 Project: EJB 3.0 Issue Type: Bug Components: ejb3 Environment: jboss-5.1.0.GA Sun jdk1.6.0_16 WinXP 32bit Reporter: e t Attachments: src.rar According to the EJB3 Specification，If the bean class has superclasses, the following additional rules apply. • A transaction attribute specified on a superclass S applies to the business methods defined by S. If a class-level transaction attribute is not specified on S, it is equivalent to specification of TransactionAttribute(REQUIRED) on S. • A transaction attribute may be specified on a business method M defined by class S to override for method M the transaction attribute value explicitly or implicitly specified on the class S. • If a method M of class S overrides a business method defined by a superclass of S, the transaction attribute of M is determined by the above rules as applied to class S. The issue is : 1 . When I take the test of a SLSB which has a superclass and its transaction attribute is set to NEVER, I always get the method call in transaction attribute is set to REQUIRED(see the follow code for details). 2 . When I deploy an empty ejb-jar.xml and jboss.xml to META-INF directory, the SLSB's transaction attribute is set to SUPPORTS/NOT_SUPPORTEDNEVER PS:I using the EntityManager's persist method call for checking current method call is associated with a transaction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
5
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 September 2010