[JBoss JIRA] (WFCORE-2197) ability to upload content from secure web server
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2197?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2197:
------------------------------------------
Hadn't seen this before but +1 to using the Elytron authentication context, the authentication context can match based on the URL to identify the security policy to use.
> ability to upload content from secure web server
> ------------------------------------------------
>
> Key: WFCORE-2197
> URL: https://issues.jboss.org/browse/WFCORE-2197
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Ian Kent
>
> We use the upload-deployment-url operation of wildfly management API to add content to content repository (app war) from remote web server (nexus artifact repository manager). As the nexus web server is secure so the wildfly app server needs to pass credentials to nexus when downloading war to wildfly content repository for deployment. Is there a way to encode the nexus username and password in url parameter or add a additional parameters for username and password.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3317) Some deployment-scanner unit tests from wf-core fail on IBM JDK intermittently
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3317?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-3317:
----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2845, https://github.com/jbossas/wildfly-core-eap/pull/433, https://github.com/wildfly/wildfly-core/pull/2846 (was: https://github.com/wildfly/wildfly-core/pull/2845, https://github.com/jbossas/wildfly-core-eap/pull/433)
> Some deployment-scanner unit tests from wf-core fail on IBM JDK intermittently
> ------------------------------------------------------------------------------
>
> Key: WFCORE-3317
> URL: https://issues.jboss.org/browse/WFCORE-3317
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Test Suite
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> *Description of problem:*
> Some deployment-scanner unit tests from wf-core fail on IBM JDK intermittently.
> This is testsuite issue only.
> Affected test cases:
> * ShutdownFileSystemDeploymentServiceUnitTestCase
> * FileSystemDeploymentServiceUnitTestCase
> Executors.newSingleThreadExecutor() method returns ExecutorService with finalize method, that shutdown thread executor. Currently ExecutorService instance is not referenced, so IBM JDK calls finalize method. Finalize method calls shutdown method and size of thread-pool is decreased to 0 before lockDone.get(...) is called.
> *How reproducible:*
> 0.6% - intermittently on IBM JDK
> *Actual results - ShutdownFileSystemDeploymentServiceUnitTestCase:*
> StackTrace:
> {noformat}
> java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@67503391 rejected from java.util.concurrent.ThreadPoolExecutor@ae603d77[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2058)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:834)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1380)
> at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
> at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:692)
> at org.jboss.as.server.deployment.scanner.ShutdownFileSystemDeploymentServiceUnitTestCase.testUncleanShutdown(ShutdownFileSystemDeploymentServiceUnitTestCase.java:156)
> {noformat}
> *Actual results - FileSystemDeploymentServiceUnitTestCase:*
> StackTrace:
> {noformat}
> java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@9408464a rejected from java.util.concurrent.ThreadPoolExecutor@fa7bfba[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2058)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:834)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1380)
> at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
> at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:692)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testUncleanShutdown(FileSystemDeploymentServiceUnitTestCase.java:1755)
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Many thanks, the web console should be straight forward.
The Jboss CLI should be inferable.
I will take a look into the suggested alternatives and see what suits best.
Kindest regards.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (LOGMGR-176) Delay expression resolution in the configuration API
by James Perkins (JIRA)
James Perkins created LOGMGR-176:
------------------------------------
Summary: Delay expression resolution in the configuration API
Key: LOGMGR-176
URL: https://issues.jboss.org/browse/LOGMGR-176
Project: JBoss Log Manager
Issue Type: Enhancement
Affects Versions: 2.0.7.Final
Reporter: James Perkins
Priority: Optional
In some cases it may be desired to delay the expansion of expressions when setting the value through the configuration API. Currently the expressions is resolved when the property is set on the target object. This can be too soon for things like formatters which should probably be more dynamic and resolve the expression during the format.
This might not make sense in all cases and will cause in decrease in performance. A good example of there this could be useful is a {{StructuredFormatter}} where the meta-data value contains an expression.
This is not a requirement, but may be a nice to have. The other option would be to reconfigure the object if a property was changed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9391) Validation errors with "jboss-web_11_0.xsd
by Wolfgang Knauf (JIRA)
Wolfgang Knauf created WFLY-9391:
------------------------------------
Summary: Validation errors with "jboss-web_11_0.xsd
Key: WFLY-9391
URL: https://issues.jboss.org/browse/WFLY-9391
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.CR1
Reporter: Wolfgang Knauf
Assignee: Jason Greene
Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
<xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
It would probably also make sense to include the full schemaLocation URL ;-).
After fixing the namespace, there are four more errors left:
*src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a(n) group component
src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a(n) 'simpleType definition' component
src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
src-resolve: Cannot resolve the name 'jboss:security-roleType' to a(n) 'type definition' component*
The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9391) Validation errors with "jboss-web_11_0.xsd
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf updated WFLY-9391:
---------------------------------
Description:
Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
<xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
It would probably also make sense to include the full schemaLocation URL ;-).
After fixing the namespace, there are four more errors left:
*src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
was:
Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
<xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
It would probably also make sense to include the full schemaLocation URL ;-).
After fixing the namespace, there are four more errors left:
*src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a(n) group component
src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a(n) 'simpleType definition' component
src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
src-resolve: Cannot resolve the name 'jboss:security-roleType' to a(n) 'type definition' component*
The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
> Key: WFLY-9391
> URL: https://issues.jboss.org/browse/WFLY-9391
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.CR1
> Reporter: Wolfgang Knauf
> Assignee: Jason Greene
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months