December 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBWEB-190) TomcatResolver in RewriteValve can't resolve environment variable previously stored by a RewriteRule directive

by Wenwei Liao (JIRA)

TomcatResolver in RewriteValve can't resolve environment variable previously stored by a RewriteRule directive -------------------------------------------------------------------------------------------------------------- Key: JBWEB-190 URL: https://jira.jboss.org/browse/JBWEB-190 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Rewrite Valve Reporter: Wenwei Liao Assignee: Remy Maucherat In the following test case, http://test.foo.net/news/123 will be rewrote into /null.do instead of /test.do RewriteCond %{HTTP_HOST} ^(.*).foo.net$ [NC] RewriteRule .* $0 [E=subdomain:%1] # news RewriteRule /news/(\d+) /%{ENV:subdomain}.do [L] It seems that subdomain=test has been stored into request.attributes but TomcatResolver doesn't retrive subdomain from request.attributes but via System.getProperty -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
4
0 / 0

[JBoss JIRA] Commented: (JBAS-8290) Implement solid SessionObjectReference

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8290?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on JBAS-8290: --------------------------------- The CDI TCK does not currently test this, however it is part of the web profile support for CDI, so should be in AS 6. > Implement solid SessionObjectReference > -------------------------------------- > > Key: JBAS-8290 > URL: https://jira.jboss.org/browse/JBAS-8290 > Project: JBoss Application Server > Issue Type: Bug > Components: Weld/CDI > Reporter: Pete Muir > Assignee: Marius Bogoevici > Priority: Blocker > Fix For: 6.0.0.Final > > > JBossSessionObjectReference is a bit hacky right now: > 1) Needs a proper implementation of isRemoved which interrogates the EJB container to determine the state of the reference > 2) Needs a Remove implementation that can cope with no-interface-view beans > 3) Needs to lookup the actual reference for getBusinessObject() not just cast the local proxy. Note that we may request remote EJBs through this mechanism! -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-8286) Wrong classloader used in InterceptorMethodHandler.readObject in JBoss AS

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8286?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on JBAS-8286: --------------------------------- Marius or someone, can you provide a hint about how to test serialization in the AS? > Wrong classloader used in InterceptorMethodHandler.readObject in JBoss AS > ------------------------------------------------------------------------- > > Key: JBAS-8286 > URL: https://jira.jboss.org/browse/JBAS-8286 > Project: JBoss Application Server > Issue Type: Bug > Affects Versions: TBD-6.x > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 6.0.0.Final > > > See org.jboss.weld.test.unit.interceptor.passivation.PassivationActivationTest.testPassivationAndActivation() > It looks to me like the classloader of jboss-interceptor (the classloader for the deployer) is used to deserialize the proxy, whilst the WeldImpl exists on the application classloader -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-8692) Module.xml should not import the "system" module without filtering

by Kabir Khan (JIRA)

Module.xml should not import the "system" module without filtering ------------------------------------------------------------------ Key: JBAS-8692 URL: https://jira.jboss.org/browse/JBAS-8692 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ClassLoading Reporter: Kabir Khan Assignee: Kabir Khan -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8694) ServiceRefResourceProvider should not throw an exception when a service-ref has multiple injection targets

by jaikiran pai (JIRA)

ServiceRefResourceProvider should not throw an exception when a service-ref has multiple injection targets ---------------------------------------------------------------------------------------------------------- Key: JBAS-8694 URL: https://jira.jboss.org/browse/JBAS-8694 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Environment: AS trunk (date December 1 2010) Reporter: jaikiran pai Assignee: Alessio Soldano If a service-ref has multiple injection targets, the ServiceRefResourceProvider throws a UnsupportedOperationException. This is incorrect since it's perfectly valid (as per spec) to have multiple injection targets for a single resource reference -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2812) All files under drools-eclipse have ASL license header but should have an EPL license header.

by Geoffrey De Smet (JIRA)

All files under drools-eclipse have ASL license header but should have an EPL license header. --------------------------------------------------------------------------------------------- Key: JBRULES-2812 URL: https://jira.jboss.org/browse/JBRULES-2812 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-eclipse Reporter: Geoffrey De Smet Priority: Optional Fix For: FUTURE The drools-eclipse pom.xml has the correct license (EPL), but all the files still have the wrong header. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7651) Revisit profiles that come pre-configured with AS

by Stan Silvert (JIRA)

