[JBoss JIRA] Created: (JBAS-3750) log of JMS LinkedException when handling provider failure
by Luc Texier (JIRA)
log of JMS LinkedException when handling provider failure
---------------------------------------------------------
Key: JBAS-3750
URL: http://jira.jboss.com/jira/browse/JBAS-3750
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Luc Texier
Assigned To: Luc Texier
Priority: Minor
Fix For: JBossAS-4.0.5.GA
the JMSException's linked exception data is quite useful to log when debugging issues related to integration with forein jms provider.
here a possible version of the required change in org.jboss.ejb.plugins.jms.JMSContainerInvoker:handleFailure()
public void handleFailure(Throwable t)
{
log.warn("JMS provider failure detected: ", t);
failure = t;
// Helpful to debug issues when WSMQ is the jms provider
if(t instanceof JMSException) {
Exception le = ((JMSException)t).getLinkedException();
if (le != null) {
log.trace("Linked exception: "+le);
log.trace("Linked exception: cause: "+le.getCause() );
}
}
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3722) on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
by Prabhat Jha (JIRA)
on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
--------------------------------------------------------------
Key: JBAS-3722
URL: http://jira.jboss.com/jira/browse/JBAS-3722
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Naming
Affects Versions: JBossAS-4.0.5.GA
Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
Reporter: Prabhat Jha
Assigned To: Scott M Stark
testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
... 19 more
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
... 20 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:461)
at java.net.Socket.connect(Socket.java:411)
at java.net.Socket.<init>(Socket.java:310)
at java.net.Socket.<init>(Socket.java:212)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBSEAM-372) s:link doesn't get parent conversation Id after exit of nested conversation
by Christian Bauer (JIRA)
s:link doesn't get parent conversation Id after exit of nested conversation
---------------------------------------------------------------------------
Key: JBSEAM-372
URL: http://jira.jboss.com/jira/browse/JBSEAM-372
Project: JBoss Seam
Issue Type: Bug
Reporter: Christian Bauer
Priority: Minor
Consider this sequence:
- Conversation A -> s:link = startB(value, conversationId=A)
- Nested B -> h:commandButton = Conversation.instance().endAndRedirect(conversationId=B);
- Conversation A -> s:link = startB(value, conversationId=null)
- crash
Basically, it looks like s:link doesn't append a conversation id if the conversation is marked as being discarded after RENDER RESPONSE. This is the case in the RENDER_RESPONSE after the redirect out of Nested B, the conversation B will be discarded. So s:link renders without a conversation identifier. It should use the parent conversations identifier.
--
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
19 years, 3 months
[JBoss JIRA] Commented: (JBCACHE-471) Handle JGroups MERGE
by Ben Wang (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-471?page=comments#action_12344843 ]
Ben Wang commented on JBCACHE-471:
----------------------------------
Should we just define an API callback and leave it to the user to implement it? We can provide a simple default policy implementation where the new coordinator will always win, e.g., copy its state to everybody again? I think the user can come up with more sphosticated algorithm to contribute back.
> Handle JGroups MERGE
> --------------------
>
> Key: JBCACHE-471
> URL: http://jira.jboss.com/jira/browse/JBCACHE-471
> Project: JBoss Cache
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.4
> Reporter: Manik Surtani
> Assigned To: Manik Surtani
> Fix For: 2.0.0
>
>
> When JGroups needs to do a merge due to a temporary break in the group structure, JGroups does not handle the merging of data. This is usually left up to the application to handle.
> JBossCache should support pluggable merge policies, we could provide some simple merge policies and allow users to write their own.
> 1. Evict on merge policy - when a merge occurs, evict the entire in-memory state. Useful for Hibernate or when used with a shared cache loader.
> 2. Other merge algos ... ?
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBSEAM-380) actionMethod in query string not executing unless s:link rendered first
by Jye Tucker (JIRA)
actionMethod in query string not executing unless s:link rendered first
-----------------------------------------------------------------------
Key: JBSEAM-380
URL: http://jira.jboss.com/jira/browse/JBSEAM-380
Project: JBoss Seam
Issue Type: Feature Request
Affects Versions: 1.0.1
Reporter: Jye Tucker
We are using actionMethod query string parameters to control a Seam application from an external (Classic ASP) application. Effectively the navigation in the external application has links similar to /seamapp/index.jsf?actionMethod=bean.method
Currently the implementation of Pages#callAction(FacesContext) checks if an action expression exists in an Set stored in an application attribute "org.jboss.seam.actions". If the expression doesn't exist, the action is not executed. Usually an action expression is added to the set when an s:link is rendered on a page. See UIAction#allowAction(String)
This is problematic in our case as there are no s:links in the external application - therefore the set is never populated - therefore our methods aren't executed.
Suggest either:
1) A configuration flag to bypass this check system-wide or;
2) A register of methods which can be called without a security check (via components.xml or an additional method-level annotation perhaps?)
Happy to provide a patch for this if you advise a preferred implementation. My preference would be 2.
In the meantime, we work around it by manually creating the application attribute and populating it with our list of action expressions.
--
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
19 years, 3 months