[JBoss JIRA] (WFLY-2266) Deployment Overlay feature is not able to replace the application libraries.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2266.
----------------------------------
Fix Version/s: 8.0.0.CR1
Resolution: Done
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
> Key: WFLY-2266
> URL: https://issues.jboss.org/browse/WFLY-2266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Environment: All Operating Systems
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
> Labels: deployment
> Fix For: 8.0.0.CR1
>
>
> -----------------------
> According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."
> Here it talks about "replacing jar libraries" which is not working as expected and causes the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> *Step-1).* Undeploy if any existing application is deployed and then freshly deploy the application.
> {quote}
> [standalone@localhost:9999 /] undeploy DeploymentOverlayDemo.war
> [standalone@localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> *Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature. In the attached ant based Demo just do _"ant compile"_ to create a new Jar _"${project.dir}/tmp/Hello.jar"_
> *Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone@localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>
> Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2329) File upload doesn't work
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2329?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2329:
--------------------------------------
I will change the way this merging is done so that this can work without the multiart-config element.
> File upload doesn't work
> ------------------------
>
> Key: WFLY-2329
> URL: https://issues.jboss.org/browse/WFLY-2329
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (JBoss Web)
> Affects Versions: 8.0.0.Beta1
> Environment: - Windows 7 64
> - Wildfly Beta 1
> - JSF Mojarra 2.2.3
> - Primefaces 4.0
> - Apache commons-io-2.4 & commons-fileupload-1.3
> Reporter: Domen Cebulj
> Assignee: Stuart Douglas
> Labels: fileUpload, jsf22, primefaces, servlet
> Fix For: 8.0.0.CR1
>
> Attachments: fileUpload.war
>
>
> In the previous version it worked, but in Beta 1 stopped worked file uploading with PF4 and Mojarra 2.2.3 (neither simple upload didn't work - tested on blank project, only with PF4 and Apache libs and configured web.xml file)
> I get no error in IDE or JS console.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
My favorite option would be having file-per-layer in the root dir but the product.conf & layers.conf could do the job too, as Brian mentioned.
Talked to Rob about the requirements from JBDS side, which are:
1) Some way to discover the base, and the base's version / name information
2) Some way to discover the layers, and the name/version information for each layer (the layers as a secondary issue)
3) the entire distribution name / version, like product = JPP 6.1 (based on eap 6.2 with layers x,y,z)
Requested input about product.conf & layers.conf.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka edited comment on WFLY-2426 at 12/10/13 12:34 AM:
---------------------------------------------------------------
David, that was my original impl and that's what is in the pull request. But different people's view on simplicity differs and for some, one file with combined values is simpler. I guess it depends whether you ask the producer or consumer of the file.
Also, since this RFE comes from certain parties, I'm paying special attention to their requirements. Hence the reopen...
was (Author: ozizka):
David, that was my original impl and that's what is in the pull request. But different people's view on simplicity differs and for some, one file with combined values is simpler. I guess it depends whether you ask the producer or consumer of the file.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
David, that was my original impl and that's what is in the pull request. But different people's view on simplicity differs and for some, one file with combined values is simpler. I guess it depends whether you ask the producer or consumer of the file.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-671) Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-671?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-671.
-----------------------------------
Fix Version/s: 8.0.0.CR1
(was: Awaiting Volunteers)
Resolution: Done
> Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
> ----------------------------------------------------------------
>
> Key: WFLY-671
> URL: https://issues.jboss.org/browse/WFLY-671
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Carlo de Wolf
> Assignee: Andre Dietisheim
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> I'm unable to compile AS 7.
> {noformat}
> Failed tests: testEveryMinuteEveryHourEveryDay[379](org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase): Unexpected timeout value: java.util.GregorianCalendar[time=1314918060000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asia/Gaza",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=144,lastRule=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=60000,startTimeMode=0,endMode=3,endMonth=8,endDay=1,endDayOfWeek=6,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2011,MONTH=8,WEEK_OF_YEAR=36,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=245,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=1,SECOND=0,MILLISECOND=0,ZONE_OFFSET=7200000,DST_OFFSET=0] expected:<60000> but was:<3660000>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months