August 2018 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-26071) Add server adapter for WildFly 13

by Pavol Srna (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26071?page=com.atlassian.jira.plugi... ] Pavol Srna commented on JBIDE-26071: ------------------------------------ [~marks1900], I believe the work was done in 4.6.0.Final and the issue was just left open. I asked about it in my first comment here some time ago, but Rob (the server component owner) did not respond to my question. I believe that the change in fix version to "4.9.0.AM1" was because of some automated script from Nick Boldt. I will change it back to 4.6.0.Final, to what I believe is the correct fix version for this issue. > Add server adapter for WildFly 13 > --------------------------------- > > Key: JBIDE-26071 > URL: https://issues.jboss.org/browse/JBIDE-26071 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Affects Versions: 4.6.0.AM2 > Reporter: Martin Malina > Assignee: Rob Stryker > Priority: Blocker > Fix For: 4.6.0.Final > > > It turns out WildFly 13 was released yesterday. They're on a quarterly release cadence now apparently. So I wonder how we should deal with this. Perhaps should group some of the versions if there are no breaking changes for us? Or do you think it's better to stick with our current model of always adding a new adapter and that way you can always update the libs? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26254) Request parameters are not validated

by Jan Richter (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26254?page=com.atlassian.jira.plugi... ] Jan Richter commented on JBIDE-26254: ------------------------------------- A list of methods that have problems with wrong parameters: * findServerBeans - null values * addDiscoveryPath - null values * removeDiscoveryPath - null values * getRequiredAttributes - null values * getOptionalAttributes - null values * createServer - null values * deleteServer - null values * getLaunchModes - unsupported server types, null values * getLaunchCommand - null values * serverStaring(ed)ByClient - null values * start/stopServerAsync - null values Note: getRequired/OptionalLaunchAttributes return null (JBIDE-26281) anyway, so they might still be worth checking out > Request parameters are not validated > ------------------------------------ > > Key: JBIDE-26254 > URL: https://issues.jboss.org/browse/JBIDE-26254 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-server-protocol > Reporter: Jan Richter > Assignee: Rob Stryker > > When sending requests with parameters, one can simply send invalid objects as payload. The server does not respond then (because it is too busy throwing exceptions, I presume). > i.e. send: server/findServerBeans(null) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26285) stopServerAsync returns ok when stopping a stopped server

by Jan Richter (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26285?page=com.atlassian.jira.plugi... ] Jan Richter reassigned JBIDE-26285: ----------------------------------- Assignee: Rob Stryker > stopServerAsync returns ok when stopping a stopped server > --------------------------------------------------------- > > Key: JBIDE-26285 > URL: https://issues.jboss.org/browse/JBIDE-26285 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-server-protocol > Reporter: Jan Richter > Assignee: Rob Stryker > > Calling server/stopServerAsync on a server that is already stopped returns: > {noformat}{ severity: 0, pluginId: 'unknown', code: 0, message: 'ok' }{noformat} > There is no indication that the server wasn't actually stopped as a result of the request. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26285) stopServerAsync returns ok when stopping a stopped server

by Jan Richter (JIRA)

