WildFly Releases over the next year
by Brian Stansberry
Hi everyone,
After spending the last year plus in a feature-boxed release scheduling
mode, I think it would be both good and feasible to get the WildFly project
back into the roughly time-boxed delivery model that we managed pretty
successfully starting with WildFly 12. This thread is to gather inputs from
the WildFly developer community about doing that over the next year. After
discussing here, my aim is to post our plans to the broader WildFly
community via a wildfly.org news post and a thread on the wildfly google
group.
One question is what length of time boxes we would shoot for.
Personally I thought the roughly quarterly cadence worked well. It seemed
short enough that we didn't find ourselves regularly stressing about
getting a particular feature into a particular release because it would
otherwise have to wait too long. I could imagine trying to go for a shorter
cycle, but I don't think that's really practical right now. Optimizing our
delivery processes to make that more practical would be a good goal for the
next year though.
If we go back to quarterly releases, the next question is what that
schedule would look like. If we assume WildFly 28 goes out as planned[1],
then a quarterly cadence would look like this:
WildFly 29 Beta - Thur Jun 29
WildFly 29 Final – Thur Jul 13
WildFly 30 Beta – Thur Sep 28
WildFly 30 Final – Thur Oct 12
WildFly 31 Beta – Thur Dec 14 [2]
WildFly 31 Final – Thur Jan 11
WildFly 32 Beta – Thur Mar 28
WildFly 32 Final -- Thur Apr 11
Those dates are the Thursdays when the release is announced on and download
links are added to wildfly.org. We'd want PRs ready intended for the
release to be ready to merge 6 days before that date, i.e. the preceding
Friday.
In the past we tried for a March/June/September/December cadence, but,
besides that fact the April WildFly 28 will become a starting point, my
sense is January/April/July/October will work better. A lot of developers
go on holidays in late July and August, which tended to make September
releases difficult. And then aiming for a mid-December Final release was
often a problem, because any delay would push the release into the late
December period when folks are away, driving the actual release into
January. Even if that didn't happen, the possibility made December releases
stressful.
I don't think a strictly quarterly cadence is necessary; e.g. we could make
the Apr-Jul release cycle a couple weeks shorter to get that release out of
July and into June, if devs would find that better for their summer
schedules.
Note that my idea here isn't to come up with a set-in-stone schedule a year
in advance. It's more to come up with general idea that we can promise to
our community (e.g. 4 releases in a year) and a rough prediction when they
will be.
[1]
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/...
[2] Note that the WildFly 31 Beta date is significantly further ahead of
the Final date than the typical 2 weeks. This is so the Beta is done and
released before so many devs end work for the year.
Best regards,
Brian Stansberry
Project Lead, WildFly
2 weeks, 6 days
Deprecated Modules Cleanup + Standardized Deployments
by Richard Opalka
At the time when first modular Java was released in September 2017 [0]
JBoss Modules team have already been working on proper integration with it
[2].
That effort was finished 7 months later after Java 9 initial release and
JBoss Modules version supporting Java's JPMS modules was integrated into
WildFly in April 2018.
During the JBoss Modules 1.8.0.Final merge into WildFly some legacy and
WildFly specific modules have been deprecated, see [2] and [3]. These are:
* ibm.jdk (aggregation module for IBM JDK8 internals)
* javax.api (aggregation module for some Java's official APIs)
* javax.xml.stream.api (streaming api)
* javax.sql.api (sql api)
* sun.jdk (aggregation module for SUN JDK internals)
We created and defined these modules over time as WildFly was developed
and before
Java got modularized via [5]. But with introduction of modular Java
everything changed
and there is no more reason to use these legacy modules that we came up in
the past.
It is preferred and recomended to use official Java JPMS modules instead.
All five obsolete modules were deprecated in the past but second
important step
of removing references on them wasn't completed yet and so they are still
being used
in both WildFly and WildFly Core. Now before EAP8 goes final is the right
time
to clean it up and complete the migration to standard Java's JPMS modules
and ideally
get rid of these five deprecated modules. Another option is to keep them
(although
unreferenced) in WildFly & EAP8 for backwards compability.
There were identified two areas of above deprecated modules usages:
a) module.xml files in WildFly Core and WildFly
b) server runtime code
To migrate to Java JPMS modules it is important to know which JPMS
module(s) should be
used/referenced instead. Following is the mapping of legacy WildFly modules
to Java JPMS modules:
1) ibm.jdk deprecated module cannot be migrated to standard Java JPMS
module. This module was introduced
because we needed some of IBM JDK8 internals to be available in WildFly
in the past.
When WildFly Core and WildFly code base moved to modular JDKs (JDK11
and above) this legacy module
is not needed anymore. It is because recent IBM JDK 11 and above are
based on OpenJDK and its JPMS modules architecture.
References to that module can be eliminated completely without any
further migration.
2) javax.api deprecated module will be replaced with one or some of the
following JPMS modules it aggregates:
- java.se
- jdk.xml.dom
where java.se is also Java's JPMS aggregation module and it can be
further dereferenced to smaller JPMS modules that are only needed
3) javax.xml.stream.api will be replaced with java.xml JPMS module
4) javax.sql.api deprecated module will be replaced with one or some of
the following JPMS modules it aggregates:
- java.sql
- java.sql.rowset
- java.transaction.xa
5) sun.jdk deprecated module will be replaced with one or some of the
following JPMS modules it emulates:
- modules whose name starts with jdk. prefix (note these are specific
to the JDK and will not necessarily be available in all Java
implementations)
The last remaining bit we would like to clarify and standardize with
this cleanup effort
is server runtime code referencing these legacy WildFly modules. It was
identified that WildFly server propagates:
* javax.api
* ibm.jdk
* sun.jdk
* org.jboss.vfs
modules to all deployments by default.
In order to standardize WildFly and EAP8 deployments we propose the
following changes:
* only java.se JPMS module will be propagated to all deployments by
default - was addressed with [6]
* deprecated ibm.jdk will not be propagated anymore to all deployments by
default - will be addressed with [7]
* deprecated sun.jdk will not be propagated anymore to all deployments by
default - will be addressed with [8]
* org.jboss.vfs will not be propagated to all deployments - was addressed
with [9]
This proposal of course introduces a potential (but fixable) backward
incompatibility issue between EAP7 and EAP8 deployments.
Deployments that were relying on sun.jdk module or org.jboss.vfs module to
be available in their deployments by default will need to be fixed
to reference org.jboss.vfs module or jdk. prefixed JPMS modules explicitly
- for example see [10].
Best regards,
JBoss Modules Team
[0] https://en.wikipedia.org/wiki/Java_version_history - Java release dates
[1] https://issues.redhat.com/browse/MODULES-254 - Support for dependency
on Jigsaw modules from static modules
[2] https://issues.redhat.com/browse/WFCORE-3705 - Allow dependencies on
JDK modules
[3] https://issues.redhat.com/browse/WFCORE-3684 - Upgrade JBoss Modules to
1.8.0.Final
[4] https://issues.redhat.com/browse/WFCORE-6248 - Only Java SE aggregation
module should be visible to all deployments by default
[5] https://openjdk.org/jeps/200 - JEP 200: The Modular JDK
[6] https://issues.redhat.com/browse/WFCORE-6237 - Eliminate usage of
deprecated javax.api module
[7] https://issues.redhat.com/browse/WFCORE-6245 - Eliminate usage of
deprecated ibm.jdk module
[8] https://issues.redhat.com/browse/WFCORE-6249 - Eliminate usage of
deprecated sun.jdk module
[9] https://issues.redhat.com/browse/WFCORE-6250 - Don't include
org.jboss.vfs module to all deployments by default
[10] https://issues.redhat.com/browse/WFLY-17666 - Deployments using RMI
Java Naming provider must define explicit dependency on jdk.naming.rmi JPMS
module
1 month
Re: WFNAM00018 - Failed to connect to remote host
by Brian Stansberry
Hi Subramaniam,
To get an EAP subscription, you can go to
https://www.redhat.com/en/technologies/jboss-middleware/application-platform
and follow the "Buy It" or "Talk to a Red Hatter" links. Or, if you already
have an account with Red Hat for a different product, you can contact your
sales person to get assistance with getting an EAP subscription.
On Wed, Apr 19, 2023 at 5:55 AM Subramanian1 R iGTB <
subramanian1.r(a)intellectdesign.com> wrote:
> Hi Brian
>
> Thanks for your timely response.
>
> Though we have provided all the correct information about the JBoss
> server, we are encountering the Cannot instantiate class:
> org.wildfly.naming.client.WildFlyInitialContextFactory in spite of placing
> the wildfly jar in the lib folder.
>
> Jar Used - wildfly-client-all-20.0.1.Final.jar
> Java Version - Java 11
> GAMFT Version - 7.1.3
> Jboss Version - EAP-7.3.8
>
> Exception in NamingException for standard
> upload---->javax.naming.NoInitialContextException: *Cannot instantiate
> class: org.wildfly.naming.client.WildFlyInitialContextFactory [Root
> exception is java.lang.ClassNotFoundException:
> org.wildfly.naming.client.WildFlyInitialContextFactory]*
>
> Please find the attached log file and the JAVA source file used for the
> full stack trace.
>
> We have below 3 queries. Could you please respond:
>
> 1. Can you please let us know which Wildfly jar is compliant with the JAVA
> 11 version? Already we have tried multiple Wildfly versions like
> 20.0.2.Final, 28.0.0Beta1, 27.0.1.Final, 27.0.0.Final, 26.1.3.Final jars.
> We are facing the same issue mentioned above.
>
Those all support SE 11. A ClassNotFoundException doesn't indicate to me
that there is any problem with the SE version being used.
Looking at your attached log I'm not sure what sort of application is
running. It doesn't look like the Tomcat application from the initial post;
it seems more like a standalone java app. Is the wildfly-client-all.jar on
the classpath?
> 2. Is there any other alternative jar that can be used in place of a
> wildfly jar?
>
You should use the client jar associated with the EAP version you are
trying to integrate with. For EAP 7.3.8 that would be:
https://maven.repository.redhat.com/ga/org/jboss/eap/wildfly-client-all/7...
Also, inside your EAP 7.3 CP 8 server installation's bin/client dir there
is a 'jboss-client.jar'. That's the same jar as the one I linked on the
line above, just with a different name.
> 3. I have attached the InputFiles_Transformation_JMS.java source. Could
> you please go through and let us know if any code changes required
> complaint with JAVA11?
>
> I'm sorry, but that's beyond what I can do.
For WildFly user questions you can post to the WildFly user forum at
https://groups.google.com/g/wildfly and perhaps someone in the user
community can assist.
> And Also we tried to raise a ticket in the below mentioned redhat site but
> it requires some active subscription. Currently we do not have any
> subscription. Could you please guide us to proceed further.
>
>
> *Thanks & Regards,*
> *Subramanian SP RM | Team Lead | iGTBIntellect Design Arena Limited,M:
> +91-9487439570,Plot No. 3/G3, SIPCOT IT Park, Siruseri,Chennai – 600 130,
> India.*
>
>
> On Tue, Apr 18, 2023 at 7:55 PM Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> Hi Subramanian,
>>
>> Since you are using JBoss EAP, please open a ticket via the Red Hat
>> customer support portal at https://access.redhat.com/. The support team
>> and Red Hat is organized to provide more timely responses than you can get
>> from the WildFly community.
>>
>> You've posted a client-side stack trace. The 'WFNAM00018: Failed to
>> connect to remote host' exception message comes from the
>> wildfly-naming-client library, but there is no WildFly/EAP component code
>> in the stack trace. So I expect the code in the stack has caught an
>> exception thrown by wildfly-naming-client and converted it to JMSException,
>> taking the message from the wildfly-naming-client exception. If there's
>> other logging (e.g. a 'Caused by' section of the stack trace) that shows
>> stacks from wildfly-naming-client , please be sure and include that in
>> your ticket with Red Hat.
>>
>> Best regards,
>> Brian Stansberry
>>
>> On Tue, Apr 18, 2023 at 7:03 AM Subramanian1 R iGTB <
>> subramanian1.r(a)intellectdesign.com> wrote:
>>
>>> Hi Team
>>>
>>> This is regarding Integration between GAMFT (Go Anywhere Managed File
>>> transfer) and JBOSS server.(EAP-7.3.8)
>>>
>>> Jar Used - wildfly-client-all-20.0.1.Final.jar
>>> Java Version - Java 11
>>> GAMFT Version - 7.1.3
>>> Jboss Version - EAP-7.3.8
>>>
>>> Also we have raised the same issue in Jboss Community as well waiting
>>> for the moderator to approve. PFB Screenshot FYR.
>>> [image: Jboss.jpg]
>>>
>>> We are encountering the below error while we are trying to send JMS.to
>>> Jboss from GAMFT 7.1.3 application.
>>>
>>> javax.jms.JMSException: WFNAM00018: Failed to connect to remote host
>>> at
>>> com.linoma.resource.mq.JNDIConnectionFactory.getConnection(JNDIConnectionFactory.java:78)
>>> at
>>> com.linoma.ga.projects.resources.MQResource.testJNDIConnection(MQResource.java:411)
>>> at com.linoma.ga.projects.resources.MQResource.test(MQResource.java:282)
>>> at
>>> com.linoma.ga.projects.resources.ResourceTester.executeTest(ResourceTester.java:175)
>>> at
>>> com.linoma.ga.projects.resources.ResourceTester.test(ResourceTester.java:123)
>>> at
>>> com.linoma.ga.ui.admin.resources.ConfigureResourceForm.test(ConfigureResourceForm.java:398)
>>> at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>> at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
>>> Source)
>>> at
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>> at java.base/java.lang.reflect.Method.invoke(Unknown Source)
>>> at org.apache.el.parser.AstValue.invoke(AstValue.java:252)
>>> at
>>> org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:266)
>>> at
>>> org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)
>>> at
>>> org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74)
>>> at
>>> org.primefaces.application.DialogActionListener.processAction(DialogActionListener.java:46)
>>> at javax.faces.component.UICommand.broadcast(UICommand.java:120)
>>> at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1174)
>>> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:365)
>>> at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1660)
>>> at
>>> javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:864)
>>> at
>>> org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:42)
>>> at
>>> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196)
>>> at
>>> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)
>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at com.linoma.ga.ui.admin.LocaleFilter.doFilter(LocaleFilter.java:99)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at com.linoma.ga.ui.admin.WebDocFilter.doFilter(WebDocFilter.java:119)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.ga.core.upload.AdminFileUploadFilter.doFilter(AdminFileUploadFilter.java:81)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.dpa.security.SecurityFilter.doFilter(SecurityFilter.java:316)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.dpa.security.SecurityHeaderFilter.doFilter(SecurityHeaderFilter.java:104)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.ga.ui.core.filter.IFrameEmbeddingFilter.doFilter(IFrameEmbeddingFilter.java:90)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.ga.ui.core.filter.NoCacheFilter.doFilter(NoCacheFilter.java:46)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.ga.ui.core.filter.IECompatibilityModeFilter.doFilter(IECompatibilityModeFilter.java:61)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.dpa.j2ee.AdminRedirectFilter.doFilter(AdminRedirectFilter.java:50)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> com.linoma.ga.ui.core.filter.XForwardedForFilter.doFilter(XForwardedForFilter.java:55)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
>>> at
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
>>> at
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
>>> at
>>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
>>> at
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
>>> at
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
>>> at
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
>>> at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
>>> at
>>> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
>>> at
>>> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
>>> at
>>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
>>> at
>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
>>> at
>>> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>>> at
>>> org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
>>> at
>>> org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
>>> at
>>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>>> at java.base/java.lang.Thread.run(Unknown Source)
>>>
>>> We Seek your support to overcome this issue.
>>>
>>> *Thanks & Regards,*
>>> *Subramanian SP RM | Team Lead | iGTBIntellect Design Arena Limited,M:
>>> +91-9487439570,Plot No. 3/G3, SIPCOT IT Park, Siruseri,Chennai – 600 130,
>>> India.*
>>>
>>> This e-Mail may contain proprietary and confidential information and is
>>> sent for the intended recipient(s) only. If by an addressing or
>>> transmission error this mail has been misdirected to you, you are requested
>>> to delete this mail immediately. You are also hereby notified that any use,
>>> any form of reproduction, dissemination, copying, disclosure, modification,
>>> distribution and/or publication of this e-mail message, contents or its
>>> attachment other than by its intended recipient/s is strictly prohibited.
>>> Visit us at *https://www.intellectdesign.com*
>>> <https://www.intellectdesign.com/>
>>
>>
>>
>>
> This e-Mail may contain proprietary and confidential information and is
> sent for the intended recipient(s) only. If by an addressing or
> transmission error this mail has been misdirected to you, you are requested
> to delete this mail immediately. You are also hereby notified that any use,
> any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and/or publication of this e-mail message, contents or its
> attachment other than by its intended recipient/s is strictly prohibited.
> Visit us at *https://www.intellectdesign.com*
> <https://www.intellectdesign.com/>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
1 month, 1 week
WFNAM00018 - Failed to connect to remote host
by Subramanian1 R iGTB
Hi Team
This is regarding Integration between GAMFT (Go Anywhere Managed File
transfer) and JBOSS server.(EAP-7.3.8)
Jar Used - wildfly-client-all-20.0.1.Final.jar
Java Version - Java 11
GAMFT Version - 7.1.3
Jboss Version - EAP-7.3.8
Also we have raised the same issue in Jboss Community as well waiting for
the moderator to approve. PFB Screenshot FYR.
[image: Jboss.jpg]
We are encountering the below error while we are trying to send JMS.to
Jboss from GAMFT 7.1.3 application.
javax.jms.JMSException: WFNAM00018: Failed to connect to remote host
at
com.linoma.resource.mq.JNDIConnectionFactory.getConnection(JNDIConnectionFactory.java:78)
at
com.linoma.ga.projects.resources.MQResource.testJNDIConnection(MQResource.java:411)
at com.linoma.ga.projects.resources.MQResource.test(MQResource.java:282)
at
com.linoma.ga.projects.resources.ResourceTester.executeTest(ResourceTester.java:175)
at
com.linoma.ga.projects.resources.ResourceTester.test(ResourceTester.java:123)
at
com.linoma.ga.ui.admin.resources.ConfigureResourceForm.test(ConfigureResourceForm.java:398)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown
Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.el.parser.AstValue.invoke(AstValue.java:252)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:266)
at
org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74)
at
org.primefaces.application.DialogActionListener.processAction(DialogActionListener.java:46)
at javax.faces.component.UICommand.broadcast(UICommand.java:120)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1174)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:365)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1660)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:864)
at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:42)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.linoma.ga.ui.admin.LocaleFilter.doFilter(LocaleFilter.java:99)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.linoma.ga.ui.admin.WebDocFilter.doFilter(WebDocFilter.java:119)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
com.linoma.ga.core.upload.AdminFileUploadFilter.doFilter(AdminFileUploadFilter.java:81)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.linoma.dpa.security.SecurityFilter.doFilter(SecurityFilter.java:316)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
com.linoma.dpa.security.SecurityHeaderFilter.doFilter(SecurityHeaderFilter.java:104)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
com.linoma.ga.ui.core.filter.IFrameEmbeddingFilter.doFilter(IFrameEmbeddingFilter.java:90)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
com.linoma.ga.ui.core.filter.NoCacheFilter.doFilter(NoCacheFilter.java:46)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
com.linoma.ga.ui.core.filter.IECompatibilityModeFilter.doFilter(IECompatibilityModeFilter.java:61)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
com.linoma.dpa.j2ee.AdminRedirectFilter.doFilter(AdminRedirectFilter.java:50)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
com.linoma.ga.ui.core.filter.XForwardedForFilter.doFilter(XForwardedForFilter.java:55)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Unknown Source)
We Seek your support to overcome this issue.
*Thanks & Regards,*
*Subramanian SP RM | Team Lead | iGTBIntellect Design Arena Limited,M:
+91-9487439570,Plot No. 3/G3, SIPCOT IT Park, Siruseri,Chennai – 600 130,
India.*
--
This e-Mail may contain proprietary and confidential information and is
sent for the intended recipient(s) only. If by an addressing or
transmission error this mail has been misdirected to you, you are requested
to delete this mail immediately. You are also hereby notified that any use,
any form of reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its
attachment other than by its intended recipient/s is strictly prohibited.
Visit us at *https://www.intellectdesign.com*
<https://www.intellectdesign.com/>
1 month, 1 week
