[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 resolved JBIDE-18953.
-----------------------------------
Resolution: Done
Change was pushed to 'jbosstools-4.2.x' branch without a PR :/ (but with proper post-push review by [~fbricon])
> 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-18953) Unexpected JAX-RS validation error for client filters
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18953?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-18953:
-------------------------------------
+1 for 4.2.2
> 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-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15135:
------------------------------------
{quote}This is meant to go in the upstream block when upstream data is available{quote}
When is it available? How is it made available? How do you test this offline? How does the mojo know about upstream projects, since none of the jobs are linked in Jenkins?
{quote}Same reason, it's reporting the value of the property from Jenkins (or CLI).{quote}
Why not also dump variables we know are important which are resolved from parent pom? Why only worry about CLI variables, not defaults too? (Consider what you see in the Help > About > Eclipse Config view -- it contains BOTH things set CLI / eclipse.ini and also defaults pulled from the OS/system. I think we should do that too.)
Re: OS/JDK details... we should include those. It's way better to just collect it at publish time than to have to go dig up the information later if something fails which is slave config specific, or is an OS-related problem. Is it a lot of work to collect that information? Surely you can just grab the output of `uname -a;java -version` ?
> 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] (JBTIS-374) Unknown category 'org.jboss.tools.central.discovery.a.web' when installing from central
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBTIS-374?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBTIS-374:
----------------------------------
Problem is that your directory.xml does not know where to find the JBDS Central plugin. It should contain THREE entries:
* JBDS Central [missing]
* JBDS Early Access [present]
* JBDS IS (Early Access) [present]
For example:
https://devstudio.jboss.com/updates/8.0-staging/devstudio-directory.xml
> Unknown category 'org.jboss.tools.central.discovery.a.web' when installing from central
> ---------------------------------------------------------------------------------------
>
> Key: JBTIS-374
> URL: https://issues.jboss.org/browse/JBTIS-374
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: distribution
> Affects Versions: 8.0.0.Beta2
> Environment: JBDS 8.0.1.GA + JBDS-IS 8.0.0.Beta2
> Reporter: Andrej Podhradsky
> Assignee: Paul Leacu
> Priority: Minor
>
> The following errors occur when we want to install JBDS-IS from JBoss Central
> !ENTRY org.eclipse.mylyn.discovery.core 4 0 2014-12-16 08:23:00.010
> !MESSAGE Unknown category 'org.jboss.tools.central.discovery.a.web' referenced by connector 'angularjs-eclipse-feature' declared in com.jboss.jbds.central.discovery.earlyaccess_8.0.0.Final_v20141017_1053_B366.jar_8432436156156296317.jar
> !ENTRY org.eclipse.mylyn.discovery.core 4 0 2014-12-16 08:23:00.023
> !MESSAGE Unknown category 'org.jboss.tools.central.discovery.a.web' referenced by connector 'org.jboss.tools.arquillian' declared in com.jboss.jbds.central.discovery.earlyaccess_8.0.0.Final_v20141017_1053_B366.jar_8432436156156296317.jar
> This occurs only in error log and has no impact on the installation.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBDS-3304) [unit test] versionwatch should run against latest builds, not hardcoded older Betas
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3304?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3304:
-----------------------------
CDW docs_ack: ?
CDW devel_ack: ?
CDW pm_ack: +
CDW qa_ack: ?
CDW release: ?
> [unit test] versionwatch should run against latest builds, not hardcoded older Betas
> ------------------------------------------------------------------------------------
>
> Key: JBDS-3304
> URL: https://issues.jboss.org/browse/JBDS-3304
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 8.0.1.GA
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> versionwatch should run against latest builds, not hardcoded older Betas.
> Need a way to pull the latest builds from /staging/ so that instead of testing hardcoded Beta2 builds we use the latest.
> This might have broken as a result of a bug in install.jbds.sh - I thought this used to work:
> {code}
> ++ TMPDIR=/tmp
> /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 151: unexpected EOF while looking for matching `"'
> /mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 152: syntax error: unexpected end of file
> {code}
> Either way, we need a better unit test here to ensure that the versions diffed are NOT just the list of hardcoded ones, but instead include the hardcoded list + at least one more (latest build).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBDS-3304) [unit test] versionwatch should run against latest builds, not hardcoded older Betas
by Nick Boldt (JIRA)
Nick Boldt created JBDS-3304:
--------------------------------
Summary: [unit test] versionwatch should run against latest builds, not hardcoded older Betas
Key: JBDS-3304
URL: https://issues.jboss.org/browse/JBDS-3304
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: build
Affects Versions: 8.0.1.GA
Reporter: Nick Boldt
Assignee: Nick Boldt
versionwatch should run against latest builds, not hardcoded older Betas.
Need a way to pull the latest builds from /staging/ so that instead of testing hardcoded Beta2 builds we use the latest.
This might have broken as a result of a bug in install.jbds.sh - I thought this used to work:
{code}
++ TMPDIR=/tmp
/mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 151: unexpected EOF while looking for matching `"'
/mnt/hudson_workspace/workspace/devstudio.versionwatch_8.0.luna/sources/vwatch/install.jbds.sh: command substitution: line 152: syntax error: unexpected end of file
{code}
Either way, we need a better unit test here to ensure that the versions diffed are NOT just the list of hardcoded ones, but instead include the hardcoded list + at least one more (latest build).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBDS-3303) [unit test] versionwatch should not fail silently when the report is empty
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3303?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3303:
-----------------------------
CDW docs_ack: ?
CDW devel_ack: ?
CDW pm_ack: +
CDW qa_ack: ?
CDW release: ?
> [unit test] versionwatch should not fail silently when the report is empty
> --------------------------------------------------------------------------
>
> Key: JBDS-3303
> URL: https://issues.jboss.org/browse/JBDS-3303
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 8.0.1.GA
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> versionwatch should not fail silently when the report is empty, such as:
> {code}
> JBDS Version Watch
> Feature list for filter = .*(hibernate\|jboss\|xulrunner).*
> Plugin list for filter = .*(hibernate\|jboss\|xulrunner).*
> Generated by VersionWatch 0.3.0 in 0 min, 4 sec at 2014-12-14 20:19:34.853.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (JBDS-3303) [unit test] versionwatch should not fail silently when the report is empty
by Nick Boldt (JIRA)
Nick Boldt created JBDS-3303:
--------------------------------
Summary: [unit test] versionwatch should not fail silently when the report is empty
Key: JBDS-3303
URL: https://issues.jboss.org/browse/JBDS-3303
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: build
Affects Versions: 8.0.1.GA
Reporter: Nick Boldt
Assignee: Nick Boldt
versionwatch should not fail silently when the report is empty, such as:
{code}
JBDS Version Watch
Feature list for filter = .*(hibernate\|jboss\|xulrunner).*
Plugin list for filter = .*(hibernate\|jboss\|xulrunner).*
Generated by VersionWatch 0.3.0 in 0 min, 4 sec at 2014-12-14 20:19:34.853.
{code}
--
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 Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18764?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-18764:
-------------------------------------
haven't retried in a while
> 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