June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5040) getRequestURL doesn't return url in address bar but rather actual path

by Kelly Dolan (JIRA)

Kelly Dolan created AS7-5040: -------------------------------- Summary: getRequestURL doesn't return url in address bar but rather actual path Key: AS7-5040 URL: https://issues.jboss.org/browse/AS7-5040 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: Kelly Dolan Given: * an application MyEar.ear configured to use JAAS security that contains MyWar.war configured to redirect protected requests to a FORM login page * a login page - MyEar.ear/MyWar.war/WEB-INF/login.jsp * 2 conceptual sites - a user and admin site. The user site is accessed as http://server:port/MyEar/user and the admin site is accessed as http://server:port/MyEar/admin. The login page calls request.getRequestURL() to determine which site is being accessed and generates the content of the login page differently based on which site is being accessed among other things. In JBoss 4, request.getRequestURL() returns * returns http://server:port/MyEar/user when http://server:port/MyEar/user is entered * returns http://server:port/MyEar/admin when http://server:port/MyEar/admin is entered * if params are entered on the URL, they are not part of the string returned by getRequestURL() but that's okay for me In JBoss 7, request.getRequestURL() returns http://server:port/MyEar/WEB-INF/login.jsp. Ultimately, this seems to imply the URL in the address bar is not available to JSPs. This impacts all related get URL/path methods and for us, is a HUGE problem. JBAS-6570 was open for AS6 but closed (understandably). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
10
0 / 0

[JBoss JIRA] (AS7-5049) Allow bundles to get resolved/activated during deployment unit processing

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5049: ----------------------------------- Summary: Allow bundles to get resolved/activated during deployment unit processing Key: AS7-5049 URL: https://issues.jboss.org/browse/AS7-5049 Project: Application Server 7 Issue Type: Task Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5027) Deploying Postgresql JDBC 4 driver gives New missing/unsatisfied dependencies

by Dean Schulze (JIRA)

Dean Schulze created AS7-5027: --------------------------------- Summary: Deploying Postgresql JDBC 4 driver gives New missing/unsatisfied dependencies Key: AS7-5027 URL: https://issues.jboss.org/browse/AS7-5027 Project: Application Server 7 Issue Type: Bug Reporter: Dean Schulze -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
2
0 / 0

[JBoss JIRA] (JBEE-114) JSF-API from 2.0.1.Final introduces inclusion of JSF-IMPL resources

by Marek Novotny (JIRA)

Marek Novotny created JBEE-114: ---------------------------------- Summary: JSF-API from 2.0.1.Final introduces inclusion of JSF-IMPL resources Key: JBEE-114 URL: https://issues.jboss.org/browse/JBEE-114 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jsf-api Reporter: Marek Novotny Assignee: Paul Gier org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.0.1.Final and 2.0.2.Final introduces some resources which gather to jsf-impl artifact. That affect some classpath usage when there should be only API classes. Concrete example are /META-INF/resources/javax.faces/* files -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
9
0 / 0