Jan Richter created JBIDE-26285: ----------------------------------- Summary: stopServerAsync returns ok when stopping a stopped server Key: JBIDE-26285 URL: https://issues.jboss.org/browse/JBIDE-26285 Project: Tools (JBoss Tools) Issue Type: Bug Components: runtime-server-protocol Reporter: Jan Richter Calling server/stopServerAsync on a server that is already stopped returns: {noformat}{ severity: 0, pluginId: 'unknown', code: 0, message: 'ok' }{noformat} There is no indication that the server wasn't actually stopped as a result of the request. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22138) Server adapter: doesn't respect openshift maven profile

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22138?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-22138 at 8/2/18 9:03 AM: ------------------------------------------------------------------ [~rob.stryker] m2e-wtp sets the module name in the following method: [AbstractProjectConfiguratorDelegate#configureDeployedName|https://github....] I see it being called, which then causes the file to change on disk. This then causes *J2EEModuleVirtualComponent* to clear it's cache: {code} J2EEModuleVirtualComponent(VirtualComponent).clearCache() line: 721 J2EEModuleVirtualComponent.clearCache() line: 512 J2EEModuleVirtualComponent(VirtualComponent).resourceChanged(Resource) line: 95 VirtualComponent$ResourceAdapter.notifyChanged(Notification) line: 78 WTPModulesResource(TranslatorResourceImpl).eNotify(Notification) line: 444 WTPModulesResource(ResourceImpl).setModified(boolean) line: 1867 WTPModulesResource(TranslatorResourceImpl).doSave(OutputStream, Map) line: 192 WTPModulesResource(ResourceImpl).save(OutputStream, Map<?,?>) line: 1475 WTPModulesResource(ResourceImpl).save(Map<?,?>) line: 1044 WTPModulesResource(ReferencedXMIResourceImpl).save(Map) line: 377 WTPModulesResource(TranslatorResourceImpl).save(Map) line: 167 ModuleStructuralModel(EditModel).primSaveResource(Resource) line: 1303 ModuleStructuralModel(EditModel).saveResource(Resource) line: 1334 ModuleStructuralModel(EditModel).primSave(IProgressMonitor) line: 1269 EditModel$1.run(IProgressMonitor) line: 373 Workspace.run(ICoreRunnable, ISchedulingRule, int, IProgressMonitor) line: 2289 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2316 ModuleStructuralModel.runSaveOperation(IWorkspaceRunnable, IProgressMonitor) line: 310 ModuleStructuralModel(EditModel).save(IProgressMonitor, Object) line: 376 ModuleStructuralModel.saveIfNecessary(IProgressMonitor, Object) line: 392 StructureEdit.saveIfNecessary(IProgressMonitor) line: 397 WebProjectConfiguratorDelegate(AbstractProjectConfiguratorDelegate).configureDeployedName(IProject, String) line: 189 {code} But I dont see *JEEDeployableFactory#clearCache* being called. Btw. I dont see J2EEDeployableFactory listening to resource change. Here are the listeners that I see registered: * org.eclipse.emf.common.notify.impl.AdapterImpl@21197771 * org.eclipse.wst.common.internal.emfworkbench.integration.EditModel$ResourceAdapter@6bc55154 * org.eclipse.wst.common.internal.emfworkbench.WorkbenchResourceHelper$FileAdapter@3543d4e1 * EMF2DOMAdapterImpl(#document,WTPModulesResource), org.eclipse.wst.common.componentcore.internal.resources.VirtualComponent$ResourceAdapter@2e185af0 was (Author: adietish): [~rob.stryker] m2e-wtp sets the module name in the following method: [AbstractProjectConfiguratorDelegate#configureDeployedName|https://github....] I see it being called, which then causes the file to change on disk. This then causes *J2EEModuleVirtualComponent* to clear it's cache: {code} J2EEModuleVirtualComponent(VirtualComponent).clearCache() line: 721 J2EEModuleVirtualComponent.clearCache() line: 512 J2EEModuleVirtualComponent(VirtualComponent).resourceChanged(Resource) line: 95 VirtualComponent$ResourceAdapter.notifyChanged(Notification) line: 78 WTPModulesResource(TranslatorResourceImpl).eNotify(Notification) line: 444 WTPModulesResource(ResourceImpl).setModified(boolean) line: 1867 WTPModulesResource(TranslatorResourceImpl).doSave(OutputStream, Map) line: 192 WTPModulesResource(ResourceImpl).save(OutputStream, Map<?,?>) line: 1475 WTPModulesResource(ResourceImpl).save(Map<?,?>) line: 1044 WTPModulesResource(ReferencedXMIResourceImpl).save(Map) line: 377 WTPModulesResource(TranslatorResourceImpl).save(Map) line: 167 ModuleStructuralModel(EditModel).primSaveResource(Resource) line: 1303 ModuleStructuralModel(EditModel).saveResource(Resource) line: 1334 ModuleStructuralModel(EditModel).primSave(IProgressMonitor) line: 1269 EditModel$1.run(IProgressMonitor) line: 373 Workspace.run(ICoreRunnable, ISchedulingRule, int, IProgressMonitor) line: 2289 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2316 ModuleStructuralModel.runSaveOperation(IWorkspaceRunnable, IProgressMonitor) line: 310 ModuleStructuralModel(EditModel).save(IProgressMonitor, Object) line: 376 ModuleStructuralModel.saveIfNecessary(IProgressMonitor, Object) line: 392 StructureEdit.saveIfNecessary(IProgressMonitor) line: 397 WebProjectConfiguratorDelegate(AbstractProjectConfiguratorDelegate).configureDeployedName(IProject, String) line: 189 {code} But I dont see *J2EEDeployableFactory#clearCache* being called. Btw. I dont see J2EEDeployableFactory listening to resource change. Here are the listeners that I see registered: * org.eclipse.emf.common.notify.impl.AdapterImpl@21197771 * org.eclipse.wst.common.internal.emfworkbench.integration.EditModel$ResourceAdapter@6bc55154 * org.eclipse.wst.common.internal.emfworkbench.WorkbenchResourceHelper$FileAdapter@3543d4e1 * EMF2DOMAdapterImpl(#document,WTPModulesResource), org.eclipse.wst.common.componentcore.internal.resources.VirtualComponent$ResourceAdapter@2e185af0 > Server adapter: doesn't respect openshift maven profile > ------------------------------------------------------- > > Key: JBIDE-22138 > URL: https://issues.jboss.org/browse/JBIDE-22138 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Environment: JBoss Developer Studio (Core Features) 9.1.0.GA-v20160403-1700-B477 > Openshift plugin 3.1.0.Final-v20160401-2357-B263 > Reporter: Rafael Benevides > Assignee: Andre Dietisheim > Labels: openshift_v3, server_adapter > Fix For: 4.9.0.AM2 > > Attachments: image-2018-06-22-19-02-57-247.png > > > This is a follow up on JBIDE-22128. > The maven profile is never read to determine the actual archive name. That will require more coupling to m2e, in order to load the pom.xml model using the openshift profile, if it exists, in order to determine the archive name. This will be a long running operation and will require more significant changes > steps: > # EXEC: follow steps outlined in https://github.com/redhat-helloworld-msa/helloworld-msa/blob/master/hello... (deploying with fabric8 maven plugin doesn't work, you end up having the pod failing with ImagePullBack error. You need to take the alternative road where you deploy via "oc new-build", "oc new-app", "oc expose" etc.) > # EXEC: import the app into your Eclipse workspace > # EXEC: "hello" (workspace) project: Properties > Maven > Active Maven Profile: set "openshift" > # EXEC: create a server adapter and start it > # ASSERT: adapter starts syncing, verify what war is used > Result: > The war that's created locally and then synced to the pod is "hello.war" even though the profile specifies "ROOT.war" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26283) Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26283?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-26283: ------------------------------------ When reporting a problem like this, it would be useful to look at the console log to see that the error "Baseline and reactor have same fully qualified version, but with different content" is reported 50 times for various plugins and features. The simplest fix is to bump the versions of these plugins/features. Or bump the versions of EVERYTHING in base, regardless of error. Or we could set an older URL for the baseline check. Or we could attempt to configure the baseline check mojo to not complain when the the rebuilt bits are different from the baseline ones. > Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features > ---------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-26283 > URL: https://issues.jboss.org/browse/JBIDE-26283 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.9.0.AM1 > Reporter: Josef Kopriva > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.9.0.AM2 > > > Job https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... is red for one week. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26283) Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features

by Josef Kopriva (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26283?page=com.atlassian.jira.plugi... ] Josef Kopriva updated JBIDE-26283: ---------------------------------- Fix Version/s: 4.9.0.AM2 (was: 4.9.0.AM1) > Baseline and reactor have same fully qualified version, but with different content in jbosstools-base plugins/features > ---------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-26283 > URL: https://issues.jboss.org/browse/JBIDE-26283 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.9.0.AM1 > Reporter: Josef Kopriva > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.9.0.AM2 > > > Job https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... is red for one week. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26284) Servers created from relative path can't start

by Jan Richter (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26284?page=com.atlassian.jira.plugi... ] Jan Richter reassigned JBIDE-26284: ----------------------------------- Assignee: Rob Stryker > Servers created from relative path can't start > ---------------------------------------------- > > Key: JBIDE-26284 > URL: https://issues.jboss.org/browse/JBIDE-26284 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-server-protocol > Reporter: Jan Richter > Assignee: Rob Stryker > > Servers created with their ''server.home.dir'' attribute set to a relative path will error on starting. > Example log from wildfly: > {noformat}Error: Could not find or load main class org.jboss.modules.Main{noformat} > Relative paths either need to be resolved, or rejected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26284) Servers created from relative path can't start

by Jan Richter (JIRA)

[ https://issues.jboss.org/browse/JBIDE-26284?page=com.atlassian.jira.plugi... ] Jan Richter updated JBIDE-26284: -------------------------------- Description: Servers created with their ''server.home.dir'' attribute set to a relative path will error on starting. Example log from wildfly (and yes, that is the complete log): {noformat}Error: Could not find or load main class org.jboss.modules.Main{noformat} Relative paths either need to be resolved, or rejected. was: Servers created with their ''server.home.dir'' attribute set to a relative path will error on starting. Example log from wildfly: {noformat}Error: Could not find or load main class org.jboss.modules.Main{noformat} Relative paths either need to be resolved, or rejected. > Servers created from relative path can't start > ---------------------------------------------- > > Key: JBIDE-26284 > URL: https://issues.jboss.org/browse/JBIDE-26284 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: runtime-server-protocol > Reporter: Jan Richter > Assignee: Rob Stryker > > Servers created with their ''server.home.dir'' attribute set to a relative path will error on starting. > Example log from wildfly (and yes, that is the complete log): > {noformat}Error: Could not find or load main class org.jboss.modules.Main{noformat} > Relative paths either need to be resolved, or rejected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-26284) Servers created from relative path can't start

by Jan Richter (JIRA)

Jan Richter created JBIDE-26284: ----------------------------------- Summary: Servers created from relative path can't start Key: JBIDE-26284 URL: https://issues.jboss.org/browse/JBIDE-26284 Project: Tools (JBoss Tools) Issue Type: Bug Components: runtime-server-protocol Reporter: Jan Richter Servers created with their ''server.home.dir'' attribute set to a relative path will error on starting. Example log from wildfly: {noformat}Error: Could not find or load main class org.jboss.modules.Main{noformat} Relative paths either need to be resolved, or rejected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues August 2018