[JBoss JIRA] (LOGTOOL-76) JBoss Logging Processor should support WSDLException
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-76?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGTOOL-76:
------------------------------------
We talked about possibly having a way to override or specify the argument offset of the message parameter, and maybe providing a way to feed other parameters in as well.
> JBoss Logging Processor should support WSDLException
> ----------------------------------------------------
>
> Key: LOGTOOL-76
> URL: https://issues.jboss.org/browse/LOGTOOL-76
> Project: Log Tool
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Tom Cunningham
> Assignee: David Lloyd
>
> This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
> {code}
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg,
> java.lang.Throwable t)
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg)
> {code}
> When I try to localize with this :
> {code}
> /**
> * couldNotFindServiceInTheWSDL method definition.
> * @param portName the portName
> * @param definitionDocumentBaseURI definitionDocumentBaseURI
> * @return WSDLException
> */
> @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
> WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
> {code}
> I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors. We should support them.
> {noformat}
> Failure:
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> {noformat}
--
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
12 years, 2 months
[JBoss JIRA] (LOGTOOL-76) JBoss Logging Processor should support WSDLException
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-76?page=com.atlassian.jira.plugin... ]
David Lloyd updated LOGTOOL-76:
-------------------------------
Description:
This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
{code}
public WSDLException(java.lang.String faultCode,
java.lang.String msg,
java.lang.Throwable t)
public WSDLException(java.lang.String faultCode,
java.lang.String msg)
{code}
When I try to localize with this :
{code}
/**
* couldNotFindServiceInTheWSDL method definition.
* @param portName the portName
* @param definitionDocumentBaseURI definitionDocumentBaseURI
* @return WSDLException
*/
@Message(id = 35436, value = "Could not find service %s in the WSDL %s")
WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
{code}
I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors. We should support them.
{noformat}
Failure:
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
{noformat}
was:
This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
public WSDLException(java.lang.String faultCode,
java.lang.String msg,
java.lang.Throwable t)
public WSDLException(java.lang.String faultCode,
java.lang.String msg)
When I try to localize with this :
/**
* couldNotFindServiceInTheWSDL method definition.
* @param portName the portName
* @param definitionDocumentBaseURI definitionDocumentBaseURI
* @return WSDLException
*/
@Message(id = 35436, value = "Could not find service %s in the WSDL %s")
WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors. We should support them.
Failure:
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> JBoss Logging Processor should support WSDLException
> ----------------------------------------------------
>
> Key: LOGTOOL-76
> URL: https://issues.jboss.org/browse/LOGTOOL-76
> Project: Log Tool
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Tom Cunningham
> Assignee: David Lloyd
>
> This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
> {code}
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg,
> java.lang.Throwable t)
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg)
> {code}
> When I try to localize with this :
> {code}
> /**
> * couldNotFindServiceInTheWSDL method definition.
> * @param portName the portName
> * @param definitionDocumentBaseURI definitionDocumentBaseURI
> * @return WSDLException
> */
> @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
> WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
> {code}
> I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors. We should support them.
> {noformat}
> Failure:
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> {noformat}
--
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
12 years, 2 months
[JBoss JIRA] (WFLY-881) jar references in tmp/vfs consuming file handles
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-881?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved WFLY-881.
------------------------------
Resolution: Out of Date
Presumably this is no longer a problem.
> jar references in tmp/vfs consuming file handles
> ------------------------------------------------
>
> Key: WFLY-881
> URL: https://issues.jboss.org/browse/WFLY-881
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: VFS
> Reporter: Nicklas Karlsson
> Assignee: David Lloyd
>
> I see deployments in standalone/tmp/vfs/deployment1bdffd9028e55f79 that keep reference to multiple instances of the jars like
> joda-time-1.6.2.jar-38f02aa25a811ed4
> joda-time-1.6.2.jar-74d1519d59ff978d
> joda-time-1.6.2.jar-b197315704b17d7
> joda-time-1.6.2.jar-bc1bb40870af7097
> 3-4 of each jar and they all consume a file handle on OS level. Are they all needed?
> all in all, the AS takes up around 1000 file handles on 4 deployed applications, causing out of file handles-errors if more applications are deployed without raising the limits.
--
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
12 years, 2 months
[JBoss JIRA] (LOGMGR-80) Support Logback similar to how Log4J is supported
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-80?page=com.atlassian.jira.plugin.... ]
David Lloyd updated LOGMGR-80:
------------------------------
Assignee: James Perkins (was: David Lloyd)
> Support Logback similar to how Log4J is supported
> -------------------------------------------------
>
> Key: LOGMGR-80
> URL: https://issues.jboss.org/browse/LOGMGR-80
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Kyle Lape
> Assignee: James Perkins
>
> It would be nice to have support for Logback similar to how we support Log4J. Specifically, provide a modified version of Logback with customizations that account for the classloading behavior of Wildfly/JBoss Modules, thus removing the need to include logback libraries in deployments.
> It could be argued that there is no need for this because Logback does not provide a logging facade API and that anyone that migrates to Wildfly should migrate their {{logback.xml}} to something JBoss already supports. While that's a valid point, any help that could be provided to folks migrating to Wildfly would be appreciated.
--
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
12 years, 2 months
[JBoss JIRA] (JBAS-9542) Log file jboss.log gets truncated after restarting the server
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBAS-9542?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved JBAS-9542.
-------------------------------
Resolution: Done
This issue was fixed in JBoss LogManager some time ago. At this time it doesn't seem useful to backport the component upgrade though, if it wasn't already done.
> Log file jboss.log gets truncated after restarting the server
> -------------------------------------------------------------
>
> Key: JBAS-9542
> URL: https://issues.jboss.org/browse/JBAS-9542
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 6.1.0
> Environment: Windows, Linux
> Reporter: Sergey Goldberg
> Assignee: David Lloyd
> Labels: jboss
>
> Every time the server is restarted its log file jboss.log gets truncated even when the "append" property is set to true (handler.FILE.append=true) in the logging.properties file.
--
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
12 years, 2 months
[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ]
David Lloyd moved WFLY-1215 to JBVFS-194:
-----------------------------------------
Project: JBoss VFS (was: WildFly)
Key: JBVFS-194 (was: WFLY-1215)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: (was: VFS)
> Clean the status of testing jars for jboss-vfs
> ----------------------------------------------
>
> Key: JBVFS-194
> URL: https://issues.jboss.org/browse/JBVFS-194
> Project: JBoss VFS
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Marek Goldmann
> Assignee: David Lloyd
>
> There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior.
> What's the status of following files? Who wrote them and what is the license of those and where is the upstream code?
> ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar
> ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar
> Can they be replaced with something dummy?
--
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
12 years, 2 months
[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned JBVFS-194:
---------------------------------
Assignee: Ales Justin (was: David Lloyd)
Aleš, would you mind fixing or removing these tests please?
Thank you.
> Clean the status of testing jars for jboss-vfs
> ----------------------------------------------
>
> Key: JBVFS-194
> URL: https://issues.jboss.org/browse/JBVFS-194
> Project: JBoss VFS
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Marek Goldmann
> Assignee: Ales Justin
>
> There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior.
> What's the status of following files? Who wrote them and what is the license of those and where is the upstream code?
> ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar
> ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar
> Can they be replaced with something dummy?
--
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
12 years, 2 months
[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ]
David Lloyd updated JBVFS-194:
------------------------------
Priority: Critical (was: Major)
> Clean the status of testing jars for jboss-vfs
> ----------------------------------------------
>
> Key: JBVFS-194
> URL: https://issues.jboss.org/browse/JBVFS-194
> Project: JBoss VFS
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Marek Goldmann
> Assignee: Ales Justin
> Priority: Critical
>
> There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior.
> What's the status of following files? Who wrote them and what is the license of those and where is the upstream code?
> ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar
> ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar
> Can they be replaced with something dummy?
--
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
12 years, 2 months