[JBoss JIRA] (DROOLS-4818) Please Update the Spring-boot dependency
by Petar Tahchiev (Jira)
Petar Tahchiev created DROOLS-4818:
--------------------------------------
Summary: Please Update the Spring-boot dependency
Key: DROOLS-4818
URL: https://issues.jboss.org/browse/DROOLS-4818
Project: Drools
Issue Type: Component Upgrade
Reporter: Petar Tahchiev
Assignee: Mario Fusco
Hello,
you are using a 1 year old release of spring-boot:
https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-spring...
and I see you've made a release 10 days ago. Why are you not updating your dependencies? I'm using spring-boot 2.2.0 which uses tomcat9 and servlet4 and now I can't use it because you bring the old spring-boot with the old tomcat and the old servlet3 and I get this:
{code}
2019-11-27 21:32:53,944 org.apache.catalina.core.ContainerBase.[Tomcat].[localhost] [http-nio-8111-exec-7] ERROR: Exception Processing ErrorPage[errorCode=0, location=/error]
java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.getHttpServletMapping()Ljavax/servlet/http/HttpServletMapping;
at org.apache.catalina.core.ApplicationHttpRequest.setRequest(ApplicationHttpRequest.java:708)
at org.apache.catalina.core.ApplicationHttpRequest.<init>(ApplicationHttpRequest.java:114)
at org.apache.catalina.core.ApplicationDispatcher.wrapRequest(ApplicationDispatcher.java:917)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:358)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312)
at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:394)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:253)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:175)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:747)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (ELY-1890) Keep file permissions when modifying an existing credential store
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/ELY-1890?page=com.atlassian.jira.plugin.s... ]
Ingo Weiss updated ELY-1890:
----------------------------
Issue Type: Bug (was: Feature Request)
> Keep file permissions when modifying an existing credential store
> -----------------------------------------------------------------
>
> Key: ELY-1890
> URL: https://issues.jboss.org/browse/ELY-1890
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool
> Affects Versions: 1.11.0.CR1
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Major
>
> Using the offline elytron.sh tool, after creating the credential store I changed the mode to 600. Using the elytron.sh tool to add credentials changes the mode back to 644. Is that intentional for it to automatically do that? I would either expect it to not change and update or not change and error out.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3948 at 11/27/19 10:21 AM:
---------------------------------------------------------------------
All of my above discussion is wrong; all that's needed is for AttachmentList to be thread safe.
Why?
All writes occur in Phase STRUCTURE.
The DeploymentUnitPhaseService for the STRUCTURE Phase for the top level deployment installs all the SubDeploymentUnitService instances. It's a general rule that any service has a dep on the service that installed it, so that means any SubDeploymentUnitService will not start until the top level deployment has completed STRUCTURE phase and thus will see all its data.
Within the STRUCTURE phase, the subdeployments don't care about the data from other subdeployments.
SubDeploymentProcessor adds a dep on the STRUCTURE phase for each subdeployment to the top level deployment's PARSE phase. So all the subdeployments will have completed STRUCTURE before the top begins PARSE work. All the writes happen in STRUCTURE so they will be complete. All the reads after STRUCTURE are either by the top level deployment, which waits for the writes, or by subdeployments which are not concerned with any writes by other subdeployments.
was (Author: brian.stansberry):
All of my above discussion is wrong; all that's needed is for AttachmentList to be thread safe.
Why?
The DeploymentUnitPhaseService for the STRUCTURE Phase for the top level deployment installs all the SubDeploymentUnitService instances. It's a general rule that any service has a dep on the service that installed it, so that means any SubDeploymentUnitService will not start until the top level deployment has completed STRUCTURE phase and will see all its data.
Within the STRUCTURE phase, the subdeployments don't care about the data from other subdeployments.
SubDeploymentProcessor adds a dep on the STRUCTURE phase for each subdeployment to the top level deployment's PARSE phase. So all the subdeployments will have completed STRUCTURE before the top begins PARSE work. All the writes happen in STRUCTURE so they will be complete. All the reads after STRUCTURE are either by the top level deployment, which waits for the writes, or by subdeployments which are not concerned with any writes by other subdeployments.
> Potential race condition on deployment of EAR when Class-Path manifest entry is in use
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-3948
> URL: https://issues.jboss.org/browse/WFCORE-3948
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Stuart Douglas
> Assignee: Brian Stansberry
> Priority: Major
>
> Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months