[JBoss JIRA] (WFCORE-865) Patching regression between WFCore 2.0.0.Alpha9 and Alpha11
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-865:
------------------------------------
Summary: Patching regression between WFCore 2.0.0.Alpha9 and Alpha11
Key: WFCORE-865
URL: https://issues.jboss.org/browse/WFCORE-865
Project: WildFly Core
Issue Type: Bug
Components: Patching
Affects Versions: 2.0.0.Alpha11
Reporter: Ladislav Thon
Assignee: Alexey Loubyansky
With WildFly 10.0.0.Alpha5 (Core 2.0.0.Alpha9):
{code}
./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch apply test-patch-10.0.0.Alpha5.zip"
{
"outcome" : "success",
"result" : {}
}
./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch history"
{
"outcome" : "success",
"result" : [{
"patch-id" : "test-patch",
"type" : "cumulative",
"applied-at" : "8/4/15 9:07 AM"
}]
}
./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch info"
Version: undefined
Cumulative patch ID: test-patch
One-off patches: none
{code}
With WildFly 10.0.0.Alpha6 (Core 2.0.0.Alpha11):
{code}
./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch apply test-patch-10.0.0.Alpha6.zip"
{
"outcome" : "success",
"result" : {}
}
./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch history"
{
"outcome" : "success",
"result" : []
}
./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch info"
Version: undefined
Cumulative patch ID: base
One-off patches: none
{code}
With WildFly 10.0.0.Alpha6, based on {{patch history}} and {{patch info}}, it looks like the patch doesn't even apply, but that's not actually true, because trying to apply the patch once again results in
{code}
WFLYPAT0039: Requested WildFly version 10.0.0.Alpha6 did not match the installed version 10.0.0.Alpha6_PATCHED
{code}
So the patch in fact _is_ installed, it's just that neither {{patch history}} nor {{patch info}} doesn't show it like it used to.
The only reason I could come up with is that I use {{EAP}} as the {{<upgrade name="...">}}:
{code}
<upgrade name="EAP" version="10.0.0.Alpha6" to-version="10.0.0.Alpha6_PATCHED"/>
{code}
However:
1. This used to work just fine in WildFly 10.0.0.Alpha5 and before.
2. If this is now considered wrong, the patch shouldn't even apply in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (AS7-6911) jconsole fails if trying to connect to a standalone EAP instance running with offset ports
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6911?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6911:
----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from POST to MODIFIED
> jconsole fails if trying to connect to a standalone EAP instance running with offset ports
> ------------------------------------------------------------------------------------------
>
> Key: AS7-6911
> URL: https://issues.jboss.org/browse/AS7-6911
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Stan Silvert
> Labels: cli
>
> If JBoss AS7/8 is started using port-offset as following:
> ie. with -Djboss.socket.binding.port-offset=100
> Then While connecting to it using "jconsole.sh" as a Local Process it throws the following Exception:
> +++++++++++++++++++++++++++++
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
> at java.awt.EventQueue.access$000(EventQueue.java:84)
> at java.awt.EventQueue$1.run(EventQueue.java:607)
> at java.awt.EventQueue$1.run(EventQueue.java:605)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> +++++++++++++++++++++++
> And the Code "org.jboss.as.cli.gui.JConsoleCLIPlugin" classes Line 109 throws NullPointerException, Because "cliGuiCtx" object is null and not initialized earlier:
> 109 JOptionPane.showMessageDialog(cliGuiCtx.getMainWindow(), message);
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-1548) Add fallback querry to jconsole plugin
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1548?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1548:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from POST to MODIFIED
> Add fallback querry to jconsole plugin
> --------------------------------------
>
> Key: WFLY-1548
> URL: https://issues.jboss.org/browse/WFLY-1548
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 8.0.0.Alpha1
> Reporter: Bartosz Baranowski
> Assignee: Darran Lofthouse
> Labels: JConsole, JMX, Plugin
> Fix For: 8.0.0.Beta1
>
>
> JConsolePlugin connecects to default port, despite chance to use proper info.
> Problem:
> Unless I miss somethingm JConsole has a bit tight isolation between components. There is no way for AS7 JConsolePlugin to access "connect dialog" info. Hence it has no idea what is the content of URL being passed as remote.
> AS7 JConsolePlugin checks if MBeanServerConnection is instance of RemotinConnection. If its not, it fallbacks to default: localhost:9990.
> However we can check for socket bindings and try to connect to proper socket.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4625) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4625?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4625:
-----------------------------------------------
Jitka Kozana <jkudrnac(a)redhat.com> changed the Status of [bug 1243553|https://bugzilla.redhat.com/show_bug.cgi?id=1243553] from ON_QA to ASSIGNED
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4625
> URL: https://issues.jboss.org/browse/WFLY-4625
> Project: WildFly
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
> Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (SECURITY-744) WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-744?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-744:
--------------------------------------------------
Jitka Kozana <jkudrnac(a)redhat.com> changed the Status of [bug 1245353|https://bugzilla.redhat.com/show_bug.cgi?id=1245353] from ON_QA to ASSIGNED
> WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal
> ----------------------------------------------------------------------------------
>
> Key: SECURITY-744
> URL: https://issues.jboss.org/browse/SECURITY-744
> Project: PicketBox
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security
>
> {{WebJASPIAuthenticator}} creates a new Subject that it passes to the JASPIC Auth Module (SAM):
> {code}
> Subject clientSubject = new Subject();
> if (sam != null) {
> result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh);
> }
> {code}
> [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...]
> Afterwards this Subject instance is put into the {{JBossGenericPrincipal}} when this is being build:
> {code}
> protected Principal buildJBossPrincipal(Subject subject, Principal principal, GroupPrincipalCallback gpc) {
> // ...
> // build and return the JBossGenericPrincipal.
> return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, subject);
> }
> {code}
> [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...]
> This seems to assume that the JASPIC Auth Module has populated the Subject (as happens with JAAS login modules), but this is not what happens. JASPIC Auth Modules unlike JAAS login modules are universal and have no knowledge of the container specific Subject layout.
> The container should thus populate the Subject based on the callbacks.
> {{WebJASPIAuthenticator}} does uses the callbacks to store the caller/user principal and roles directly into the {{JBossGenericPrincipal}}. Calls like {{HttpServletRequest#getUserPrincipal}} directly return {{JBossGenericPrincipal#getUserPrincipal}} and thus work.
> However, {{EJBContext#getCallerPrincipal()}} which is implemented by {{org.jboss.as.security.service.SimpleSecurityManager#getCallerPrincipal}} works with {{securityContext.getSubjectInfo().getAuthenticatedSubject}} and does _not_ work.
> This {{SubjectInfo}} is initialized in {{org.jboss.as.web.security.SecurityContextAssociationValve}} via the following code:
> {code}
> sc.getUtil().createSubjectInfo(new SimplePrincipal(
> principal.getName()),
> principal.getCredentials(),
> principal.getSubject() // clientSubject from JASPIC SAM
> );
> {code}
> (principal here is the {{JBossGenericPrincipal}} that's returned by {{WebJASPIAuthenticator}})
> Because the Subject instance used here is still the empty instance, the authenticated identity will not be available in EJB beans. {{EJBContext#getCallerPrincipal()}} will always return the anonymous principal and every check for a role will return false.
> Adding something like the following code to {{buildJBossPrincipal}} seems to propagate the authenticated identity correctly to the EJB module:
> {code}
> Subject authenticatedSubject = new Subject();
> // Add the caller principal to the Subject
> Group callerPrincipalGroup = new SimpleGroup("CallerPrincipal");
> callerPrincipalGroup.addMember(principal);
> authenticatedSubject.getPrincipals().add(callerPrincipalGroup);
>
> // Add the roles to the Subject
> if (!roles.isEmpty()) {
> Group rolesGroup = new SimpleGroup("Roles");
> for (String role : roles) {
> rolesGroup.addMember(new SimplePrincipal(role));
> }
> authenticatedSubject.getPrincipals().add(rolesGroup);
> }
> return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, authenticatedSubject);
> {code}
> I've tested [locally|https://github.com/javaeekickoff/jboss-as-jaspic-patch/commit/31b...] with this patch and it indeed seems to work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (SECURITY-745) WebJASPIAuthenticator doesn't register Subject with SecurityContext
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-745?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-745:
--------------------------------------------------
Jitka Kozana <jkudrnac(a)redhat.com> changed the Status of [bug 1245353|https://bugzilla.redhat.com/show_bug.cgi?id=1245353] from ON_QA to ASSIGNED
> WebJASPIAuthenticator doesn't register Subject with SecurityContext
> -------------------------------------------------------------------
>
> Key: SECURITY-745
> URL: https://issues.jboss.org/browse/SECURITY-745
> Project: PicketBox
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After an authenticated identity is established, WebJASPIAuthenticator registers this with the current request, session (if cache is enabled) and optionally SSO:
> {code}
> /**
> * <p>
> * Registers an authenticated Principal and authentication type in our request, in the current session (if there is one),
> * and with our SingleSignOn valve, if there is one. Set the appropriate cookie to be returned.
> * </p>
> *
> * [...[
> */
> @Override
> protected void register(...)
> {code}
> [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...]
> What it does *not* do however is registering this same information with the [SecurityContext|http://grepcode.com/file/repo1.maven.org/maven2/org.picke...] where the EJB programmatic security can pick it up.
> Now in the next request {{org.jboss.as.web.security.SecurityContextAssociationValve}} will do this registration, but this means:
> # Programmatic EJB security ({{EJBContext#isCallerInRole}} etc) can not be used in the same request in which authentication took place, since the {{SecurityContextAssociationValve}} runs before {{WebJASPIAuthenticator}}
> # This mechanism depends on the session cache being used. _(This is true by default in JBoss, but it should not be according to the JASPIC spec and users may opt to disable it, possibly since some SAM could require this in order to function correctly)_
> I would like to propose putting code like the following in the mentioned {{register}} method or just after it, e.g.
> {code}
> protected boolean authenticate(Request request, HttpServletResponse response, LoginConfig config) throws IOException {
> // [...]
> // if the client principal is not a jboss generic principal, we need to build one before registering.
> if (!(clientPrincipal instanceof JBossGenericPrincipal))
> clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal, gpc);
>
> this.register(request, response, clientPrincipal, authMethod, pvc != null ? pvc.getUsername() : null,
> pvc != null && pvc.getPassword() != null ? new String(pvc.getPassword()) : null);
> // NEW: Associate Subject with SecurityContext
>
> SecurityContext context = SecurityActions.getSecurityContext();
> if (context == null) {
> throw PicketBoxMessages.MESSAGES.invalidNullSecurityContext();
> }
>
> JBossGenericPrincipal jbossGenericPrincipal = (JBossGenericPrincipal) clientPrincipal;
> context.getUtil().createSubjectInfo(new SimplePrincipal(
> jbossGenericPrincipal.getName()),
> jbossGenericPrincipal.getCredentials(),
> jbossGenericPrincipal.getSubject()
> );
> {code}
> Maybe the security context should be created if it does not exists, but I think it should always exist at the given point, shouldn't it?
> Note that this depends on SECURITY-744, since in the current trunk version of {{WebJASPIAuthenticator}} the {{Subject}} isn't build at all.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (DROOLS-795) Timers are reset during the serialization process
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-795?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-795:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1248024, https://bugzilla.redhat.com/show_bug.cgi?id=1248429, https://bugzilla.redhat.com/show_bug.cgi?id=1249886 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1248024)
> Timers are reset during the serialization process
> -------------------------------------------------
>
> Key: DROOLS-795
> URL: https://issues.jboss.org/browse/DROOLS-795
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR1
>
>
> When the marshall serializes a timer it doesn't take count of how much time it is already passed, so when the timer is deserialized it restart from it start time. The following failing test case reproduces the problem.
> {code}
> @Test
> public void testMarshallWithTimedRule() {
> String drl = "rule \"Rule A Timeout\"\n" +
> "when\n" +
> " String( this == \"ATrigger\" )\n" +
> "then\n" +
> " insert (new String( \"A-Timer\") );\n" +
> "System.out.println(\"+++++++Got ATrigger, started A-Timer with 5s timeout\");\n" +
> "end\n" +
> "\n" +
> "rule \"Timer For rule A Timeout\"\n" +
> " timer ( int: 5s )\n" +
> "when\n" +
> " String( this == \"A-Timer\")\n" +
> "then\n" +
> " delete ( \"A-Timer\" );\n" +
> " delete ( \"ATrigger\" );\n" +
> "System.out.println(\"******* reset rule A based on timer\");\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL )
> .build( EqualityBehaviorOption.EQUALITY,
> DeclarativeAgendaOption.ENABLED,
> EventProcessingOption.STREAM );
> KieSessionConfiguration sessionConfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> sessionConfig.setOption( ClockTypeOption.get( "pseudo" ) );
> KieSession ksession = kbase.newKieSession(sessionConfig, null);
> ksession.insert( new String( "ATrigger" ) );
> assertEquals( 1, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> ksession = marshallAndUnmarshall( kbase, ksession, sessionConfig);
> clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 0, ksession.getFactCount() );
> }
> public static KieSession marshallAndUnmarshall(KieBase kbase, KieSession ksession, KieSessionConfiguration sessionConfig) {
> // Serialize and Deserialize
> try {
> Marshaller marshaller = KieServices.Factory.get().getMarshallers().newMarshaller(kbase);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> marshaller.marshall(baos, ksession);
> marshaller = MarshallerFactory.newMarshaller( kbase );
> ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
> baos.close();
> ksession = marshaller.unmarshall(bais, sessionConfig, null);
> bais.close();
> } catch (Exception e) {
> e.printStackTrace();
> fail("unexpected exception :" + e.getMessage());
> }
> return ksession;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
by Partap Aujla (JIRA)
[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ]
Partap Aujla edited comment on WFLY-4682 at 8/3/15 5:36 PM:
------------------------------------------------------------
Hello,
I attempted (1) and it failed for me. I received a parse error at startup.
(2) Was an option but I did not attempt this.
What I realized was that javax.jms.api is not listed as a dependency in javax.api (module.xml) and javax.api is the main dependency in most of other modules. Starting from the top of extensions in the standalone.xml file I went through each module (org.jboss.as.clustering.infinispan, org.jboss.as.connector, etc.) till I found module which had javax.jms.api as a dependency. In my case it was module org.jboss.as.ejb3. I then modified the module.xml of this module and set export = true for javax.jms.api. ( <module name="javax.jms.api" export="true"/>. ) Path to module.xml of org.jboss.as.ejb3 <WildFly_HOME_DIR>/modules/system/layers/base/org/jboss/as/ejb3/main
Hope this helps.
was (Author: paujla03):
Hello,
I attempted (1) and it failed for me. I received a parse error at startup.
(2) Was an option but I did not attempt this.
What I realized was that javax.jms.api is not listed as a dependency in javax.api (module.xml) and javax.api is the main dependency in most of other modules. Starting from the top of extensions in the standalone.xml file I went through each module (org.jboss.as.clustering.infinispan, org.jboss.as.connector, etc.) till I found module which had javax.jms.api as a dependency. In my case it was module org.jboss.as.ejb3. I then modified the module.xml and set export = true for javax.jms.api. ( <module name="javax.jms.api" export="true"/>. ) Path to module.xml <WildFly_HOME_DIR>/modules/system/layers/base/org/jboss/as/ejb3/main
Hope this helps.
> standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4682
> URL: https://issues.jboss.org/browse/WFLY-4682
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, MSC
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Bartosz Baranowski
> Labels: duplicate
> Attachments: standalone-full.xml
>
>
> Deployment (Servlet, EJB, MDB) which is using Websphere MQ 8 resource adapter to send/receive messages from external Websphere MQ 8 instance is not loading "javax.jms.api" module. Deployment is using JMS api.
> This is change in behaviour against previous versions EAP 6/Widlfly 9.
> There is no error during deploy. Failures occur in the moment when deployment for example servlet is called. Following error is logged in EAP 7.0.0.DR2 log:
> {code}
> 08:57:24,835 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "servlet.war" with deployment "servlet.war"
> 08:57:24,838 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /home/mnovak/projects/eap-tests-wsmq/ibm-mq-testsuite/src/test/config/ibm8/install/jboss-eap-7.0/standalone/data/content/62/931347d12b65c80cd2201372be52f0494e361a/content
> 08:57:25,794 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /CleaningServlet/CleaningServlet: java.lang.NoClassDefFoundError: javax/jms/Message
> at org.jboss.as.test.ibm.mq.servlet.CleaningServlet.doGet(CleaningServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
> Caused by: java.lang.ClassNotFoundException: javax.jms.Message from [Module "deployment.servlet.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 30 more
> {code}
> Websphere MQ resource adapter is rar archive in deployments directory. It's not configured in module. Only way to force loading of "javax.jms.api" for deployment is to add Dependecies: javax.jms.api to MANIFEST.MF or add it to global-modules. This negatively affects usability.
> Can be javax.jms.api loaded for deployment by default for "full" and "full-ha" profile?
> I'm adding standalone-full.xml with configuration for EAP 7.0.0.DR2.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months