[JBoss JIRA] (WFLY-9562) Issue creating replicated cache in standalone-ha
by Steven Hawkins (JIRA)
Steven Hawkins created WFLY-9562:
------------------------------------
Summary: Issue creating replicated cache in standalone-ha
Key: WFLY-9562
URL: https://issues.jboss.org/browse/WFLY-9562
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 11.0.0.Final
Reporter: Steven Hawkins
Assignee: Paul Ferraro
Attempting to install teiid into standalone-ha via a cli scripts fails with:
{code}
09:12:37,399 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache-configuration.teiid-cache.resultset-repl: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-configuration.teiid-cache.resultset-repl: Failed to start service
...
Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000343: Must have a transport set in the global configuration in order to define a clustered cache
at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:229)
at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:240)
at org.infinispan.configuration.ConfigurationManager.putConfiguration(ConfigurationManager.java:80)
at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:390)
at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:353)
at org.jboss.as.clustering.infinispan.DefaultCacheContainer.defineConfiguration(DefaultCacheContainer.java:73)
at org.wildfly.clustering.infinispan.spi.service.ConfigurationBuilder.start(ConfigurationBuilder.java:88)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
... 3 more
{code}
This worked with prior WildFly releases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9561) WildFly - Elytron - Programmatic login
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-9561:
-----------------------------------
Component/s: (was: REST)
> WildFly - Elytron - Programmatic login
> --------------------------------------
>
> Key: WFLY-9561
> URL: https://issues.jboss.org/browse/WFLY-9561
> Project: WildFly
> Issue Type: Feature Request
> Components: Security, Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Stanislav Grushevskiy
> Assignee: Darran Lofthouse
> Attachments: test.zip
>
>
> If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
> @Path("login")
> public class LoginService {
> @Context
> private HttpServletRequest request;
> @POST
> public void login(LoginForm form) throws ServletException {
> request.login(form.getLogin(), form.getPassword());
> }
> }
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>application-security-domain</security-domain>
> </jboss-web>
> If I add manual interaction with Session in login method, "JSESSIONID" is set.
> OR
> If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
> "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
> Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
> Run "mvn wildfly:deploy".
> Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
> In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9561) WildFly - Elytron - Programmatic login
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-9561:
-----------------------------------
Issue Type: Bug (was: Feature Request)
> WildFly - Elytron - Programmatic login
> --------------------------------------
>
> Key: WFLY-9561
> URL: https://issues.jboss.org/browse/WFLY-9561
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Stanislav Grushevskiy
> Assignee: Darran Lofthouse
> Attachments: test.zip
>
>
> If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
> @Path("login")
> public class LoginService {
> @Context
> private HttpServletRequest request;
> @POST
> public void login(LoginForm form) throws ServletException {
> request.login(form.getLogin(), form.getPassword());
> }
> }
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>application-security-domain</security-domain>
> </jboss-web>
> If I add manual interaction with Session in login method, "JSESSIONID" is set.
> OR
> If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
> "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
> Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
> Run "mvn wildfly:deploy".
> Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
> In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9561) WildFly - Elytron - Programmatic login
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-9561:
--------------------------------------
Assignee: Darran Lofthouse (was: Alessio Soldano)
> WildFly - Elytron - Programmatic login
> --------------------------------------
>
> Key: WFLY-9561
> URL: https://issues.jboss.org/browse/WFLY-9561
> Project: WildFly
> Issue Type: Feature Request
> Components: REST, Security, Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Stanislav Grushevskiy
> Assignee: Darran Lofthouse
> Attachments: test.zip
>
>
> If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
> @Path("login")
> public class LoginService {
> @Context
> private HttpServletRequest request;
> @POST
> public void login(LoginForm form) throws ServletException {
> request.login(form.getLogin(), form.getPassword());
> }
> }
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>application-security-domain</security-domain>
> </jboss-web>
> If I add manual interaction with Session in login method, "JSESSIONID" is set.
> OR
> If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
> "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
> Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
> Run "mvn wildfly:deploy".
> Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
> In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9561) WildFly - Elytron - Programmatic login
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-9561:
-----------------------------------
Fix Version/s: (was: 10.x.x TBD)
> WildFly - Elytron - Programmatic login
> --------------------------------------
>
> Key: WFLY-9561
> URL: https://issues.jboss.org/browse/WFLY-9561
> Project: WildFly
> Issue Type: Feature Request
> Components: REST, Security, Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Stanislav Grushevskiy
> Assignee: Darran Lofthouse
> Attachments: test.zip
>
>
> If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
> @Path("login")
> public class LoginService {
> @Context
> private HttpServletRequest request;
> @POST
> public void login(LoginForm form) throws ServletException {
> request.login(form.getLogin(), form.getPassword());
> }
> }
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>application-security-domain</security-domain>
> </jboss-web>
> If I add manual interaction with Session in login method, "JSESSIONID" is set.
> OR
> If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
> "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
> Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
> Run "mvn wildfly:deploy".
> Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
> In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-9325:
-----------------------------------
I've identified few areas where we can improve the IO / CPU cycles in testsuite
- reduce copying server around (biggest offender manual TS) partially done by "smarter" copying of resources, partially blocked by WFCORE-3409
- copy only config files we need for current testsuite
- run XLTS transformations only when absolutely needed and only for files that we need (not catch all as we do now)
- use thin distro instead of "fat" one
- merge testsuites, web could easily be merged into basic.
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominator is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9561) WildFly - Elytron - Programmatic login
by Stanislav Grushevskiy (JIRA)
Stanislav Grushevskiy created WFLY-9561:
-------------------------------------------
Summary: WildFly - Elytron - Programmatic login
Key: WFLY-9561
URL: https://issues.jboss.org/browse/WFLY-9561
Project: WildFly
Issue Type: Feature Request
Components: REST, Security, Web (Undertow)
Affects Versions: 11.0.0.Final
Reporter: Stanislav Grushevskiy
Assignee: Alessio Soldano
Fix For: 10.x.x TBD
Attachments: test.zip
If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
@Path("login")
public class LoginService {
@Context
private HttpServletRequest request;
@POST
public void login(LoginForm form) throws ServletException {
request.login(form.getLogin(), form.getPassword());
}
}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain>application-security-domain</security-domain>
</jboss-web>
If I add manual interaction with Session in login method, "JSESSIONID" is set.
OR
If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
"JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
Run "mvn wildfly:deploy".
Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ELY-1452) Summary: SigTest: incompatibile API
by Martin Choma (JIRA)
Martin Choma created ELY-1452:
---------------------------------
Summary: Summary: SigTest: incompatibile API
Key: ELY-1452
URL: https://issues.jboss.org/browse/ELY-1452
Project: WildFly Elytron
Issue Type: Bug
Components: API / SPI
Affects Versions: 1.2.0.Beta10
Reporter: Martin Choma
Class org.wildfly.security.mechanism.MechanismUtil
"E1.2 - API type removed" : method public final static void org.wildfly.security.mechanism.MechanismUtil.handleCallbacks(java.lang.String,javax.security.auth.callback.CallbackHandler,javax.security.auth.callback.Callback[])
Comparing latest from 1.1.x and 1.2.x
Base version: 1.1.8.CR1-SNAPSHOT
Tested version: 1.2.0.Beta10-SNAPSHOT
Incompatible change was introduced by [1]
[1] https://github.com/wildfly-security/wildfly-elytron/commit/c1a5ce817635d3...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months