[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-6408:
------------------------------------------
Bernd
Thank you for pointing out this issue and providing the scripts.
I have reproduced it myself and will be investigating asap.
> Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT
> ---------------------------------------------------------------------------
>
> Key: AS7-6408
> URL: https://issues.jboss.org/browse/AS7-6408
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.2.0.Alpha1
> Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013)
> Reporter: Bernd Koecke
> Assignee: Richard Achmatowicz
> Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml
>
>
> When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment.
> When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6410) Session beans are not bound to JNDI if there is a remote interface for a stateless bean
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6410?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-6410:
-------------------------------------
This appears to be working against upstream.
> Session beans are not bound to JNDI if there is a remote interface for a stateless bean
> ---------------------------------------------------------------------------------------
>
> Key: AS7-6410
> URL: https://issues.jboss.org/browse/AS7-6410
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming, Remoting
> Affects Versions: 7.1.1.Final
> Environment: Ubuntu 12.10
> Reporter: Jari Juslin
> Assignee: jaikiran pai
> Attachments: bugrepro.zip
>
>
> I have a session bean inside a jar, which in turn is inside an ear. If the session bean's interface is market with @Remote, JBoss 7.1.1 does not bind any beans in the package to JNDI. Change the @Remote to @Local or comment it out and binding takes place.
> The binding was checked both programmatically and from JBoss Management Console.
> No errors messages are printed.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6413) Remove subsystem command in JGroups management api should remove existing stacks.
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-6413?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz reassigned AS7-6413:
----------------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> 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: Richard Achmatowicz
> 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
13 years, 4 months
[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
13 years, 4 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
13 years, 4 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
13 years, 4 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
13 years, 4 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
13 years, 4 months