[JBoss JIRA] (WFLY-3040) Missing modules
by David Cabillic (JIRA)
David Cabillic created WFLY-3040:
------------------------------------
Summary: Missing modules
Key: WFLY-3040
URL: https://issues.jboss.org/browse/WFLY-3040
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: OSGi
Affects Versions: 8.0.0.Final
Environment: Windows 64 bits
Reporter: David Cabillic
Assignee: Thomas Diesler
I listed modules with links to missing ones :
|| module || missing module ||
| org.infinispan.client.hotrod | com.google.protobuf |
| org.jboss.as.aggregate | org.jboss.as.managed-beans |
| org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 9 months
[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs
by Ales Justin (JIRA)
[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ]
Ales Justin commented on JBVFS-194:
-----------------------------------
[~goldmann] >> Can they be replaced with something dummy?
They are dummy. We're just testing their structure; .ear with nested jars / wars.
Or what's the issue with them?
> 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
10 years, 9 months
[JBoss JIRA] (WFLY-2899) Help and error messages in Main classes should be printed raw
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2899?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2899:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1069514|https://bugzilla.redhat.com/show_bug.cgi?id=1069514] from POST to MODIFIED
> Help and error messages in Main classes should be printed raw
> -------------------------------------------------------------
>
> Key: WFLY-2899
> URL: https://issues.jboss.org/browse/WFLY-2899
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
> Fix For: 8.0.1.Final
>
>
> The help in standalone and host-controller main methods gets printed after {{System.out}} and {{System.err}} have been captured by jboss-stdio. This leads the help and errors being printed in a log manager format rather than just the raw text.
> Example output:
> {code}
> [jperkins@jperkins-rh wildfly]$ ./build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/standalone.sh -help
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/jperkins/projects/jboss/as/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT
> JAVA: java
> JAVA_OPTS: -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:31:43,895 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 15:31:44,918 INFO [stdout] (main)
> 15:31:44,918 INFO [stdout] (main) Usage: standalone.sh [args...]
> 15:31:44,918 INFO [stdout] (main) where args include:
> 15:31:44,918 INFO [stdout] (main) --admin-only Set the server's running type to
> 15:31:44,919 INFO [stdout] (main) ADMIN_ONLY causing it to open
> 15:31:44,919 INFO [stdout] (main) administrative interfaces and accept
> 15:31:44,919 INFO [stdout] (main) management requests but not start other
> 15:31:44,920 INFO [stdout] (main) runtime services or accept end user
> 15:31:44,920 INFO [stdout] (main) requests.
> 15:31:44,920 INFO [stdout] (main)
> 15:31:44,920 INFO [stdout] (main)
> 15:31:44,921 INFO [stdout] (main) -b <value>, -b=<value> Set system property jboss.bind.address
> 15:31:44,921 INFO [stdout] (main) to the given value
> 15:31:44,921 INFO [stdout] (main)
> 15:31:44,921 INFO [stdout] (main)
> 15:31:44,922 INFO [stdout] (main) -b<interface>=<value> Set system property
> 15:31:44,922 INFO [stdout] (main) jboss.bind.address.<interface> to the
> 15:31:44,922 INFO [stdout] (main) given value
> 15:31:44,922 INFO [stdout] (main)
> 15:31:44,923 INFO [stdout] (main)
> 15:31:44,923 INFO [stdout] (main) -c <config>, -c=<config> Name of the server configuration file
> 15:31:44,923 INFO [stdout] (main) to use (default is "standalone.xml")
> 15:31:44,923 INFO [stdout] (main) (Same as --server-config)
> 15:31:44,924 INFO [stdout] (main)
> 15:31:44,924 INFO [stdout] (main)
> 15:31:44,924 INFO [stdout] (main) --debug [<port>] Activate debug mode with an optional
> 15:31:44,924 INFO [stdout] (main) argument to specify the port. Only
> 15:31:44,925 INFO [stdout] (main) works if the launch script supports it.
> 15:31:44,925 INFO [stdout] (main)
> 15:31:44,925 INFO [stdout] (main)
> 15:31:44,925 INFO [stdout] (main) -D<name>[=<value>] Set a system property
> 15:31:44,926 INFO [stdout] (main)
> 15:31:44,926 INFO [stdout] (main)
> 15:31:44,926 INFO [stdout] (main) -h, --help Display this message and exit
> 15:31:44,927 INFO [stdout] (main)
> 15:31:44,927 INFO [stdout] (main)
> 15:31:44,927 INFO [stdout] (main) --read-only-server-config=<config> Name of the server configuration file
> 15:31:44,927 INFO [stdout] (main) to use. This differs from
> 15:31:44,928 INFO [stdout] (main) '--server-config' and '-c' in that the
> 15:31:44,928 INFO [stdout] (main) original file is never overwritten.
> 15:31:44,928 INFO [stdout] (main)
> 15:31:44,928 INFO [stdout] (main)
> 15:31:44,929 INFO [stdout] (main) -P <url>, -P=<url>, Load system properties from the given
> 15:31:44,929 INFO [stdout] (main) --properties=<url> url
> 15:31:44,929 INFO [stdout] (main)
> 15:31:44,929 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main) -S<name>[=<value>] Set a security property
> 15:31:44,930 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main) --server-config=<config> Name of the server configuration file
> 15:31:44,931 INFO [stdout] (main) to use (default is "standalone.xml")
> 15:31:44,931 INFO [stdout] (main) (Same as -c)
> 15:31:44,931 INFO [stdout] (main)
> 15:31:44,931 INFO [stdout] (main)
> 15:31:44,932 INFO [stdout] (main) -u <value>, -u=<value> Set system property
> 15:31:44,932 INFO [stdout] (main) jboss.default.multicast.address to the
> 15:31:44,932 INFO [stdout] (main) given value
> 15:31:44,933 INFO [stdout] (main)
> 15:31:44,933 INFO [stdout] (main)
> 15:31:44,933 INFO [stdout] (main) -v, -V, --version Print version and exit
> 15:31:44,934 INFO [stdout] (main)
> 15:31:44,934 INFO [stdout] (main)
> {code}
--
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, 9 months
[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1722:
--------------------------------
As every message that needs to be encrypted (when sent or received) has to acquire the *single* lock in {{ENCRYPT}}, even unrelated messages (e.g. from different senders or tagged as {{OOB|DONT_BUNDLE}}) are delivered or sent sequentially.
SOLUTION: use a pool of ciphers. Each cipher has a related lock. A sender or receiver thread grabs a random cipher and locks its associated lock. This way, lock requests are striped and the single lock bottleneck is removed. The pool size (and thus the lock striping) needs to be configurable.
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
> Key: JGRP-1722
> URL: https://issues.jboss.org/browse/JGRP-1722
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4
> Reporter: Martin Gencur
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads.
> It would be great if we could improve the performance of ENCRYPT protocol.
--
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, 9 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 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
10 years, 9 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
10 years, 9 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
10 years, 9 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
10 years, 9 months