[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6319?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6319:
---------------------------------------
On Tomaz' server we use for testing Windows builds, this started failing immediately after a JDK update to u38. Tomaz just reverted that and we'll see if that fixes the issue. There was a lightning JDK update on Jan 10 which vague memory tells me is about when this started happening there. This JIRA was created the 11th, so that fits.
This all ties into the notion that this is related to the discussion at http://stackoverflow.com/questions/14270311/rather-mysterious-socketexcep....
u38 had changes to HttpClient:
stuartdouglas: http://www.oracle.com/technetwork/java/javase/2col/6u38-bugfixes-1880999....
stuartdouglas: "Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases"
> EJBEndpointAuthenticationTestCase is failing intermittently
> ------------------------------------------------------------
>
> Key: AS7-6319
> URL: https://issues.jboss.org/browse/AS7-6319
> Project: Application Server 7
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 7.2.0.Alpha1
> Environment: AS7 upstream (Jan 11 2013)
> Reporter: jaikiran pai
> Assignee: Jim Ma
> Attachments: log.txt
>
>
> The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these:
> {code}
> java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352
> {code}
> same goes also for PojoEndpointAuthenticationTestCase that fails sometimes
> {code}
> javax.xml.ws.WebServiceException: Could not send Message.
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> at $Proxy110.hello(Unknown Source)
> at org.jboss.as.test.integration.ws.authentication.PojoEndpointAuthenticationTestCase.accessHelloWithValidUser1(PojoEndpointAuthenticationTestCase.java:116)
> ...
> Caused by: java.net.SocketException: Socket Closed
> at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:286)
> at java.net.Socket.getSoTimeout(Socket.java:1032)
> at sun.net.www.http.HttpClient.available(HttpClient.java:356)
> {code}
> It looks like the testcase expects a specific text in the exception cause.
--
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, 11 months
[JBoss JIRA] (AS7-6413) Remove subsystem command in JGroups management api should remove existing stacks.
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created AS7-6413:
----------------------------------------
Summary: Remove subsystem command in JGroups management api should remove existing stacks.
Key: AS7-6413
URL: https://issues.jboss.org/browse/AS7-6413
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.2.0.Alpha1
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Fix For: 7.2.0.Alpha1
The management command
{noformat}
/subsystem=jgroups:remove()
{noformat}
should check for existing stack children and remove their runtime services before removing its own runtime services.
Otherwise removing the JGroups subsystem, followed by adding it back in and creating a new stack with the same name will fail due to duplicate MSC services associated with the stack.
--
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, 11 months
[JBoss JIRA] (AS7-6262) Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/AS7-6262?page=com.atlassian.jira.plugin.s... ]
Stan Silvert commented on AS7-6262:
-----------------------------------
Mojarra issue http://java.net/jira/browse/JAVASERVERFACES-2703
> Dynamically added JSF converter ignored in some cases since Mojarra 2.1.16 upgrade
> ----------------------------------------------------------------------------------
>
> Key: AS7-6262
> URL: https://issues.jboss.org/browse/AS7-6262
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.1.4.Final (EAP)
> Environment: Current 7.1.4.Final-SNAPSHOT (2013-01-02 be583f5)
> Reporter: Marek Schmidt
> Assignee: Stan Silvert
> Fix For: 7.1.4.Final (EAP)
>
> Attachments: AS7-6262.tar.gz, AS7-6262.war, reproducer-pure.tar.gz, reproducer-pure.war, reproducer.tar.gz, reproducer.war
>
>
> Dynamically created converters seems to be ignored in some special cases, like the following.
> Having a form like this:
> {code}
> <h:form>
> <ul>
> <ui:repeat value="#{basket.items}" var="i">
> <li>Item #{i.number}
> <h:selectOneMenu value="#{i.color}">
> <test:selectColors />
> </h:selectOneMenu>
> </li>
> </ui:repeat>
> </ul>
> <div>
> <h:commandButton value="Add" action="#{basket.add}" />
> </div>
> <h:outputText value="#{basket.string}" />
> </h:form>
> {code}
> Where SelectColors is
> {code}
> @JsfComponent(description=@Description(displayName="org.jboss.seam.test.SelectColors",value="Creates a List<SelectItem> of colors."),
> family="javax.faces.SelectItems", type="org.jboss.seam.test.SelectColors",generate="org.jboss.seam.test.html.HtmlSelectColors",
> tag = @Tag(baseClass="javax.faces.webapp.UIComponentTagBase", name="selectColors"))
> public class SelectColors extends javax.faces.component.UISelectItems implements SystemEventListener {
> public SelectColors() {
> FacesContext context = FacesContext.getCurrentInstance();
> UIViewRoot root = context.getViewRoot();
> root.subscribeToViewEvent( PreRenderViewEvent.class, this );
> }
> @Override
> public Object getValue() {
> List<SelectItem> ret = new LinkedList<SelectItem> ();
> ret.add(new SelectItem("default", "Select color... (black by default)"));
> ret.add(new SelectItem("red", "Red"));
> ret.add(new SelectItem("white", "White"));
> ret.add(new SelectItem("blue", "Blue"));
> ret.add(new SelectItem("black", "Black"));
> return ret;
> }
> private void addSelectionConverter() {
> UIComponent parentComponent = getParent();
> if (parentComponent instanceof ValueHolder) {
> ValueHolder parentValueHolder = (ValueHolder) parentComponent;
> Converter parentConverter = parentValueHolder.getConverter();
> if (parentConverter == null) {
> parentValueHolder.setConverter(new DefaultColorConverter());
> }
> }
> }
> @Override
> public void processEvent(SystemEvent event) throws AbortProcessingException
> {
> if ( !FacesContext.getCurrentInstance().isPostback() ) {
> addSelectionConverter();
> }
> }
> @Override
> public boolean isListenerForSource(Object source)
> {
> return ( source instanceof UIViewRoot );
> }
> }
> {code}
> and the DefaultColorConverter being:
> {code}
> @FacesConverter(value="org.jboss.seam.test.DefaultColorConverter")
> public class DefaultColorConverter implements Converter
> {
> public static final String DEFAULT_COLOR = "black";
> public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
> {
> if ("default".equals(value)) {
> return DEFAULT_COLOR;
> }
>
> return value;
> }
> public String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException
> {
> return value.toString();
> }
> }
> {code}
> In the pre-Mojarra 2.1.16 upgrade, clicking on the add button repeatedly creates "black" items. Post mojarra 2.1.16, it sets the color to "default", which should never happen, as the converter should convert the "default" value into "black".
--
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, 11 months
[JBoss JIRA] (AS7-430) DomainController discovery system
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-430?page=com.atlassian.jira.plugin.sy... ]
Brian Stansberry commented on AS7-430:
--------------------------------------
Please go ahead and close PR 3593, since we know for sure that will not go in as-is. This generic stuff is a good thing to have.
I didn't notice before that the only child allowed under <discovery-options> was S3. Now you can support both static and S3, via the generic element. That's great, as it allows an important use case of configuring for a 2nd master HC, which would be brought on-line when the primary failed, with no need for any config change on the slaves to let them detect it and connect.
For static discovery, a non-generic configuration is better though. That's so basic it's something we'd always support, so it's a bit different from the more specialized S3.
{code}
<discovery-option>
<static-discovery host="172.16.81.100" port="9999"/>
<discovery-option name="option-one" code="org.jboss.as.host.controller.discovery.S3Discovery">
<property name="access-key" value="s3_access_key"/>
<property name="secret-access-key" value="s3_secret_access_key"/>
<property name="location" value="s3_bucket_name"/>
</discovery-option>
</discovery-option>
{code}
> DomainController discovery system
> ---------------------------------
>
> Key: AS7-430
> URL: https://issues.jboss.org/browse/AS7-430
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Farah Juma
> Fix For: 7.3.0.Alpha1
>
>
> Mechanism(s) by which a Host Controller finds a Domain Controller so it can begin the process of integrating into the domain.
> Task includes the host.xml schema elements to configure this, the domain object model classes behind those elements, and the actual implementation of discovery from both the ServerManager and DomainController sides.
--
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, 11 months
[JBoss JIRA] (AS7-430) DomainController discovery system
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/AS7-430?page=com.atlassian.jira.plugin.sy... ]
Farah Juma commented on AS7-430:
--------------------------------
Created a new branch: https://github.com/fjuma/jboss-as/commits/AS7-430_refactored
This is a refactored version of my original implementation to allow discovery options to be specified using a generic untyped configuration instead of a typed configuration. In particular, the <discovery-options> element can now have any number of <discovery-option> children. A <discovery-option> specifies:
- a class that implements the DiscoveryOption interface (note: the module that contains this class can optionally be specified as well)
- key/value properties for the particular discovery option
Sample Configuration -
Slave host controller (note: this example configures only S3 discovery):
{code:xml}
<remote security-realm="ManagementRealm">
<discovery-options>
<discovery-option name="option-one" code="org.jboss.as.host.controller.discovery.S3Discovery">
<property name="access-key" value="s3_access_key"/>
<property name="secret-access-key" value="s3_secret_access_key"/>
<property name="location" value="s3_bucket_name"/>
</discovery-option>
</discovery-options>
</remote>
{code}
The remote domain controller's host and port can also still be statically configured, exactly as before. Additional static discovery options can also be provided via the <discovery-option> element, as follows:
Slave host controller (note: this example configures multiple static discovery options):
{code:xml}
<remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm">
<discovery-options>
<discovery-option name="backup-hc-one" code="org.jboss.as.host.controller.discovery.StaticDiscovery">
<property name="host" value="172.16.81.100"/>
<property name="port" value="9999"/>
</discovery-option>
<discovery-option name="backup-hc-two" code="org.jboss.as.host.controller.discovery.StaticDiscovery">
<property name="host" value="172.16.81.101"/>
<property name="port" value="9999"/>
</discovery-option>
</discovery-options>
</remote>
{code}
Should I close the existing pull request (https://github.com/jbossas/jboss-as/pull/3593) that uses a typed configuration and open a new one for this refactored version instead?
> DomainController discovery system
> ---------------------------------
>
> Key: AS7-430
> URL: https://issues.jboss.org/browse/AS7-430
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Farah Juma
> Fix For: 7.3.0.Alpha1
>
>
> Mechanism(s) by which a Host Controller finds a Domain Controller so it can begin the process of integrating into the domain.
> Task includes the host.xml schema elements to configure this, the domain object model classes behind those elements, and the actual implementation of discovery from both the ServerManager and DomainController sides.
--
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, 11 months
[JBoss JIRA] (AS7-6412) Transformation logging issues
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6412:
-------------------------------------
Summary: Transformation logging issues
Key: AS7-6412
URL: https://issues.jboss.org/browse/AS7-6412
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
Kind of a grab bag dumping ground for issues I've noted with the new transformation logging stuff.
Here's an example message I saw posted in an unrelated discussion:
subsystem 'infinispan' model version 'null' -- attributes null JBAS014886: are not understood in that model version and this resource will need to be ignored on that host.
I'm not sure about the model version 'null' bit. Maybe that was a dev error, or perhaps a bug. If there are valid cases for 'null' there the logic needs to account for that and output something nicer.
The "attributes null" bit: we need to deal with cases where no attribute names are passed in. (There are cases like this.) If that happens the entire "attributes xxx" bit should be skipped.
The message param passed in is going to be an i18n message, so the message structure should account for that and not try to assume some particular English grammar. For example
Subsystem 'infinispan' model version '1.2.3' -- attribute(s) abc, def had the following problem: JBAS014886: Attributes are not understood in that model version and this resource will need to be ignored on that host.
--
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, 11 months
[JBoss JIRA] (JASSIST-183) API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-183?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-183:
--------------------------------------
Andrei, can you mention JASSIST-183 on the seam-dev mailing list so others will know about this issue? I wonder if Seam could work around it.
> API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
> ---------------------------------------------------------------------------------------
>
> Key: JASSIST-183
> URL: https://issues.jboss.org/browse/JASSIST-183
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA, 3.17.1-GA
> Environment: Seam 2.2.2 / 2.3.0, Java 7u9
> Reporter: Andrei Ivanov
> Assignee: Shigeru Chiba
> Priority: Blocker
> Labels: regression
>
> Checking how some applications run with Java 7, I've tried to upgrade to the newly released Javassist just to notice Seam is no longer working:
> {noformat}
> java.lang.NoSuchMethodError: javassist.util.proxy.RuntimeSupport.findSuperMethod(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/reflect/Method;
> at OrderInitializer_$$_javassist_seam_0.writeReplace(OrderInitializer_$$_javassist_seam_0.java)
> at org.jboss.seam.Component.postConstructJavaBean(Component.java:1461)
> at org.jboss.seam.Component.postConstruct(Component.java:1379)
> at org.jboss.seam.Component.newInstance(Component.java:2155)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
> at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:143)
> at org.jboss.seam.init.Initialization.init(Initialization.java:744)
> at org.jboss.seam.mock.AbstractSeamTest.startSeam(AbstractSeamTest.java:929)
> at org.jboss.seam.mock.SeamTest.startSeam(SeamTest.java:69)
> {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, 11 months
[JBoss JIRA] (AS7-6411) Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6411?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6411:
----------------------------------
Assignee: Darran Lofthouse (was: Brian Stansberry)
> Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."
> ----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6411
> URL: https://issues.jboss.org/browse/AS7-6411
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
> Reporter: Bernard Giroud
> Assignee: Darran Lofthouse
> Labels: as7, management
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
> cygwin = true;
> {code}
> It should read:
> {code}
> cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {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, 11 months