[JBoss JIRA] (WFCORE-1143) Cancel button in JConsole do nothing
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1143?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1143:
------------------------------------------
Which cancel button is being talked about here? Could you please attach a screen shot.
>From the description I can't work out do you mean a cancel button which is a part of jconsole - i.e. not in our control - or is there a separate cancel button you can not get rid of when you switch to the CLI tab?
> Cancel button in JConsole do nothing
> ------------------------------------
>
> Key: WFCORE-1143
> URL: https://issues.jboss.org/browse/WFCORE-1143
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
>
> *Description of problem:*
> Cancel button in JConsole do nothing. It should be removed from JConsole
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # ./bin/standalone.sh &
> # ./bin/jconsole.sh
> # Click to CLI tab
> # Click to "Cancel" button
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5715) Wildfly 9/10 removing deployments after a certain time
by Sven Ulrich (JIRA)
[ https://issues.jboss.org/browse/WFLY-5715?page=com.atlassian.jira.plugin.... ]
Sven Ulrich updated WFLY-5715:
------------------------------
Attachment: ifxjdbc_4.10.jar
> Wildfly 9/10 removing deployments after a certain time
> ------------------------------------------------------
>
> Key: WFLY-5715
> URL: https://issues.jboss.org/browse/WFLY-5715
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final, 10.0.0.CR4
> Environment: Ubuntu 12.04.5 LTS
> Reporter: Sven Ulrich
> Assignee: ehsavoie Hugonnet
> Attachments: ifxjdbc_4.10.jar, server.log, standalone.xml
>
>
> I have setup a Wildfly 10 CR4 on a Ubuntu 12.04.5 LTS. The server is running fine.
> Now I want to deploye my jar files (jdbc driver and jee apps).
> All is uploaded via the management web interface running on the port 10010 (added offset of 20 because a WF8 is running on Port 8080)
> First I log into the web interface and navigate to the tab deployments. Then I use the button add.
> In the popup window:
> 1: Upload a new deployment
> 2: I choose ifxjdbc_4.10.jar for e.g.
> 3: In Verify upload enabled is set and everything else is standard
> 4: The upload takes round about 30sec.
> Now I can setup datasources for this driver and its works fine. My next step is to stop the server and restart it. Then the server wont start because the content is missing for the jar.
> It wont be an issue for me if i could be 100% sure that the server wont be restarted anytime :)
> I have added my standalone.xml and the log with hopefully all needed information.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5722) Can't configure empty base-dn for ldap realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5722?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-5722:
--------------------------------------
Assignee: Darran Lofthouse (was: Stefan Guilhen)
> Can't configure empty base-dn for ldap realm
> --------------------------------------------
>
> Key: WFLY-5722
> URL: https://issues.jboss.org/browse/WFLY-5722
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Affects Versions: 2.0.2.Final
> Reporter: Alberto Persello
> Assignee: Darran Lofthouse
> Labels: authentication, authorization, group, ldap, realm
>
> It is not possible to set the empty value for base-dn attribute in authentication-->ldap element and in authorization-->ldap-->group-search-->group-to-principal element.
> The empty value is the only valid option for java ldap searches to scan the entire ldap (the equivalent of RootDSE).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1153) Can't configure empty base-dn for ldap realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1153?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-5722 to WFCORE-1153:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1153 (was: WFLY-5722)
Component/s: Domain Management
Security
(was: Security Manager)
Affects Version/s: 2.0.2.Final
(was: 9.0.1.Final)
> Can't configure empty base-dn for ldap realm
> --------------------------------------------
>
> Key: WFCORE-1153
> URL: https://issues.jboss.org/browse/WFCORE-1153
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.2.Final
> Reporter: Alberto Persello
> Assignee: Darran Lofthouse
> Labels: authentication, authorization, group, ldap, realm
>
> It is not possible to set the empty value for base-dn attribute in authentication-->ldap element and in authorization-->ldap-->group-search-->group-to-principal element.
> The empty value is the only valid option for java ldap searches to scan the entire ldap (the equivalent of RootDSE).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1143) Cancel button in JConsole do nothing
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1143?page=com.atlassian.jira.plugi... ]
Marek Kopecký commented on WFCORE-1143:
---------------------------------------
I used WildFly Project (not WildFly Core Project), because jconsole.sh script is not in "wildfly-core". But "WildFly Core Project" may be better, because CLI is part of WildFly Core.
[~ctomc]: In that case, "cancel button" could stay in jconsole ...
> Cancel button in JConsole do nothing
> ------------------------------------
>
> Key: WFCORE-1143
> URL: https://issues.jboss.org/browse/WFCORE-1143
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
>
> *Description of problem:*
> Cancel button in JConsole do nothing. It should be removed from JConsole
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # ./bin/standalone.sh &
> # ./bin/jconsole.sh
> # Click to CLI tab
> # Click to "Cancel" button
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5722) Can't configure empty base-dn for ldap realm
by Alberto Persello (JIRA)
Alberto Persello created WFLY-5722:
--------------------------------------
Summary: Can't configure empty base-dn for ldap realm
Key: WFLY-5722
URL: https://issues.jboss.org/browse/WFLY-5722
Project: WildFly
Issue Type: Bug
Components: Security Manager
Affects Versions: 9.0.1.Final
Reporter: Alberto Persello
Assignee: Stefan Guilhen
It is not possible to set the empty value for base-dn attribute in authentication-->ldap element and in authorization-->ldap-->group-search-->group-to-principal element.
The empty value is the only valid option for java ldap searches to scan the entire ldap (the equivalent of RootDSE).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5721) Some of attributes in datasource subsystem do not allow usage of expressions
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5721?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-5721:
-----------------------------------
Affects Version/s: 10.0.0.CR4
> Some of attributes in datasource subsystem do not allow usage of expressions
> ----------------------------------------------------------------------------
>
> Key: WFLY-5721
> URL: https://issues.jboss.org/browse/WFLY-5721
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.CR4
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Priority: Minor
>
> Some of the properties in datasource subsystem are disabled to be set by expression. It would be good if all attributes could be set by expression if possible.
> Namely these are those which sets "expressions-allowed" as false
> * driver
> ** driver-class-name
> ** driver-module-name
> ** driver-xa-datasource-class-name
> ** module-slot
> ** jdbc-compliant
> ** profile
> * data-source
> ** allow-multiple-users
> This issue came alongside with testing EAP7-467 which asks for allowing expressions in datasource subsystem, especially for attribute 'enabled'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5721) Some of attributes in datasource subsystem do not allow usage of expressions
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created WFLY-5721:
--------------------------------------
Summary: Some of attributes in datasource subsystem do not allow usage of expressions
Key: WFLY-5721
URL: https://issues.jboss.org/browse/WFLY-5721
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Ondřej Chaloupka
Assignee: Jesper Pedersen
Priority: Minor
Some of the properties in datasource subsystem are disabled to be set by expression. It would be good if all attributes could be set by expression if possible.
Namely these are those which sets "expressions-allowed" as false
* driver
** driver-class-name
** driver-module-name
** driver-xa-datasource-class-name
** module-slot
** jdbc-compliant
** profile
* data-source
** allow-multiple-users
This issue came alongside with testing EAP7-467 which asks for allowing expressions in datasource subsystem, especially for attribute 'enabled'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls
by Ste Gr (JIRA)
[ https://issues.jboss.org/browse/WFLY-5716?page=com.atlassian.jira.plugin.... ]
Ste Gr edited comment on WFLY-5716 at 11/23/15 4:46 AM:
--------------------------------------------------------
I've attached sources and pre-build jar files.
Please deploy them and open the URLs and click on the displayed button.
* http://server:8080/wfly5716-fw/index.jsf
* http://server:8080/wfly5716-app/index.jsf
You will see some outputs in the log. I've attached the output that I'm getting. As you can see the lines for "INIT" and "DESTROY" are at different locations. For _wfly5716-fw_ it seems to be correct as both "DUMMY" calls are made while the request scoped bean is valid. For _wfly5716-app_ this is not the case. The second "DUMMY" call is made after the bean has bean invalidated and no new one is created for the second call.
*wfly5716-fw*
{code}
10:42:41,590 INFO [stdout] (default task-9) [fw] IFrameworkResourceManager = Proxy for remote EJB StatelessEJBLocator for "/wfly5716-fw/WebFrameworkImpl", view is interface testing.wfly5716.share.IWebFramework, affinity is None
10:42:41,592 INFO [stdout] (default task-9) [fw] invoke WebFrameworkImpl#resolveUser
10:42:41,592 INFO [stdout] (default task-9) [fw] testing.wfly5716.fw.RequestBean@483c00d3 INIT
10:42:41,592 INFO [stdout] (default task-9) [fw] testing.wfly5716.fw.RequestBean@483c00d3 DUMMY
10:42:41,593 INFO [stdout] (default task-9) [fw] invoke WebFrameworkImpl#resolveRights
10:42:41,593 INFO [stdout] (default task-9) [fw] testing.wfly5716.fw.RequestBean@483c00d3 DUMMY
10:42:41,597 INFO [stdout] (default task-9) [fw] testing.wfly5716.fw.RequestBean@483c00d3 DESTROY
{code}
*wfly5716-app*
{code}
10:44:07,966 INFO [stdout] (default task-13) [app] IFrameworkResourceManager = Proxy for remote EJB StatelessEJBLocator for "/wfly5716-fw/WebFrameworkImpl", view is interface testing.wfly5716.share.IWebFramework, affinity is None
10:44:07,967 INFO [stdout] (default task-13) [fw] invoke WebFrameworkImpl#resolveUser
10:44:07,968 INFO [stdout] (default task-13) [fw] testing.wfly5716.fw.RequestBean@49356a INIT
10:44:07,968 INFO [stdout] (default task-13) [fw] testing.wfly5716.fw.RequestBean@49356a DUMMY
10:44:07,968 INFO [stdout] (default task-13) [fw] testing.wfly5716.fw.RequestBean@49356a DESTROY
10:44:07,969 INFO [stdout] (default task-13) [fw] invoke WebFrameworkImpl#resolveRights
10:44:07,969 INFO [stdout] (default task-13) [fw] testing.wfly5716.fw.RequestBean@49356a DUMMY
{code}
was (Author: grubi):
sources and pre-build jar/war files.
> Wrong handling of request context for remote EJB calls
> ------------------------------------------------------
>
> Key: WFLY-5716
> URL: https://issues.jboss.org/browse/WFLY-5716
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 9.0.0.Final, 10.0.0.CR4
> Reporter: Ste Gr
> Assignee: Stuart Douglas
> Attachments: wfly5716.zip
>
>
> Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
> A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
> If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
> I don't know the spec but:
> - either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
> - or each invokation must get its own request context (entity manager must be produced and disposed again).
> I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
> (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls
by Ste Gr (JIRA)
[ https://issues.jboss.org/browse/WFLY-5716?page=com.atlassian.jira.plugin.... ]
Ste Gr updated WFLY-5716:
-------------------------
Attachment: wfly5716.zip
sources and pre-build jar/war files.
> Wrong handling of request context for remote EJB calls
> ------------------------------------------------------
>
> Key: WFLY-5716
> URL: https://issues.jboss.org/browse/WFLY-5716
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 9.0.0.Final, 10.0.0.CR4
> Reporter: Ste Gr
> Assignee: Stuart Douglas
> Attachments: wfly5716.zip
>
>
> Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
> A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
> If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
> I don't know the spec but:
> - either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
> - or each invokation must get its own request context (entity manager must be produced and disposed again).
> I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
> (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months