[JBoss JIRA] (AS7-4520) EJB subsystem gives uninformative error messages when an EJB class is invalid

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-4520?page=com.atlassian.jira.plugin.s... ] Stuart Douglas updated AS7-4520: -------------------------------- Summary: EJB subsystem gives uninformative error messages when an EJB class is invalid (was: beans.xml + Singleton EJB fails to deploy) > EJB subsystem gives uninformative error messages when an EJB class is invalid > ----------------------------------------------------------------------------- > > Key: AS7-4520 > URL: https://issues.jboss.org/browse/AS7-4520 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.1.Final > Environment: JBoss AS 7.1.1.Final > Reporter: Harold Campbell > Assignee: Stuart Douglas > > Singleton EJBs in the presence of beans.xml fail to deploy with a weld error. Without the presence of beans.xml the EJB deploys and functions as expected. Here's the full deployment attempt log: > 12:42:50,533 INFO [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/hcamp/code/jboss-as-7.1.1.Final/standalone/data/content/3a/11b79a5d3167adc8ec204eedf44cec07a50450/content > 12:42:50,561 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "rfpushtest.war" > 12:42:55,891 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment rfpushtest.war > 12:42:56,529 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named Poller in deployment unit deployment "rfpushtest.war" are as follows: > java:global/rfpushtest/Poller!com.foo.rfpushtest.ejb.singleton.Poller > java:app/rfpushtest/Poller!com.foo.rfpushtest.ejb.singleton.Poller > java:module/Poller!com.foo.rfpushtest.ejb.singleton.Poller > java:global/rfpushtest/Poller > java:app/rfpushtest/Poller > java:module/Poller > 12:42:57,493 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: rfpushtest.war > 12:42:57,653 INFO [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.5 (AS71) > 12:42:57,817 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment rfpushtest.war > 12:42:59,592 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Solder Config XML provider starting... > 12:42:59,595 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Loading XmlDocumentProvider: org.jboss.solder.config.xml.bootstrap.ResourceLoaderXmlDocumentProvider > 12:42:59,658 INFO [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-1) Reading XML file: vfs:/content/rfpushtest.war/WEB-INF/beans.xml > 12:42:59,699 INFO [org.jboss.solder.Version] (MSC service thread 1-1) Solder 3.1.0.Final (build id: 3.1.0.Final) > 12:43:07,485 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."rfpushtest.war".component.Poller.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."rfpushtest.war".component.Poller.START: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] > Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) > at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:116) > at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:130) > at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > ... 3 more > Caused by: javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalAccessException: Class org.jboss.as.weld.injection.WeldEEInjection can not access a member of class com.foo.rfpushtest.ejb.singleton.Poller with modifiers "" > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333) > at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > ... 9 more > Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException: Class org.jboss.as.weld.injection.WeldEEInjection can not access a member of class com.foo.rfpushtest.ejb.singleton.Poller with modifiers "" > at org.jboss.as.weld.injection.WeldEEInjection.produce(WeldEEInjection.java:103) > at org.jboss.as.weld.injection.WeldManagedReferenceFactory.getReference(WeldManagedReferenceFactory.java:77) > at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:90) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) > ... 18 more > Caused by: java.lang.IllegalAccessException: Class org.jboss.as.weld.injection.WeldEEInjection can not access a member of class com.foo.rfpushtest.ejb.singleton.Poller with modifiers "" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) [rt.jar:1.6.0_26] > at java.lang.Class.newInstance0(Class.java:349) [rt.jar:1.6.0_26] > at java.lang.Class.newInstance(Class.java:308) [rt.jar:1.6.0_26] > at org.jboss.as.weld.injection.WeldEEInjection.produce(WeldEEInjection.java:100) > ... 26 more > 12:43:07,792 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "rfpushtest.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"rfpushtest.war\".component.Poller.START" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"rfpushtest.war\".component.Poller.START: Failed to start service"}} > 12:43:07,811 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016009: Stopping weld service for deployment rfpushtest.war > 12:43:07,951 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment rfpushtest.war in 173ms > 12:43:07,954 INFO [org.jboss.as.controller] (management-handler-thread - 2) JBAS014774: Service status report > JBAS014777: Services which failed to start: service jboss.deployment.unit."rfpushtest.war".component.Poller.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."rfpushtest.war".component.Poller.START: Failed to start service -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4470) JPA should allow for a bean validator factory per persistence unit or per application deployment

by Scott Marlow (JIRA)

Scott Marlow created AS7-4470: --------------------------------- Summary: JPA should allow for a bean validator factory per persistence unit or per application deployment Key: AS7-4470 URL: https://issues.jboss.org/browse/AS7-4470 Project: Application Server 7 Issue Type: Task Components: JPA / Hibernate Affects Versions: 7.1.0.Final Reporter: Scott Marlow Currently, a new bean validator factory instance is associated with each deployed persistence unit. This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property). This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPARe...]. The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false. Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] (AS7-4097) Using an extended persistence context in a stateless session bean should throw an exception

by Karsten Wutzke (JIRA)

Karsten Wutzke created AS7-4097: ----------------------------------- Summary: Using an extended persistence context in a stateless session bean should throw an exception Key: AS7-4097 URL: https://issues.jboss.org/browse/AS7-4097 Project: Application Server 7 Issue Type: Bug Reporter: Karsten Wutzke Using an extended persistence context in a stateless session bean should not initiate. It should throw an exception to notify the user of incorrect use. See JPA 2.0 spec, section 7.6.2: "A container-managed extended persistence context can only be initiated within the scope of a stateful session bean." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
3
0 / 0

[JBoss JIRA] (JBAS-9502) Specifying url-selector-strategy-class-name in a local-tx-datasource does not work

by Travis Rogers (JIRA)

