[JBoss JIRA] (AS7-5321) support expressions for remote-destination-outbound-socket-binding host attrib
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5321?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar reassigned AS7-5321:
--------------------------------
Assignee: Kabir Khan (was: Tomaz Cerar)
needs reject transformer for legacy version
> support expressions for remote-destination-outbound-socket-binding host attrib
> ------------------------------------------------------------------------------
>
> Key: AS7-5321
> URL: https://issues.jboss.org/browse/AS7-5321
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management
> Affects Versions: 7.1.1.Final
> Reporter: John Mazzitelli
> Assignee: Kabir Khan
> Labels: rhq
> Fix For: 7.2.0.Alpha1
>
>
> I appears that remote-destination-outbound-socket-binding resources cannot have attributes that are expressions - at least the host attrtibute. In JBossAS 4.2.3, we used to have a stock email service.xml that people could customize by simply passing in new system properties (rather than editing .xml or going through a CLI to change the values). However, in AS 7.1.1.Final, we can't do this for the mail service because at least the host attribute does not appear to allow for expressions:
> /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=mail-smtp
> My host attribute was set to the expression ${rhq.server.email.smtp-host:localhost} and when I tried to start the server, I got:
> Caused by: java.net.UnknownHostException: ${rhq.server.email.smtp-host:localhost}
> at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) [rt.jar:1.6.0_29]
> at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1202) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName0(InetAddress.java:1153) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName(InetAddress.java:1083) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName(InetAddress.java:1019) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getByName(InetAddress.java:969) [rt.jar:1.6.0_29]
> at org.jboss.as.network.OutboundSocketBinding.getDestinationAddress(OutboundSocketBinding.java:146)
> at org.jboss.as.mail.extension.MailSessionService.getServerSocketAddress(MailSessionService.java:106)
> The weird thing is, the port attribute appears to allow for expressions. When my port is set to this expression: "${rhq.server.email.smtp-port:25}", the server starts up fine (that is, after I set to the host to a legitimate hostname like "localhost")
> This JIRA is to request that expressions be supported for the host attribute as it appears to be supported for the port attribute.
--
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, 6 months
[JBoss JIRA] (AS7-5663) CLONE - System properties are currently unusable for setting a connector's proxy-name
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5663?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar reassigned AS7-5663:
--------------------------------
Assignee: Tomaz Cerar (was: Emanuel Muckenhuber)
> CLONE - System properties are currently unusable for setting a connector's proxy-name
> -------------------------------------------------------------------------------------
>
> Key: AS7-5663
> URL: https://issues.jboss.org/browse/AS7-5663
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management, Web
> Affects Versions: 7.1.1.Final
> Environment: -JBoss Enterprise Application Platform (EAP) 6.0.0
> Reporter: Aaron Ogburn
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.CR1
>
>
> A connector's proxy-name cannot be set through system properties currently in the web subsystem:
> ==domain.xml==
> <subsystem xmlns="urn:jbossomain:web:1.1" default-virtual-server="default-host" instance-id="${jboss.node.name}"
> native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" proxy-name="${jboss.proxy.name}"/>
> The property is never parsed though and
> request.getServerName() just returns ${jboss.node.name}.
--
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, 6 months
[JBoss JIRA] (AS7-5321) support expressions for remote-destination-outbound-socket-binding host attrib
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5321?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-5321:
-----------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.2.0.CR1)
> support expressions for remote-destination-outbound-socket-binding host attrib
> ------------------------------------------------------------------------------
>
> Key: AS7-5321
> URL: https://issues.jboss.org/browse/AS7-5321
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management
> Affects Versions: 7.1.1.Final
> Reporter: John Mazzitelli
> Assignee: Tomaz Cerar
> Labels: rhq
> Fix For: 7.2.0.Alpha1
>
>
> I appears that remote-destination-outbound-socket-binding resources cannot have attributes that are expressions - at least the host attrtibute. In JBossAS 4.2.3, we used to have a stock email service.xml that people could customize by simply passing in new system properties (rather than editing .xml or going through a CLI to change the values). However, in AS 7.1.1.Final, we can't do this for the mail service because at least the host attribute does not appear to allow for expressions:
> /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=mail-smtp
> My host attribute was set to the expression ${rhq.server.email.smtp-host:localhost} and when I tried to start the server, I got:
> Caused by: java.net.UnknownHostException: ${rhq.server.email.smtp-host:localhost}
> at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) [rt.jar:1.6.0_29]
> at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1202) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName0(InetAddress.java:1153) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName(InetAddress.java:1083) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName(InetAddress.java:1019) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getByName(InetAddress.java:969) [rt.jar:1.6.0_29]
> at org.jboss.as.network.OutboundSocketBinding.getDestinationAddress(OutboundSocketBinding.java:146)
> at org.jboss.as.mail.extension.MailSessionService.getServerSocketAddress(MailSessionService.java:106)
> The weird thing is, the port attribute appears to allow for expressions. When my port is set to this expression: "${rhq.server.email.smtp-port:25}", the server starts up fine (that is, after I set to the host to a legitimate hostname like "localhost")
> This JIRA is to request that expressions be supported for the host attribute as it appears to be supported for the port attribute.
--
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, 6 months
[JBoss JIRA] (AS7-5321) support expressions for remote-destination-outbound-socket-binding host attrib
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5321?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar edited comment on AS7-5321 at 1/4/13 11:10 AM:
-----------------------------------------------------------
This was implemented as part of conversion of core model to RD but it needs some tests.
was (Author: ctomc):
This was implemented as part of conversion of core model to RD but it needs its some tests.
> support expressions for remote-destination-outbound-socket-binding host attrib
> ------------------------------------------------------------------------------
>
> Key: AS7-5321
> URL: https://issues.jboss.org/browse/AS7-5321
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Domain Management
> Affects Versions: 7.1.1.Final
> Reporter: John Mazzitelli
> Assignee: Tomaz Cerar
> Labels: rhq
> Fix For: 7.2.0.Alpha1
>
>
> I appears that remote-destination-outbound-socket-binding resources cannot have attributes that are expressions - at least the host attrtibute. In JBossAS 4.2.3, we used to have a stock email service.xml that people could customize by simply passing in new system properties (rather than editing .xml or going through a CLI to change the values). However, in AS 7.1.1.Final, we can't do this for the mail service because at least the host attribute does not appear to allow for expressions:
> /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=mail-smtp
> My host attribute was set to the expression ${rhq.server.email.smtp-host:localhost} and when I tried to start the server, I got:
> Caused by: java.net.UnknownHostException: ${rhq.server.email.smtp-host:localhost}
> at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) [rt.jar:1.6.0_29]
> at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1202) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName0(InetAddress.java:1153) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName(InetAddress.java:1083) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getAllByName(InetAddress.java:1019) [rt.jar:1.6.0_29]
> at java.net.InetAddress.getByName(InetAddress.java:969) [rt.jar:1.6.0_29]
> at org.jboss.as.network.OutboundSocketBinding.getDestinationAddress(OutboundSocketBinding.java:146)
> at org.jboss.as.mail.extension.MailSessionService.getServerSocketAddress(MailSessionService.java:106)
> The weird thing is, the port attribute appears to allow for expressions. When my port is set to this expression: "${rhq.server.email.smtp-port:25}", the server starts up fine (that is, after I set to the host to a legitimate hostname like "localhost")
> This JIRA is to request that expressions be supported for the host attribute as it appears to be supported for the port attribute.
--
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, 6 months
[JBoss JIRA] (AS7-6276) It's not possible to add more global valves through jboss-cli
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created AS7-6276:
-------------------------------------
Summary: It's not possible to add more global valves through jboss-cli
Key: AS7-6276
URL: https://issues.jboss.org/browse/AS7-6276
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.2.0.Alpha1
Reporter: Ondřej Chaloupka
Assignee: Jean-Frederic Clere
I wanted to add 2 global valves to web subsystem but it's not possible because the commands produces invalid xml file.
When you run:
/subsystem=web/valve=myvalve:add(class-name=org.apache.catalina.valves.RemoteAddrValve,module=org.jboss.as.web,enabled=true)
/subsystem=web/valve=myvalve2:add(class-name=org.apache.catalina.valves.RemoteAddrValve,module=org.jboss.as.web,enabled=true)
/:reload
The reload fails and the xml output saved in standalone.xml file is following:
{code}
<valve name="myvalve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true">
<valve name="myvalve2" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true"/>
</valve>
{code}
When I define 2 valves manually to XML file like:
{code}
<valve name="myvalve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true" />
<valve name="myvalve2" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve" enabled="true" />
{code}
then everything works fine.
--
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, 6 months
[JBoss JIRA] (AS7-6272) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6272?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-6272:
--------------------------------------
Reassigning to to Tom because it seems not AS7 integration related.
Tom, feel free to ping me if you need to discuss something about integration.
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: AS7-6272
> URL: https://issues.jboss.org/browse/AS7-6272
> Project: Application Server 7
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.1.3.Final (EAP)
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
> Assignee: Stefano Maestri
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store.
--
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, 6 months
[JBoss JIRA] (AS7-6272) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6272?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri updated AS7-6272:
---------------------------------
Assignee: Tom Jenkinson (was: Stefano Maestri)
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: AS7-6272
> URL: https://issues.jboss.org/browse/AS7-6272
> Project: Application Server 7
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.1.3.Final (EAP)
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
> Assignee: Tom Jenkinson
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store.
--
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, 6 months
[JBoss JIRA] (REMJMX-57) Memory leak due to connection IDs being retained within JMXConnectorServer
by Darran Lofthouse (JIRA)
Darran Lofthouse created REMJMX-57:
--------------------------------------
Summary: Memory leak due to connection IDs being retained within JMXConnectorServer
Key: REMJMX-57
URL: https://issues.jboss.org/browse/REMJMX-57
Project: Remoting JMX
Issue Type: Bug
Components: Connection
Affects Versions: 1.1.0.Beta2, 1.0.5.Final
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.CR1
As connections are opened the identifier for the connection is registered with JMXConnectorServer - however on termination of the connection this registration is not cleared leading to a build up and leak.
--
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, 6 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:
-----------------------------------
OK. Now I understand what you were trying to do and I see your point. I'll look into it some more.
> 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
>
>
> 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, 6 months