Revisit profiles that come pre-configured with AS ------------------------------------------------- Key: JBAS-7651 URL: https://jira.jboss.org/jira/browse/JBAS-7651 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: ProfileService Affects Versions: JBossAS-6.0.0.M1 Reporter: Stan Silvert Assignee: Scott M Stark Priority: Blocker Fix For: JBossAS-6.0.0.M3 We need to revisit the profiles that come pre-configured with AS. The goal is to provide a robust set of profiles that cover the needs of most users out of the box. Right now we have: minimal - total bare bones default - what most people use, but you have to do stuff like secure the consoel before production standard - as far as I know, this is only for JEE certification? web - just web stuff with JTA, JCA and JPA all - everything we can throw in, but mostly used for clustering I think something like the following would better suit most user's needs. This satisfies the emerging requirement to have profiles that are useful to development and production: minimal - same as before web - JEE web profile standard - I guess we still need this? development - no admin console and less logging - super-fast boot time - (JSF2 PROJECT_STAGE set to "Development") production - includes admin console - secure - (JSF2 PROJECT_STAGE set to "Production") clustered development - same as development, but with clustered services available clustered production - same as production, but with clustered services available Also see http://community.jboss.org/message/521946#521946 -- 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, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-7535) Handle nested transactions in transaction-sticky load balance policies

by Brian Stansberry (JIRA)

Handle nested transactions in transaction-sticky load balance policies ---------------------------------------------------------------------- Key: JBAS-7535 URL: https://jira.jboss.org/jira/browse/JBAS-7535 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.CR1 If the client creates a nested transaction, ClientUserTransactionStickyInterceptor doesn't detect that the TransactionPropagationContext has changed following the response, and thus doesn't associate the target with the new TPC. Effect is the new TPC is not sticky. One possibility is to throw NotSupportedTransaction if we detect a nested transaction. But from a quick look at this code, it seems easier to support nested transactions than to throw NotSupportedTransaction. Is it as simple as detecting if the TPC changes from before and after the invocation and storing the target if it has? public class ClientUserTransactionStickyInterceptor extends AbstractTransactionStickyInterceptor { @Override public Object invoke(Invocation invocation) throws Throwable { putIfExistsTransactionTarget(invocation); Object existingTPC = getTransactionPropagationContext(); // NEW Object response = getNext().invoke(invocation); invocationHasReachedAServer(invocation, response, existingTPC); //NEW return response; } public void invocationHasReachedAServer(Invocation invocation, Object response, Object existingTPC) { Object tpc = getTransactionPropagationContext(); if (tpc == null || tpc.equals(existingTPC) == false) // NEW { /* If tpc is null when invoking a UserTransaction operation, begin() * is being called, so we remember the target where the transaction * was started. */ rememberTransactionTarget(invocation, response); } } } I don't much like detecting the nested transaction in advance and throwing an exception. Certainly not if we *can* support nested transactions; in that case it's not the interceptors place to decide what the server allows. AFAICT throwing an exception would require doing something ugly like this on every call Object existingTPC = getTransactionPropagationContext(); if (existingTPC != null && ("begin".equals(invocation.getMethod().getName()) && invocation.getMethod().getDeclaringClass().equals(UserTransaction.class)) { throw new NotSupportedTransaction("blah blah blah"); } putIfExistsTransactionTarget(invocation); Object response = getNext().invoke(invocation); invocationHasReachedAServer(invocation, response); -- 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, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2449) OSGi like ClassLoader problem

by Jacopo Torrini (JIRA)

OSGi like ClassLoader problem ----------------------------- Key: JBRULES-2449 URL: https://jira.jboss.org/jira/browse/JBRULES-2449 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.0.1.FINAL Environment: kubuntu 9.10 Reporter: Jacopo Torrini Assignee: Mark Proctor Suppose that we have a OSGi like environment, (a system made of plugins, each of them istantiated in a separated classloader. Each classloader has dependencies on other plugin-classloaders). Suppose that you have a bundle (plugin) that owns the domain model, another bundle with drools and rules on that domain model. The second plugin depends on the first. If you try to load the drools rules, drools throws a NoDefClassFoundError for the class org.drools.base.extractors.BaseObjectClassFieldReader. Investigating on code, I've found that the problem resides on the classloader used to define the pseudoclass that extract field value. In class org.drools.base.ClassFieldAccessorFactory, line 135, a ByteClassLoader is used to define the new class, but that byteclassloader uses the domain object classloader as parent classloader. In fact this byteclassloader is created by CacheEntry that is initialized with the domain object classloader, as you can see in line 275 of ClassFieldAccessorCache. At this point, because the field extractor is defined as a subclass of BaseObjectClassFieldReader defined in drools library, the domain object classloader is unable to find that class and throw the exception metioned above. -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5197) Add "RetryInterceptor" functionality to all clustered proxies

by Brian Stansberry (JIRA)

Add "RetryInterceptor" functionality to all clustered proxies ------------------------------------------------------------- Key: JBAS-5197 URL: http://jira.jboss.com/jira/browse/JBAS-5197 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.1.0.CR1 Container issue for ensuring "RetryInterceptor" functionality is added to all clustered proxies. "RetryInterceptor" functionality consists of adding an interceptor that is able to access the cluster (currently via JNDI) and get an updated set of cluster targets when all current targets have failed. Needed when a complete cluster restart has occurred since the current list of targets was deserialized on the client. We currently have this for EJB2 proxies; need it for EJB3, HA-JNDI and generic AOP-based and ProxyFactoryHA-based proxies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

4
9
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 December 2010