[JBoss JIRA] (LOGMGR-128) Create the ability to close or destroy a LogContext
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-128?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-128:
--------------------------------------
Instead of a close we might just want {{reset()}} or {{clear()}}. Nothing will really be closed, especially on the system log context.
> Create the ability to close or destroy a LogContext
> ---------------------------------------------------
>
> Key: LOGMGR-128
> URL: https://issues.jboss.org/browse/LOGMGR-128
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: James Perkins
> Assignee: James Perkins
>
> The {{org.jboss.logmanager.LogContext}} should have the ability to be closed or better put destroyed. Each logger, formatter, error-handler and handler would be removed and closed if required.
> This is useful for things like the WildFly embedded CLI server when the embedded log context needs to be destroyed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9263) Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9263:
-------------------------------------------
Summary: Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
Key: WFLY-9263
URL: https://issues.jboss.org/browse/WFLY-9263
Project: WildFly
Issue Type: Bug
Components: Scripts
Affects Versions: 10.1.0.Final
Reporter: Nuno Godinho de Matos
Assignee: Tomaz Cerar
Priority: Optional
Hi,
I believe that eclipse development with wildfly is quite cumbersome at the moment of defining a new wildfly domain runtime, in particular in regard to the resutilng "open launch configurations".
When we consider what happens with weblogic domains, they normally all have a dedicated bin/ folder.
I do the same thing when a create a fresh new wildfly domain, i enrich it with an additional bin/ folder where I pump in scripts to start/stop etc.. the domain.
Where in particular, the start script is created with properties like java options that matter to our deployments.
Weblogic start plugin uses the startWeblogic.cmd in the bin folder.
Naturally, this does not happen on Wildfly because the concept for the bin scripts is different. They are generic and domain independent.
But It would in any case be very nice, if it were possible to have some sort of convention that when the eclipse plugin looks at a stand alone domain, it could at least hunt for some sort of configuration file, such as an .eclipse_launch_parameters config, to override the default settings.
If such a mechanism would exist, i could enhance my create domain logic to pump into such a configuration file the same setting that is use in my start wildfly scripts.bat.sh.
As it stands, every time I create a new runtime I need to open the configuration page.
Go to the launch configurations, remove the heap settings.
And then go to my startup domain scripts, search for the java opts that I care about, and copy them over.
This is quite time wasteful.
It would be extremely helpful to be able to dodge point and click configuration, once I tell wildfly where the folder for my stand alone domain is located.
Many thanks for taking into consideration this enhancement request for widlfly eclipse plugin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-7309) Make the authentication configurable in the testsuite
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7309?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7309:
-----------------------------------------------
Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1384542|https://bugzilla.redhat.com/show_bug.cgi?id=1384542] from ON_QA to VERIFIED
> Make the authentication configurable in the testsuite
> ------------------------------------------------------
>
> Key: WFLY-7309
> URL: https://issues.jboss.org/browse/WFLY-7309
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Optional
> Fix For: 11.0.0.Alpha1
>
>
> Actually some tests cases fails when running against a remote eap instance.
> In this specific case instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.
> Example:
> org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:
> {code:java}
> private MBeanServerConnection getMBeanServerConnection() throws IOException {
> final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
> connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
> return connector.getMBeanServerConnection();
> }
> {code}
> To:
> {code:java}
> private MBeanServerConnection getMBeanServerConnection() throws IOException {
> HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
> String[] credentials = { System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
> propEnv.put(JMXConnector.CREDENTIALS, credentials);
> final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
> connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
> return connector.getMBeanServerConnection();
> }
> {code}
> Could these kind of authentication being configurable?
> It is important to us because this allows the tests to be executed against the docker images running in openshift.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months