[JBoss JIRA] (WFCORE-345) Provide way to display deployed application metadata
by Nicklas Karlsson (JIRA)
[ https://issues.jboss.org/browse/WFCORE-345?page=com.atlassian.jira.plugin... ]
Nicklas Karlsson commented on WFCORE-345:
-----------------------------------------
Good question! ;-) Trying to recall what I meant three years ago. Probably I was thinking that since a WAR can have multiple filters and request listeners in class files or WEB-INF\lib jar files, it could be handy to see the final order of them as they are called when a request arrives at the web context.
> Provide way to display deployed application metadata
> ----------------------------------------------------
>
> Key: WFCORE-345
> URL: https://issues.jboss.org/browse/WFCORE-345
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
>
> It would be handy to have the deployment process print out the complete DeploymentInfo for an application so one could view the final order of filters and request listeners etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved WFLY-6916.
------------------------------
Resolution: Rejected
> Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6916
> URL: https://issues.jboss.org/browse/WFLY-6916
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Wildfly 10 final
> Java 8
> Reporter: Prakash Boda
> Assignee: Farah Juma
>
> Below is the stacktrace.
> 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services
> 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty
> 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:88)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125)
> at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226)
> ... 25 more
> After this error also deployment is successful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-6916:
----------------------------------
Strange, haven't seen this before. I'm going to close this for now since there isn't a reproducer. Feel free to re-open it if you do come up with one.
> Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6916
> URL: https://issues.jboss.org/browse/WFLY-6916
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Wildfly 10 final
> Java 8
> Reporter: Prakash Boda
> Assignee: Farah Juma
>
> Below is the stacktrace.
> 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services
> 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty
> 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:88)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125)
> at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226)
> ... 25 more
> After this error also deployment is successful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-314) Configure child resources as mandatory or its cardinality in ResourceDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-314?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-314:
-----------------------------------------
You can now easily configure the expected cardinality of a resource type via SimpleResourceDefinition.Parameters. Default is min 0, max 1 for singleton resource types (i.e. those with a full specified final PathElement) and min 0 max * for wildcard types.
But at this point the kernel doesn't provide any validation that the model conforms to these specifications. Since the 'configure' part is now done, I'm going to change the title of this to be about validation.
> Configure child resources as mandatory or its cardinality in ResourceDefinition
> -------------------------------------------------------------------------------
>
> Key: WFCORE-314
> URL: https://issues.jboss.org/browse/WFCORE-314
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Pedro Igor
>
> Currently, the ResourceDefinition does not provide a good way to configure a child resource as mandatory or even its cardinality. Instead of that, manual validations are required inside handlers.
> The idea is remove manual validations and let it be done automatically by the model.
> Considering the following example:
> {code:xml}
> <parent-resource>
> <child-resource/>
> </parent-resource>
> {code}
> Would be useful if we could mark the 'child-resource' above as mandatory. Or even:
> {code:xml}
> <parent-resource>
> <child-resource/>
> <child-resource/>
> <child-resource/>
> <child-resource/> <!-- This is invalid. Only 3 childs are supported. -->
> </parent-resource>
> {code}
> Where we can specify the cardinality for a child-resource so we can configure the min/max occurrences.
> I think the latter approach is more flexible and can be used to get a resource as mandatory or specify its number of occurrence.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-314) Kernel validation of cardinality of resources as specified in their ResourceDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-314?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-314:
------------------------------------
Summary: Kernel validation of cardinality of resources as specified in their ResourceDefinition (was: Configure child resources as mandatory or its cardinality in ResourceDefinition)
> Kernel validation of cardinality of resources as specified in their ResourceDefinition
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-314
> URL: https://issues.jboss.org/browse/WFCORE-314
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Pedro Igor
>
> Currently, the ResourceDefinition does not provide a good way to configure a child resource as mandatory or even its cardinality. Instead of that, manual validations are required inside handlers.
> The idea is remove manual validations and let it be done automatically by the model.
> Considering the following example:
> {code:xml}
> <parent-resource>
> <child-resource/>
> </parent-resource>
> {code}
> Would be useful if we could mark the 'child-resource' above as mandatory. Or even:
> {code:xml}
> <parent-resource>
> <child-resource/>
> <child-resource/>
> <child-resource/>
> <child-resource/> <!-- This is invalid. Only 3 childs are supported. -->
> </parent-resource>
> {code}
> Where we can specify the cardinality for a child-resource so we can configure the min/max occurrences.
> I think the latter approach is more flexible and can be used to get a resource as mandatory or specify its number of occurrence.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1581) AttributeDefinition.convertToExpectedType can convert LIST of PROPERTY to OBJECT
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1581?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1581:
-------------------------------------
Description:
It's valid for callers to pass a param of ModelType.LIST with elements of type PROPERTY for use in attributes of type OBJECT. AttributeDefinition.convertToExpectedType can deal with this, thus avoiding storing an attribute value with a "usable" but not "per specification" type.
JBEAP-4767 shows an example case where this kind of value is passed as a param.
was:
It's valid for callers to pass a param of ModelType.LIST with elements of type PROPERTY for use in attributes of type OBJECT. AttributeDefinition.convertToExpectedType can deal with this, thus avoiding storing an attribute value with a "usable" but not "per specification" type.
JBEAP-4767 shows an example case where this can of value is passed as a param.
> AttributeDefinition.convertToExpectedType can convert LIST of PROPERTY to OBJECT
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1581
> URL: https://issues.jboss.org/browse/WFCORE-1581
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> It's valid for callers to pass a param of ModelType.LIST with elements of type PROPERTY for use in attributes of type OBJECT. AttributeDefinition.convertToExpectedType can deal with this, thus avoiding storing an attribute value with a "usable" but not "per specification" type.
> JBEAP-4767 shows an example case where this kind of value is passed as a param.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6951) JacORBSubsystemParser should create an OBJECT param for an OBJECT attribute
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-6951:
--------------------------------------
Summary: JacORBSubsystemParser should create an OBJECT param for an OBJECT attribute
Key: WFLY-6951
URL: https://issues.jboss.org/browse/WFLY-6951
Project: WildFly
Issue Type: Bug
Components: IIOP
Affects Versions: 10.1.0.CR1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 11.0.0.Alpha1
The parser when parsing "properties" elements is producing a DMR param of ModelType.LIST of ModelType.PROPERTY instead of a param of ModelType.OBJECT, which is how the attribute is specified. This works ok although it results in storing the attribute value in non-canonical format. But this behavior blocks completion of WFCORE-1581 because it results in test failures once WFCORE-1581 is implemented. Tests that compare the model structure generated by a current version controller when it executes the parser's ops fail as that structure doesn't match what a legacy version controller produces. The mismatch is largely harmless, but it's much simpler to correct the parser than to code a workaround into the tests. Plus the parser is just wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months