[JBoss JIRA] (WFLY-3029) add remove-jndi operations to JMS resources
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-3029:
---------------------------------
Summary: add remove-jndi operations to JMS resources
Key: WFLY-3029
URL: https://issues.jboss.org/browse/WFLY-3029
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: JMS
Affects Versions: 8.0.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 8.0.1.Final
JMS resources have a "add-jndi" operation to add a JNDI binding to their entries attribute but there is no mechanism to remove one JNDI binding.
A remove-jndi operation must be added to handle this use case.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-2948) Welcome file does not work for *.jsf
by Gulam Samdani (JIRA)
[ https://issues.jboss.org/browse/WFLY-2948?page=com.atlassian.jira.plugin.... ]
Gulam Samdani closed WFLY-2948.
-------------------------------
Resolution: Done
> Welcome file does not work for *.jsf
> --------------------------------------
>
> Key: WFLY-2948
> URL: https://issues.jboss.org/browse/WFLY-2948
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Final
> Reporter: Gulam Samdani
> Assignee: Remy Maucherat
> Priority: Minor
> Fix For: 8.0.1.Final
>
>
> Welcome file does not work for *.jsf
> --------------------------------------------------------
> same problem not exists in Wildfly Beta but wildfly 8 final /cr1 gives this error ...
>
> problem :
>
> http://localhost:8080/hello ------------------------------ NO works***
> @http://localhost:8080/hello/index.jsf ------------- it works fine
> =======================================
> <welcome-file-list>
>
> <welcome-file>index.jsf</welcome-file>
>
> </welcome-file-list>
> <servlet>
> <servlet-name>Faces Servlet</servlet-name>
> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>*.jsf</url-pattern>
> </servlet-mapping>
> </web-app>
> -------------------------------------------------
> Reproduce this error :
> https://community.jboss.org/message/857300
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3028?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3028:
---------------------------------
Assignee: Tomaz Cerar (was: David Lloyd)
> It should be possible to initialize Filters on deployment rather than on first use
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3028
> URL: https://issues.jboss.org/browse/WFLY-3028
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 |
> Reporter: Nicolas Barrera
> Assignee: Tomaz Cerar
> Labels: servletfilter
>
> As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
> It happens that I have a filter chain declared in web.xml
> FilterA -> FilterB
> so that when a new request arrives FilterA is executed first and FilterB second.
> My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
> When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
> With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
> FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
> and FilterA.filter will fail because FilterB.init wasn't called earlier.
> Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
> I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3028?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3028:
------------------------------
Component/s: (was: EE)
> It should be possible to initialize Filters on deployment rather than on first use
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3028
> URL: https://issues.jboss.org/browse/WFLY-3028
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 |
> Reporter: Nicolas Barrera
> Assignee: David Lloyd
> Labels: servletfilter
>
> As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
> It happens that I have a filter chain declared in web.xml
> FilterA -> FilterB
> so that when a new request arrives FilterA is executed first and FilterB second.
> My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
> When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
> With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
> FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
> and FilterA.filter will fail because FilterB.init wasn't called earlier.
> Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
> I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use
by Nicolas Barrera (JIRA)
Nicolas Barrera created WFLY-3028:
-------------------------------------
Summary: It should be possible to initialize Filters on deployment rather than on first use
Key: WFLY-3028
URL: https://issues.jboss.org/browse/WFLY-3028
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: EE, Web (Undertow)
Affects Versions: 8.0.0.CR1
Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 |
Reporter: Nicolas Barrera
Assignee: David Lloyd
As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
It happens that I have a filter chain declared in web.xml
FilterA -> FilterB
So that when a new request arrives FilterA is executed first and FilterB second.
My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
and FilterA.filter will fail because FilterB.init wasn't called earlier.
Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use
by Nicolas Barrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-3028?page=com.atlassian.jira.plugin.... ]
Nicolas Barrera updated WFLY-3028:
----------------------------------
Description:
As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
It happens that I have a filter chain declared in web.xml
FilterA -> FilterB
so that when a new request arrives FilterA is executed first and FilterB second.
My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
and FilterA.filter will fail because FilterB.init wasn't called earlier.
Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
was:
As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
It happens that I have a filter chain declared in web.xml
FilterA -> FilterB
So that when a new request arrives FilterA is executed first and FilterB second.
My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
and FilterA.filter will fail because FilterB.init wasn't called earlier.
Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
> It should be possible to initialize Filters on deployment rather than on first use
> ----------------------------------------------------------------------------------
>
> Key: WFLY-3028
> URL: https://issues.jboss.org/browse/WFLY-3028
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EE, Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 |
> Reporter: Nicolas Barrera
> Assignee: David Lloyd
> Labels: servletfilter
>
> As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case:
> It happens that I have a filter chain declared in web.xml
> FilterA -> FilterB
> so that when a new request arrives FilterA is executed first and FilterB second.
> My problem is that FilterA needs FilterB to be initialized before it's filter method is executed.
> When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup.
> With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order:
> FilterA.init, FilterA.filter, FilterB.init, FilterB.filter
> and FilterA.filter will fail because FilterB.init wasn't called earlier.
> Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup.
> I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8.
--
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
10 years, 10 months
[JBoss JIRA] (JGRP-1660) LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1660:
---------------------------
Fix Version/s: (was: 3.4)
(was: 3.3.5)
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1660
> URL: https://issues.jboss.org/browse/JGRP-1660
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.4, 3.3.3
> Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
> Reporter: Architect SoftWeb.ISD
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)
> Object.wait(long) line: not available [native method]
> Locking$ClientLock(Object).wait() line: 485
> Locking$ClientLock.acquireTryLock(long, boolean) line: 1010
> Locking$ClientLock.tryLock() line: 896
> CENTRAL_LOCK(Locking).down(Event) line: 152
> ProtocolStack.down(Event) line: 1025
> JChannel.down(Event) line: 718
> LockService$LockImpl.tryLock() line: 102
> LockServiceStabilityTestCase$ClientImitation.run() line: 167
> Thread.run() line: 662
--
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
10 years, 10 months
[JBoss JIRA] (JGRP-1660) LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1660.
----------------------------
Resolution: Cannot Reproduce Bug
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1660
> URL: https://issues.jboss.org/browse/JGRP-1660
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.4, 3.3.3
> Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
> Reporter: Architect SoftWeb.ISD
> Assignee: Bela Ban
> Fix For: 3.5, 3.4, 3.3.5
>
> Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)
> Object.wait(long) line: not available [native method]
> Locking$ClientLock(Object).wait() line: 485
> Locking$ClientLock.acquireTryLock(long, boolean) line: 1010
> Locking$ClientLock.tryLock() line: 896
> CENTRAL_LOCK(Locking).down(Event) line: 152
> ProtocolStack.down(Event) line: 1025
> JChannel.down(Event) line: 718
> LockService$LockImpl.tryLock() line: 102
> LockServiceStabilityTestCase$ClientImitation.run() line: 167
> Thread.run() line: 662
--
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
10 years, 10 months