[JBoss JIRA] (JBIDE-18861) module start action does not delete *.undeployed file
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18861?page=com.atlassian.jira.plugi... ]
Rob Stryker reassigned JBIDE-18861:
-----------------------------------
Assignee: Rob Stryker
> module start action does not delete *.undeployed file
> -----------------------------------------------------
>
> Key: JBIDE-18861
> URL: https://issues.jboss.org/browse/JBIDE-18861
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Environment: Windows7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> If you start Wildfly with all modules enabled and started.
> Now use STOP action on an EAR module.
> Now stop Wildfly.
> Now start Wildfly (debug or run).
> It will start up without the EAR module running, this is correct behavior at this point.
> Now use START on EAR module. It fails to start at all.
> This is because the file *.undeployed still exists. If you manually remove the file (using system file manager) the module will start up.
> If you perform a "full publish" on the module that appears to cause it to start up as well.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBIDE-18764) Weird behavior of the packaging exclusions support
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18764?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-18764:
-------------------------------------
[~fbricon] Any luck replicating this?
> Weird behavior of the packaging exclusions support
> --------------------------------------------------
>
> Key: JBIDE-18764
> URL: https://issues.jboss.org/browse/JBIDE-18764
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Fred Bricon
> Attachments: excludejars.zip
>
>
> I have a multi-module maven project with ear, war, ejb ...
> The excludejars-web/pom.xml defines <packagingExcludes>WEB-INF/lib/*</packagingExcludes>
> When deploying excludejars-ear to WF, the excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib directory is empty, as expected.
> Now if you remove <packagingExcludes>WEB-INF/lib/*</packagingExcludes> from the excludejars-web/pom.xml , Update the Maven project configuration (Alt-F5) on the excludejars-web project, org.eclipse.wst.common.component is updated to contain <property name="component.exclusion.patterns"/>
> When you do a full publish on the ear project, excludejars-ear/excludejars-web-0.0.1-SNAPSHOT.war/WEB-INF/lib is still empty. Same thing if you invoke "clean" on the WF server adapter.
> The only way to get the jars deployed is to remove the ear from WF, clean, then add the ear back.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBIDE-18861) module start action does not delete *.undeployed file
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18861?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-18861:
-------------------------------------
[~mmalina] Please verify this on master so I know whether its suitable for maintenance.
> module start action does not delete *.undeployed file
> -----------------------------------------------------
>
> Key: JBIDE-18861
> URL: https://issues.jboss.org/browse/JBIDE-18861
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Environment: Windows7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> If you start Wildfly with all modules enabled and started.
> Now use STOP action on an EAR module.
> Now stop Wildfly.
> Now start Wildfly (debug or run).
> It will start up without the EAR module running, this is correct behavior at this point.
> Now use START on EAR module. It fails to start at all.
> This is because the file *.undeployed still exists. If you manually remove the file (using system file manager) the module will start up.
> If you perform a "full publish" on the module that appears to cause it to start up as well.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-15135:
----------------------------------------
{quote}QUESTION Should there be something in upstream?{quote}
Upstream contains the buildInfo from upstream sites, when available (except there own upstream elements or we'd get huge files)
{quote}QUESTION What about details about the OS & JDK version?{quote}
I didn't include them because I never used them (I also use this mojo as an opportunity to think about what's not useful any more). It would be easy to re-introduce if you use them occasionally.
{quote}QUESTION Why are TARGET_PLATFORM_VERSION, TARGET_PLATFORM_VERSION_MAXIMUM, BUILD_ALIAS and BUILD_ID not resolved? The first 3 of those are from maven variables in the parent pom (if not set commandline), and BUILD_ID is a timestamp that could be the same as the one placed in GIT_REVISION.txt{quote}
This should report the build properties that are specified manually. So unless you set those properties, buildInfo reports null. On Jenkins, since we set thos properties, they would be set.
{quote}QUESTION Why is WORKSPACE not listed, and resolved to `pwd` ? This is often useful when builds fail to figure out where files have been created on a slave's filesystem, because they don't all use the same workspace path convention. And while you CAN browse the workspace within Jenkins, sometimes it's more efficient to do so over ssh.{quote}
Same reason, it's reporting the value of the property from Jenkins (or CLI).
{quote}QUESTION Can you also generate an ALL_VERSIONS.txt for aggregate builds? Or does that only happen when the mojo detects there are upstream projects? If so, how do I tell the mojo that there are upstream projects when building locally?{quote}
This is meant to go in the upstream block when upstream data is available
{quote}QUESTION Why did you change the format of GIT_REVSION.txt? I like that you've added details about the repo from which the code comes, but would a format such as the one below be more compact & easier to parse out the useful values of branch/tag, SHA, and source repo?{quote}
I created this new format because it would also list aliases when there are some. I don't mind much changing it since I believe the "revision" block of buildinfo.json is a better alternative.
> Attach metadata during assembly instead of publish time
> -------------------------------------------------------
>
> Key: JBIDE-15135
> URL: https://issues.jboss.org/browse/JBIDE-15135
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.x
>
>
> In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site.
> Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-18862:
-------------------------------------
[~mmalina] let me know if this works in master
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBDS-3275) Add wildfly archetypes to JBoss Central
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-3275?page=com.atlassian.jira.plugin.... ]
Fred Bricon edited comment on JBDS-3275 at 1/5/15 11:05 AM:
------------------------------------------------------------
Fastest solution is probably to use http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png
!http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png!
... and set proper dimensions via css, if needed. File name says 1180px but it really is 1280.
In the mean time, you can also open a bug on https://issues.jboss.org/browse/DESIGN/ and request for a scaled down version of wildfly-banner.
was (Author: fbricon):
Fastest solution is probably to use
!http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png!
... and set proper dimensions via css, if needed. File name says 1180px but it really is 1280.
In the mean time, you can also open a bug on https://issues.jboss.org/browse/DESIGN/ and request for a scaled down version of wildfly-banner.
> Add wildfly archetypes to JBoss Central
> ---------------------------------------
>
> Key: JBDS-3275
> URL: https://issues.jboss.org/browse/JBDS-3275
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Fix For: 8.1.0.GA
>
>
> Supporting Wildfly archetypes with JBoss Central. As an Java EE developer, I need to be able to switch between EAP and Wildfly, when I select Wildfly, the archetype needs to correctly include the right BOMs, where all artifacts are available only on Maven Central.
> This should include both the Java EE Web Project, Java EE EAR Project, and HTML5 Project
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBDS-3275) Add wildfly archetypes to JBoss Central
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-3275?page=com.atlassian.jira.plugin.... ]
Fred Bricon commented on JBDS-3275:
-----------------------------------
Fastest solution is probably to use
!http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png!
... and set proper dimensions via css, if needed. File name says 1180px but it really is 1280.
In the mean time, you can also open a bug on https://issues.jboss.org/browse/DESIGN/ and request for a scaled down version of wildfly-banner.
> Add wildfly archetypes to JBoss Central
> ---------------------------------------
>
> Key: JBDS-3275
> URL: https://issues.jboss.org/browse/JBDS-3275
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Fix For: 8.1.0.GA
>
>
> Supporting Wildfly archetypes with JBoss Central. As an Java EE developer, I need to be able to switch between EAP and Wildfly, when I select Wildfly, the archetype needs to correctly include the right BOMs, where all artifacts are available only on Maven Central.
> This should include both the Java EE Web Project, Java EE EAR Project, and HTML5 Project
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBIDE-18953) Unexpected JAX-RS validation error for client filters
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18953?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-18953:
----------------------------------
Fix Version/s: (was: 4.3.0.Alpha1)
> Unexpected JAX-RS validation error for client filters
> -----------------------------------------------------
>
> Key: JBIDE-18953
> URL: https://issues.jboss.org/browse/JBIDE-18953
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.2.0.Final
> Reporter: Valentin Baciu
> Assignee: Xavier Coulon
> Fix For: 4.2.2.Final
>
>
> We are using JAX-RS client filters in our project. One of the classes looks like this:
> ...
> import java.io.IOException;
> import javax.ws.rs.client.ClientRequestContext;
> import javax.ws.rs.client.ClientRequestFilter;
> import javax.ws.rs.client.ClientResponseContext;
> import javax.ws.rs.client.ClientResponseFilter;
> import javax.ws.rs.ext.Provider;
> ...
> @Provider
> public class ClientFilter implements ClientRequestFilter, ClientRequestFilter
> {
> ...
> }
> The class is part of a Dynamic Web Project with JAX-RS support turned on.
> The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error:
> The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver.
> I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBIDE-18994) Unexpected JAX-RS validation error for client filters
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18994?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-18994:
----------------------------------
Fix Version/s: (was: 4.2.2.Final)
> Unexpected JAX-RS validation error for client filters
> -----------------------------------------------------
>
> Key: JBIDE-18994
> URL: https://issues.jboss.org/browse/JBIDE-18994
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.2.0.Final
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Fix For: 4.3.0.Alpha1
>
>
> We are using JAX-RS client filters in our project. One of the classes looks like this:
> ...
> import java.io.IOException;
> import javax.ws.rs.client.ClientRequestContext;
> import javax.ws.rs.client.ClientRequestFilter;
> import javax.ws.rs.client.ClientResponseContext;
> import javax.ws.rs.client.ClientResponseFilter;
> import javax.ws.rs.ext.Provider;
> ...
> @Provider
> public class ClientFilter implements ClientRequestFilter, ClientRequestFilter
> {
> ...
> }
> The class is part of a Dynamic Web Project with JAX-RS support turned on.
> The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error:
> The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver.
> I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBIDE-18994) Unexpected JAX-RS validation error for client filters
by Xavier Coulon (JIRA)
Xavier Coulon created JBIDE-18994:
-------------------------------------
Summary: Unexpected JAX-RS validation error for client filters
Key: JBIDE-18994
URL: https://issues.jboss.org/browse/JBIDE-18994
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: webservices
Affects Versions: 4.2.0.Final
Reporter: Xavier Coulon
Assignee: Xavier Coulon
Fix For: 4.2.2.Final, 4.3.0.Alpha1
We are using JAX-RS client filters in our project. One of the classes looks like this:
...
import java.io.IOException;
import javax.ws.rs.client.ClientRequestContext;
import javax.ws.rs.client.ClientRequestFilter;
import javax.ws.rs.client.ClientResponseContext;
import javax.ws.rs.client.ClientResponseFilter;
import javax.ws.rs.ext.Provider;
...
@Provider
public class ClientFilter implements ClientRequestFilter, ClientRequestFilter
{
...
}
The class is part of a Dynamic Web Project with JAX-RS support turned on.
The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error:
The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver.
I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