Travis Rogers created JBAS-9502: ----------------------------------- Summary: Specifying url-selector-strategy-class-name in a local-tx-datasource does not work Key: JBAS-9502 URL: https://issues.jboss.org/browse/JBAS-9502 Project: Application Server 3 4 5 and 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: 6.1.0 Environment: Windows 7 Oracle JDK 1.6.0_27 Reporter: Travis Rogers Assignee: Jesper Pedersen Priority: Minor Fix For: No Release Attachments: JBAS-9452.patch Here is an example of my data source configuration. <datasources> <local-tx-datasource> <jndi-name>as400/AS400-DS</jndi-name> <connection-url>jdbc:as400:primaryhost;prompt=false|jdbc:as400:secondaryhost;prompt=false</connection-url> <url-delimiter>|</url-delimiter> <url-selector-strategy-class-name>org.example.MyUrlSelectorStrategy</url-selector-strategy-class-name> <driver-class>com.ibm.as400.access.AS400JDBCDriver</driver-class> <user-name>my_user_name</user-name> <password>p4ssw0rd</password> <metadata> <type-mapping>DB2</type-mapping> </metadata> <background-validation-millis>15000</background-validation-millis> <min-pool-size>5</min-pool-size> <max-pool-size>5</max-pool-size> <blocking-timeout-millis>1000</blocking-timeout-millis> <idle-timeout-minutes>5</idle-timeout-minutes> </local-tx-datasource> </datasources> When providing the 'url-selector-strategy-class-name' attribute in a local-tx-datasource definition, the value specified is ignored, and the default implementation ends up being used instead. After digging around in the code, I noticed that in connector/src/main/org/jboss/resource/metadata/mcf/DataSourceDeploymentMetaData.java, the getManagedConnectionFactoryProperties method should call property.setName("UrlSelectorStrategyClassName"); instead of property.setName("URLSelectorStrategyClassName"); in order to properly set the property with the name 'urlSelectorStrategyClassName' on the class BaseWrapperManagedConnectionFactory.java. I've confirmed that, after making the change, the server reads in the property correctly and uses the associated class for URL selection strategy when connecting to the database with the configured URLs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5048) Cannot run smoke tests from IDE

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5048: ----------------------------------- Summary: Cannot run smoke tests from IDE Key: AS7-5048 URL: https://issues.jboss.org/browse/AS7-5048 Project: Application Server 7 Issue Type: Bug Components: Test Suite Reporter: Thomas Diesler Assignee: Thomas Diesler This currently relies on {code} private String jbossHome = System.getenv("JBOSS_HOME"); {code} So you must have the environment variable set before you start the IDE. Otherwise you get {code} org.jboss.arquillian.container.spi.ConfigurationException: jbossHome 'null' must exist at org.jboss.arquillian.container.spi.client.deployment.Validate.configurationDirectoryExists(Validate.java:93) at org.jboss.as.arquillian.container.managed.ManagedContainerConfiguration.validate(ManagedContainerConfiguration.java:82) {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] (JGRP-1451) Group gets stuck with inconsistent views

by David Hotham (JIRA)

David Hotham created JGRP-1451: ---------------------------------- Summary: Group gets stuck with inconsistent views Key: JGRP-1451 URL: https://issues.jboss.org/browse/JGRP-1451 Project: JGroups Issue Type: Bug Affects Versions: 3.0.9 Reporter: David Hotham Assignee: Bela Ban Same stress test as in JGRP-1450 etc: a group of four members, keep killing two (picked at random), expect that the group will eventually heal itself. This one's rather a complicated sequence of events, if I've understood it correctly. I'll do my best to explain - but do ask if something's not clear or you'd like to see more details. * start with everyone agreeing that the view is [C, D, B, A] * kill C and D * On seeing this, A's FD_SOCK pinger tries but fails to connect to B ** I think this is a race where previously D was monitoring B, and now A wants to monitor B ** B hasn't yet spotted that D has gone, and so is not ready to accept a new connection from A ** This is a bit of a guess, but I don't think this detail is critical. * So now A suspects everyone else and forms a view [A]. * Meanwhile B only suspects C and D, so forms a view [B, A] So far, I think, this is OK. The two sub-groups have different coordinators, so I expect that if everything stayed static here then in due course we'd get a merge and all would be well. * C and D restart. They both join B's sub-group. * So now A has [A], and B, C and D all have [B, A, C, D] Again, I think that this is still OK and should be resolved by a merge soon enough. * Now B and C are killed. ** D sees that the new view would be [A, D] in which it would not be coordinator. So it doesn't install any new view. ** A doesn't care I'm not sure what would happen if we left things alone now: ie whether the group would recover or not. But in fact the stress test restarted B and C, so we go on... * B and C restart. Now they both join A's subgroup (C first, as it happens). * So A, B and C all end up with the view [A, C, B] * Meanwhile D still thinks that the view is [B, A, C, D] Now we seem to have a problem (and in my test, this is where things stopped happening): * A declines to lead a merge: it regularly logs "I (10.239.0.1) won't be the merge leader" ** Presumably it is deciding that B would be a better merge leader * But B doesn't think that it's a coordinator, so it won't merge either. So we're stuck, with two different views! How is this situation expected to resolve itself? Thanks David -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
34
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 June 2012