May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-504) Example project Maven configuration incomplete: plugin repository not configured

by Peter Horvath (JIRA)

Peter Horvath created DROOLS-504: ------------------------------------ Summary: Example project Maven configuration incomplete: plugin repository not configured Key: DROOLS-504 URL: https://issues.jboss.org/browse/DROOLS-504 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.1.Final Reporter: Peter Horvath Assignee: Mark Proctor Drools Example project uses JBoss dependencies both for libraries and Maven plugins. The JBoss repository is configured within the pom.xml _so the examples sources in the distribution zip build out-of-the-box with maven_. The same has not been done for the *pluginRepository*, as a result, Maven build fails as it cannot download JBoss plugins. Please add the necessary configuration to the example projects so that it really can be built out-of-the-box. {code:xml} <pluginRepositories> <pluginRepository> <id>jboss-public-repository-group</id> <name>JBoss Public Repository Group</name> <url>http://repository.jboss.org/nexus/content/groups/public/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories> {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3045) Expose JAXRS deployments via the management API

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-3045?page=com.atlassian.jira.plugin.... ] Ingo Weiss updated WFLY-3045: ----------------------------- Assignee: (was: Ingo Weiss) > Expose JAXRS deployments via the management API > ----------------------------------------------- > > Key: WFLY-3045 > URL: https://issues.jboss.org/browse/WFLY-3045 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, REST > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Fix For: Awaiting Volunteers > > > Currently WildFly expose webapps and ejbs deployments through the management API. I think we should also expose in a similar manner the other deployments such as REST resources -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1844) Remove shared transport

by Bela Ban (JIRA)

Bela Ban created JGRP-1844: ------------------------------ Summary: Remove shared transport Key: JGRP-1844 URL: https://issues.jboss.org/browse/JGRP-1844 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2]. Here's my reasoning: * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared * TUNNEL doesn't work with shared transports (throws an exception) * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste Thoughts ? My +100 for removing shared transports in 4.0... [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1844) Remove shared transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1844: --------------------------- Fix Version/s: 4.0 Affects Version/s: 3.5 > Remove shared transport > ----------------------- > > Key: JGRP-1844 > URL: https://issues.jboss.org/browse/JGRP-1844 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2]. > Here's my reasoning: > * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller > * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared > * TUNNEL doesn't work with shared transports (throws an exception) > * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used > * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste > Thoughts ? My +100 for removing shared transports in 4.0... > [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport > [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3045) Expose JAXRS deployments via the management API

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFLY-3045?page=com.atlassian.jira.plugin.... ] Ingo Weiss reassigned WFLY-3045: -------------------------------- Assignee: Ingo Weiss > Expose JAXRS deployments via the management API > ----------------------------------------------- > > Key: WFLY-3045 > URL: https://issues.jboss.org/browse/WFLY-3045 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, REST > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Ingo Weiss > Fix For: Awaiting Volunteers > > > Currently WildFly expose webapps and ejbs deployments through the management API. I think we should also expose in a similar manner the other deployments such as REST resources -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3393) JSP 2 different tags called with same tag instance

by roy mizrachi (JIRA)

[ https://issues.jboss.org/browse/WFLY-3393?page=com.atlassian.jira.plugin.... ] roy mizrachi commented on WFLY-3393: ------------------------------------ Hi Stuart, I do not have a reproducer but managed to find this issue by putting break points in the doStartTag(),release() methods of the javax.servlet.jsp.tagext.Tag implementation put some tags in a JSP page and run this. Thanks for the effort, Roi > JSP 2 different tags called with same tag instance > -------------------------------------------------- > > Key: WFLY-3393 > URL: https://issues.jboss.org/browse/WFLY-3393 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.1.0.CR2 > Reporter: roy mizrachi > Assignee: Stuart Douglas > > When working with JSP tags on struts i can see that sometimes 2 diffrent tags with same type is called with the same instance. > Example: > JSP > <jcv:text id="email" maxlength="255" property="valueObject.Email"/> > <br> > <jcv:text id="phone" maxlength="255" property="valueObject.Phone"/> > TLD > <tag> > <name>text</name> > <tagclass>tti.jcore.views.form.tag.JViewsTextTag</tagclass> > ... > </tag> > I can see that the public int doStartTag() called for both with the same instance. > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3404) Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.

by Timothy Heider (JIRA)

Timothy Heider created WFLY-3404: ------------------------------------ Summary: Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final. Key: WFLY-3404 URL: https://issues.jboss.org/browse/WFLY-3404 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 8.0.0.Final Reporter: Timothy Heider Assignee: Jason Greene I have deployed my application to Wildfly 8.0.0 Final and it is almost unusable now. We have rolled back to JBoss 7.1 (same application WARs) and it works fine. Specifically what seems to be slow is our SOAP web services are taking up to 8 to 10 seconds to respond. We have user concurrency of probably 10-30 users at once hitting these services every 10 seconds or so. On JBoss 7.1 these services all respond sub-second. The database is totally unburdened and the server is 90% idle all the time. We have one service endpoint that is a Comet queue wait call. Probably 10 users are waiting on that. Did something change between JBoss 7 and Wildfly 8 that might cause that to not work now? (e.g. too small a thread pool that blocks until the 10 second comet call breaks on a timeout?) We will try 8.1.0CR2 but I wanted to report we're investigating this and see if you can help us. Thanks! -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-503) Automatically infer traitability for non-declared classes

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-503: ------------------------------------- Summary: Automatically infer traitability for non-declared classes Key: DROOLS-503 URL: https://issues.jboss.org/browse/DROOLS-503 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Beta4 Reporter: Davide Sottara Assignee: Davide Sottara Priority: Minor Fix For: 6.1.0.CR1 Even if a java class is marked as @Traitable, it may still be necessary to declare it explicitly (e.g. if it is not used directly in any rule pattern). This declaration is only required to force the engine to evaluate the @Traitable status, which can be done on demand and automatically -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-502) ClasspathKieProject fails vfs: try to unzip exploded jar

by Nicolas-Xavier Vanderlinden (JIRA)

[ https://issues.jboss.org/browse/DROOLS-502?page=com.atlassian.jira.plugin... ] Nicolas-Xavier Vanderlinden commented on DROOLS-502: ---------------------------------------------------- ClasspathKieProject.java {code} public static String getPomProperties(String urlPathToAdd) { .... if ( urlPathToAdd.endsWith( ".jar" ) || urlPathToAdd.endsWith( "/content" ) ) { pomProperties = getPomPropertiesFromZipFile(rootPath); } else { pomProperties = getPomPropertiesFromFileSystem(rootPath); {code} urlPathToAdd.endsWith( ".jar" ) does not always mean that it's a zip. > ClasspathKieProject fails vfs: try to unzip exploded jar > -------------------------------------------------------- > > Key: DROOLS-502 > URL: https://issues.jboss.org/browse/DROOLS-502 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta4 > Reporter: Nicolas-Xavier Vanderlinden > Assignee: Mark Proctor > > Drools is not able to load kmodule.xml from an exploded jar inside an exploded ear. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-502) ClasspathKieProject fails vfs: try to unzip exploded jar

by Nicolas-Xavier Vanderlinden (JIRA)

Nicolas-Xavier Vanderlinden created DROOLS-502: -------------------------------------------------- Summary: ClasspathKieProject fails vfs: try to unzip exploded jar Key: DROOLS-502 URL: https://issues.jboss.org/browse/DROOLS-502 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.1.0.Beta4 Reporter: Nicolas-Xavier Vanderlinden Assignee: Mark Proctor Drools is not able to load kmodule.xml from an exploded jar inside an exploded ear. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
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 May 2014