resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] request: can we publish source artifacts to the maven repo

[Martin A. <sp...@ma...>]

And I'm confused - looking at the parent pom.xml it looks like the  
stuff you suggest below is already there.

M

On 9 Jul 2008, at 09:11, Martin Algesten wrote:

>
> Hi Adam,
>
> Are you running against "released" beta versions or building your  
> own jar from the source tree? I'm about to sort out releases using  
> the maven-release-plugin which means the source code would be  
> bundled anyway - doesn't help if you're compiling your own though.
>
> M
>
> On 9 Jul 2008, at 03:04, Adam Jordens wrote:
>
>> Essentially I’m asking if we can add the maven-source-plugin to the  
>> resteasy-jaxrs-all parent artifact POM.
>>
>> Something similar to the following would probably suffice:
>>
>> <plugin>
>>   <groupId>org.apache.maven.plugins</groupId>
>>   <artifactId>maven-source-plugin</artifactId>
>>   <version>2.0.2</version>
>>   <executions>
>>     <execution>
>>       <goals>
>>         <goal>jar</goal>
>>       </goals>
>>     </execution>
>>   </executions>
>> </plugin>
>>
>> It’s always nice to be able to debug with source code in your IDE  
>> (IntelliJ in my case) and this helps automate that.
>>
>>
>> Cheers,
>> Adam
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic  
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] stale?

[Martin A. <sp...@ma...>]

I assume the source tree of interest is completely under:

https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs

and the other stuff under

https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk

is just old? (resteasy-mom, resteasy-resourcemanager etc etc)

M

Re: [Resteasy-developers] request: can we publish source artifacts to the maven repo

[Martin A. <sp...@ma...>]

Hi Adam,

Are you running against "released" beta versions or building your own  
jar from the source tree? I'm about to sort out releases using the  
maven-release-plugin which means the source code would be bundled  
anyway - doesn't help if you're compiling your own though.

M

On 9 Jul 2008, at 03:04, Adam Jordens wrote:

> Essentially I’m asking if we can add the maven-source-plugin to the  
> resteasy-jaxrs-all parent artifact POM.
>
> Something similar to the following would probably suffice:
>
> <plugin>
>   <groupId>org.apache.maven.plugins</groupId>
>   <artifactId>maven-source-plugin</artifactId>
>   <version>2.0.2</version>
>   <executions>
>     <execution>
>       <goals>
>         <goal>jar</goal>
>       </goals>
>     </execution>
>   </executions>
> </plugin>
>
> It’s always nice to be able to debug with source code in your IDE  
> (IntelliJ in my case) and this helps automate that.
>
>
> Cheers,
> Adam
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Martin A. <sp...@ma...>]

On 9 Jul 2008, at 00:35, Bill Burke wrote:

> Martin, couple problems with your commit:
>
> 1) You broke other tests that depended on 400.  Please run whole  
> testsuite next time, thanks.

Uhm, no?!

I did run the whole test suite and it goes through fine - unless I've  
misunderstood how to run it (see below).

> 2) I believe, after looking at those broken tests, that I ported the  
> test from Jersey's testsuite.  This means that we might have to  
> change the behavior back to the way it was.  We'll see what happens  
> with the TCK.

  Yes, the tests are amended from 400 to 404 - happy to change that  
back. But then we go back to what is the wanted behaviour? (see  
previous email)


queen$ svn up
At revision 251.
queen$ svn st
queen$ mvn clean test
[INFO]  
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]  
------------------------------------------------------------------------
[INFO] Resteasy JAX-RS ....................................... SUCCESS  
[0.462s]
[INFO] JAX-RS Core API ....................................... SUCCESS  
[1.252s]
[INFO] RESTEasy JAX-RS Common Implementation ................. SUCCESS  
[0.026s]
[INFO] RESTEasy JAX-RS Implementation ........................ SUCCESS  
[7.167s]
[INFO] Resteasy JAX-RS Template Webapp ....................... SUCCESS  
[0.206s]
[INFO] Resteasy JAX-RS Distribution .......................... SUCCESS  
[0.081s]
[INFO] RESTEast JAX-RS Client ................................ SUCCESS  
[0.023s]
[INFO]  
------------------------------------------------------------------------
[INFO]  
------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL

[Resteasy-developers] request: can we publish source artifacts to the maven repo

[Adam J. <Ada...@ge...>]

Essentially I¹m asking if we can add the maven-source-plugin to the
resteasy-jaxrs-all parent artifact POM.

Something similar to the following would probably suffice:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-source-plugin</artifactId>
  <version>2.0.2</version>
  <executions>
    <execution>
      <goals>
        <goal>jar</goal>
      </goals>
    </execution>
  </executions>
</plugin>

It¹s always nice to be able to debug with source code in your IDE (IntelliJ
in my case) and this helps automate that.


Cheers,
Adam

[Resteasy-developers] ExceptionMapper + exceptions from an EJB invocation

[Adam J. <Ada...@ge...>]

Here¹s the situation.

I¹ve got a resource implemented as a Stateless EJB (exposed via a Seam
application but that¹s neither here nor there).

@Stateless
@Local(SpecimensClient.class)
@Name("specimens")
@Path("/rest/specimens")
public class SpecimensBean implements SpecimensClient, Serializable
{
    public ExtSpecimen getSpecimen(Long id)
    {
        try
        {
            Specimen specimen = (Specimen)
                    em.createQuery("XYZ").getSingleResult();

            ...    
            return extSpecimen;
        }
        catch (NoResultException e)
        {
            throw new
WebApplicationException(HttpURLConnection.HTTP_NOT_FOUND);
        }
    }
}

Now accessing that resource with an invalid id is resulting in the
WebApplicationException getting thrown.  However instead of it propagating
up as a InvocationTargetException with the WebApplicationException as it¹s
cause, the InvocationTargetException is wrapping an EJBException which in
turn is wrapping the WebApplicationException.

What¹s the opinion on the best way to handle this, short of having to
implement a @Provider to do the unwrapping of the EJBException myself (which
does seem to work).


Kind Regards,
Adam  

[Resteasy-developers] AsychronousDispatcher.java vs AsynchronousDispatcher.java

[Ryan J. M. <ry...@da...>]

I just did an update and found that is both a  
AsychronousDispatcher.java and a AsynchronousDispatcher.java. The SVN  
repo confirm it as of version 250:

http://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/

I assume that was a refactoring and somehow the older version  
(AsychronousDispatcher.java ) stuck around. If that's the case, I'll  
delete it.

Just FYI, I ran into similar issues doing the major refactoring on the  
3rd, it was a real pain. The original files were not removed from the  
repo on a refactor and the subsequent update ended up having both  
package names.

Ryan-

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Bill B. <bb...@re...>]

Martin, couple problems with your commit:

1) You broke other tests that depended on 400.  Please run whole 
testsuite next time, thanks.

2) I believe, after looking at those broken tests, that I ported the 
test from Jersey's testsuite.  This means that we might have to change 
the behavior back to the way it was.  We'll see what happens with the TCK.

Bill Burke wrote:
> Would be cool to have a regression unit test that duplicates the 
> problems you and ryan are seeing too.
> 
> Bill Burke wrote:
>> Change the code to check for Failure (if it doesn't already) and rethrow 
>> that.
>>
>> Martin Algesten wrote:
>>> In ResourceMethod.invoke() line 153, there's a try-catch that makes  
>>> all Failure exceptions thrown below be translated to 400. Is this  
>>> deliberate? To make NumberFormatException result in 404 I want to pass  
>>> my error code in the Failure exception, and then get that set in the  
>>> response.
>>>
>>> I've checked in a change where we always set the error code passed in  
>>> the Failure - it looks reasonable.
>>>
>>> Martin
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] module refactor?

[Bill B. <bb...@re...>]

So when do you all want me to do the module refactor?   (move stuff into 
client/common etc...)
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] New commiter: Mark Little

[Mark L. <mar...@go...>]

Thanks and it's good to join. For my sins I'm a co-author on quite a  
few WS-* specs, but I seem to be doing pretty well in rehab these  
days ;-)

Mark.


On 8 Jul 2008, at 13:50, Bill Burke wrote:

> Mark Little is interesting in helping a bit on Resteasy.  Mark runs
> JBoss's SOA platform and is "The God of Transactions".  We're planning
> on eventually getting some code/work around DTX and business  
> activity in
> a REST environment.  Don't know which parts of this will be part of
> RESTEasy or not, but, it should be some interesting work to plug up
> where REST in general is weak.
>
> Bill
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Martin A. <sp...@ma...>]

Can't close the JIRA bug though :/

On 8 Jul 2008, at 17:30, Martin Algesten wrote:

>
> Just checked in a fix for RESTEASY-63 together with two test cases
> that ensure that MessageBodyReader and MessageBodyWriter can both
> throw WebApplicationException with response codes through to the
> HttpServletResponse.
>
> This fixes RESTEASY-63 - I re-enabled Ryan's proper check.
>
> M
>
> On 8 Jul 2008, at 14:33, Bill Burke wrote:
>
>> Would be cool to have a regression unit test that duplicates the
>> problems you and ryan are seeing too.
>>
>> Bill Burke wrote:
>>> Change the code to check for Failure (if it doesn't already) and
>>> rethrow that.
>>> Martin Algesten wrote:
>>>> In ResourceMethod.invoke() line 153, there's a try-catch that
>>>> makes  all Failure exceptions thrown below be translated to 400.
>>>> Is this  deliberate? To make NumberFormatException result in 404 I
>>>> want to pass  my error code in the Failure exception, and then get
>>>> that set in the  response.
>>>>
>>>> I've checked in a change where we always set the error code passed
>>>> in  the Failure - it looks reasonable.
>>>>
>>>> Martin
>>>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Martin A. <sp...@ma...>]

Just checked in a fix for RESTEASY-63 together with two test cases  
that ensure that MessageBodyReader and MessageBodyWriter can both  
throw WebApplicationException with response codes through to the  
HttpServletResponse.

This fixes RESTEASY-63 - I re-enabled Ryan's proper check.

M

On 8 Jul 2008, at 14:33, Bill Burke wrote:

> Would be cool to have a regression unit test that duplicates the  
> problems you and ryan are seeing too.
>
> Bill Burke wrote:
>> Change the code to check for Failure (if it doesn't already) and  
>> rethrow that.
>> Martin Algesten wrote:
>>> In ResourceMethod.invoke() line 153, there's a try-catch that  
>>> makes  all Failure exceptions thrown below be translated to 400.  
>>> Is this  deliberate? To make NumberFormatException result in 404 I  
>>> want to pass  my error code in the Failure exception, and then get  
>>> that set in the  response.
>>>
>>> I've checked in a change where we always set the error code passed  
>>> in  the Failure - it looks reasonable.
>>>
>>> Martin
>>>

Re: [Resteasy-developers] Providers and Future Bloat

[Bill B. <bb...@re...>]

Maybe a separate download/distro for optional providers?

Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I had a few more ideas for some other provider types and I realized  
> that if we're not carful about, we could get fat really quickly.  
> Here's a few provider ideas that Bill and I tossed around on this list:
> 
> POI provider
> SVG Provider
> PGP/GPG Provider
> 
> Given these 3 alone, we now have dependencies on the following projects:
> 
> Jakarta POI
> Apache Batik
> Bouncy Castle or other PGP api
> 
> It got me thinking: should we have an optional provider module(s)?  
> Personally, I don't care. I think we've have the value-add of tons of  
> kick-ass providers with no fuss, it wouldn't matter. But you know  
> inevitably, there'd be a TSS article or collection of blog posts about  
> how bloated RESTEasy is so bloated, yada yada yada. Does anyone else  
> think this is a potential issue that we may want to address sooner  
> than later?
> 
> Ryan-
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> 
> iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF
> CRyFIK8Gpu9B2FwzNs+vE+w=
> =fWJM
> -----END PGP SIGNATURE-----
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Logging Configuration Details

[Martin A. <sp...@ma...>]

On 8 Jul 2008, at 15:11, Ryan J. McDonough wrote:

>> 1) Needs to work out-of-the-box, no additional configuration, jars  
>> etc etc. log4j fails on the remarkably irritating lack of  
>> reasonable defaults (no logging out of the box). slf4j fails on  
>> requiring the presence of an implementation jar (would be much  
>> better if it defaulted to java.util.logging that could be  
>> overridden by dropping in a jar).
>
> True, but the same can be said of JCL too.

Haven't looked at JCL, but I take your word for it :)

>> 2) Needs to be non-intrusive. I don't want to sprinkle the class  
>> files with crud to get a logger in place. log4j does this nicely,  
>> Logger.getLogger( MyClass.class ) is all I need + the import. slf4j  
>> fails because of the factory pattern  
>> LoggerFactory.getLogger( MyClass.class ) + two imports (same goes  
>> for java.util.logging) - but then slf4j is a bit better than  
>> java.util.logging since the following construct in java is truly  
>> hideous:
>
> I can live with 2 import statements if it's easier to use.

I can live with 2 statements too - it just irritates me.

>> if ( logger.isLoggable( Level.FINE ) ) {
>> logger.fine( "Blah blah" );
>> }
>>
>> instead of
>>
>> if ( logger.isDebugEnabled() ) {
>> logger.debug( "Blah  blah" );
>> }
>
> Even better, slf4j supports parameterized messages such that:
>
> logger.debug("The new entry is {}.", entry);
>
> You don't need to check isDebugEnabled() as that is handled  
> internally. If debug is not enabled, the message will not be parsed.

Yeah, I like that, and in my wrappers I always implemented that myself  
using java.text.MessageFormat. I guess my main concern with slf4j is  
that to get it working out-of-the-box we need to hard link to one  
implementation jar - and whichever we chose it's going to be the wrong  
one for someone.

M

Re: [Resteasy-developers] Logging Configuration Details

[Ryan J. M. <ry...@da...>]

On Jul 8, 2008, at 8:59 AM, Martin Algesten wrote:

>
> (posting from another thread)
>
> On 8 Jul 2008, at 14:31, Ryan J. McDonough wrote:
>
>>> Btw I also made sl4j-log4j dependency optional since I hate log4j  
>>> with
>>> a passion, and depending on resteasy currently pulled that crud into
>>> my project.
>>
>> But do you share the same hatred of slf4j? I agree we should not  
>> impose the log4j on any one, but I'm still partial to including  
>> slf4j so that a log4j or other provider is optional but RESTEasy  
>> logging details are written to the log of their choice. If folks  
>> just simply don't like the idea of slf4j, we can yank it, but then  
>> again I hate JDK logging and System.out with a passion ;) Thoughts?
>
> I agree we want logging and no System.out. My criteria for good  
> logging is:
>
> 1) Needs to work out-of-the-box, no additional configuration, jars  
> etc etc. log4j fails on the remarkably irritating lack of reasonable  
> defaults (no logging out of the box). slf4j fails on requiring the  
> presence of an implementation jar (would be much better if it  
> defaulted to java.util.logging that could be overridden by dropping  
> in a jar).

True, but the same can be said of JCL too.

>
>
> 2) Needs to be non-intrusive. I don't want to sprinkle the class  
> files with crud to get a logger in place. log4j does this nicely,  
> Logger.getLogger( MyClass.class ) is all I need + the import. slf4j  
> fails because of the factory pattern  
> LoggerFactory.getLogger( MyClass.class ) + two imports (same goes  
> for java.util.logging) - but then slf4j is a bit better than  
> java.util.logging since the following construct in java is truly  
> hideous:

I can live with 2 import statements if it's easier to use.

> if ( logger.isLoggable( Level.FINE ) ) {
> logger.fine( "Blah blah" );
> }
>
> instead of
>
> if ( logger.isDebugEnabled() ) {
> logger.debug( "Blah  blah" );
> }

Even better, slf4j supports parameterized messages such that:

logger.debug("The new entry is {}.", entry);

You don't need to check isDebugEnabled() as that is handled  
internally. If debug is not enabled, the message will not be parsed.


> Bottom line is that I think all logging framework suck. In previous  
> projects I've always preferred just making a small wrapper class  
> local to the project. It defaults to using java.util.logging to  
> satisfy the out-of-the-box criteria. Generally only bigger projects  
> really require all their logging to conform, which means they can  
> spend the effort tweaking my wrapper to do what it needs to.
>

They do all suck, but some suck less can do the job better than others.

> M
>
>
>

Re: [Resteasy-developers] Providers and Future Bloat

[Martin A. <sp...@ma...>]

It's nice to have the extras. But I'd like to see them in a separate  
jar. The main jar should imo just be a bare bones JAX-RS implementation.

M

On 8 Jul 2008, at 15:02, Ryan J. McDonough wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I had a few more ideas for some other provider types and I realized
> that if we're not carful about, we could get fat really quickly.
> Here's a few provider ideas that Bill and I tossed around on this  
> list:
>
> POI provider
> SVG Provider
> PGP/GPG Provider
>
> Given these 3 alone, we now have dependencies on the following  
> projects:
>
> Jakarta POI
> Apache Batik
> Bouncy Castle or other PGP api
>
> It got me thinking: should we have an optional provider module(s)?
> Personally, I don't care. I think we've have the value-add of tons of
> kick-ass providers with no fuss, it wouldn't matter. But you know
> inevitably, there'd be a TSS article or collection of blog posts about
> how bloated RESTEasy is so bloated, yada yada yada. Does anyone else
> think this is a potential issue that we may want to address sooner
> than later?
>
> Ryan-
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF
> CRyFIK8Gpu9B2FwzNs+vE+w=
> =fWJM
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] New commiter: Mark Little

[Mark L. <ml...@re...>]

Thanks and it's good to join. For my sins I'm a co-author on quite a  
few WS-* specs, but I seem to be doing pretty well in rehab these  
days ;-)

Mark.


On 8 Jul 2008, at 13:50, Bill Burke wrote:

> Mark Little is interesting in helping a bit on Resteasy.  Mark runs
> JBoss's SOA platform and is "The God of Transactions".  We're planning
> on eventually getting some code/work around DTX and business  
> activity in
> a REST environment.  Don't know which parts of this will be part of
> RESTEasy or not, but, it should be some interesting work to plug up
> where REST in general is weak.
>
> Bill
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

----
Mark Little
ml...@re...

JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod  
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903  
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt  
Parsons (USA) and Brendan Lane (Ireland).

[Resteasy-developers] Providers and Future Bloat

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had a few more ideas for some other provider types and I realized  
that if we're not carful about, we could get fat really quickly.  
Here's a few provider ideas that Bill and I tossed around on this list:

POI provider
SVG Provider
PGP/GPG Provider

Given these 3 alone, we now have dependencies on the following projects:

Jakarta POI
Apache Batik
Bouncy Castle or other PGP api

It got me thinking: should we have an optional provider module(s)?  
Personally, I don't care. I think we've have the value-add of tons of  
kick-ass providers with no fuss, it wouldn't matter. But you know  
inevitably, there'd be a TSS article or collection of blog posts about  
how bloated RESTEasy is so bloated, yada yada yada. Does anyone else  
think this is a potential issue that we may want to address sooner  
than later?

Ryan-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF
CRyFIK8Gpu9B2FwzNs+vE+w=
=fWJM
-----END PGP SIGNATURE-----

Re: [Resteasy-developers] Logging Configuration Details

[Martin A. <sp...@ma...>]

(posting from another thread)

On 8 Jul 2008, at 14:31, Ryan J. McDonough wrote:

>> Btw I also made sl4j-log4j dependency optional since I hate log4j  
>> with
>> a passion, and depending on resteasy currently pulled that crud into
>> my project.
>
> But do you share the same hatred of slf4j? I agree we should not  
> impose the log4j on any one, but I'm still partial to including  
> slf4j so that a log4j or other provider is optional but RESTEasy  
> logging details are written to the log of their choice. If folks  
> just simply don't like the idea of slf4j, we can yank it, but then  
> again I hate JDK logging and System.out with a passion ;) Thoughts?

I agree we want logging and no System.out. My criteria for good  
logging is:

1) Needs to work out-of-the-box, no additional configuration, jars etc  
etc. log4j fails on the remarkably irritating lack of reasonable  
defaults (no logging out of the box). slf4j fails on requiring the  
presence of an implementation jar (would be much better if it  
defaulted to java.util.logging that could be overridden by dropping in  
a jar).

2) Needs to be non-intrusive. I don't want to sprinkle the class files  
with crud to get a logger in place. log4j does this nicely,  
Logger.getLogger( MyClass.class ) is all I need + the import. slf4j  
fails because of the factory pattern  
LoggerFactory.getLogger( MyClass.class ) + two imports (same goes for  
java.util.logging) - but then slf4j is a bit better than  
java.util.logging since the following construct in java is truly  
hideous:

if ( logger.isLoggable( Level.FINE ) ) {
  logger.fine( "Blah blah" );
}

instead of

if ( logger.isDebugEnabled() ) {
  logger.debug( "Blah  blah" );
}

Bottom line is that I think all logging framework suck. In previous  
projects I've always preferred just making a small wrapper class local  
to the project. It defaults to using java.util.logging to satisfy the  
out-of-the-box criteria. Generally only bigger projects really require  
all their logging to conform, which means they can spend the effort  
tweaking my wrapper to do what it needs to.

M

Re: [Resteasy-developers] Logging Configuration Details

[Ryan J. M. <ry...@da...>]

On Jul 8, 2008, at 8:53 AM, Bill Burke wrote:

>
>
> Ryan J. McDonough wrote:
>> I know you're not a fan of logging, but logging can work.
>
> Yeah, I know...Users find it very useful (I personally do not) and  
> whatever users want, users get...  I don't know anything about  
> slf4j, but if the backend is pluggable, I"m all for it.

Yes, it's pluggable and it has nicer syntax than any of the others,  
IMHO.

>
>
> Thanks for putting this together.  I wouldn't have done it and we  
> needed it...

My pleasure.

>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

Re: [Resteasy-developers] Logging Configuration Details

[Bill B. <bb...@re...>]

Ryan J. McDonough wrote:
> I know you're not a fan of logging, but logging can work.

Yeah, I know...Users find it very useful (I personally do not) and 
whatever users want, users get...  I don't know anything about slf4j, 
but if the backend is pluggable, I"m all for it.

Thanks for putting this together.  I wouldn't have done it and we needed 
it...

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] New commiter: Mark Little

[Bill B. <bb...@re...>]

Mark Little is interesting in helping a bit on Resteasy.  Mark runs 
JBoss's SOA platform and is "The God of Transactions".  We're planning 
on eventually getting some code/work around DTX and business activity in 
a REST environment.  Don't know which parts of this will be part of 
RESTEasy or not, but, it should be some interesting work to plug up 
where REST in general is weak.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Logging Configuration Details

[Ryan J. M. <ry...@da...>]

I knew that ;) It has something similar to commons-logging. JBoss AS 5  
includes a provider for slf4j so I felt it was a safe choice. I didn't  
want to get into making the decision of using log4j or jdk logging,  
but at least something that can provide logging details. My desire is  
to keep slf4j, drop log4j as a dependency (as Martin already did) and  
use JDK logging as the default. Developers are free to choose whatever  
framework suits them. Or can we use jboss-logging?

I know you're not a fan of logging, but logging can work. The logging  
details from Hibernate have saved my ass a number of times because  
they provided enough detail of what is going on when. I'd like to be  
able to offer the same.

Ryan-

On Jul 8, 2008, at 8:34 AM, Bill Burke wrote:

> FYI, JBoss does have a pluggable logging abstraction.
>
> Ryan McDonough wrote:
>> I can see your point, but I do respectfully disagree. The idea  
>> behind it was to offer choice to end users on logging frameworks. I  
>> didn't want people to have to manage 2 different logging  
>> configurations just to get at the log messages from RESTEasy. If  
>> I'm using JBoss AS, I'm most likely going to be using log4j, but if  
>> I'm running stand alone, maybe JDK logging will be sufficient. I've  
>> also not been much of a fan of JDK logging since configuration is  
>> kind of a pain. I've used log4j frequently, but I don't want to  
>> impose that restriction onto anyone else, which was the reason  
>> behind slf4j.
>> On a related note, from a framework debugging perspective, I'd like  
>> to be able to offer detailed information available to developers,  
>> much the same way Hibernate does it:
>> http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/hibernate/Hibernate_Reference_Guide/Configuration-Logging.html
>> and how it's done in JBoss AS:
>> http://docs.jboss.org/process-guide/en/html/logging.html
>> I'd like to be able to offer the same level of details going  
>> forward. This is what the LoggingCategories class.
>> Ryan-
>> On Mon, Jul 7, 2008 at 10:03 AM, Bill Burke <bb...@re... <mailto:bb...@re... 
>> >> wrote:
>>    -1 on slf4j.  I'm so sick of these shitty logging frameworks and  
>> the
>>    dependency problems and bloat problems they create.  Let's use JDK
>>    logging instead.  Its good enough for what we want to do.
>>    Ryan J. McDonough wrote:
>>        -----BEGIN PGP SIGNED MESSAGE-----
>>        Hash: SHA1
>>        Since we didn't have logging in RESTEasy I introduced the  
>> slf4j
>>         logging API to the project over the weekend. I have put the
>>        following  wiki page up here to detail some of the changes:
>>        http://wiki.jboss.org/wiki/RESTEasyLogging
>>        Going forward, I'd like to see logging instead of  
>> System.out ;)
>>        Ryan-
>>        -----BEGIN PGP SIGNATURE-----
>>        Version: GnuPG v1.4.7 (Darwin)
>>        iD8DBQFIcYdHK/xjmUY6JwURAl9iAJ453Bq+zrfPUvsmUgO83CaCmJ/9/ 
>> ACfTDGm
>>        18+LjZ87CRYVgDJtkO5djKM=
>>        =hKND
>>        -----END PGP SIGNATURE-----
>>         
>> -------------------------------------------------------------------------
>>        Sponsored by: SourceForge.net Community Choice Awards: VOTE  
>> NOW!
>>        Studies have shown that voting for your favorite open source
>>        project,
>>        along with a healthy diet, reduces your potential for chronic
>>        lameness
>>        and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>        _______________________________________________
>>        Resteasy-developers mailing list
>>        Res...@li...
>>        <mailto:Res...@li...>
>>        https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>    --     Bill Burke
>>    JBoss, a division of Red Hat
>>    http://bill.burkecentral.com <http://bill.burkecentral.com/>
>> -- 
>> Ryan J. McDonough
>> http://www.damnhandy.com
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

Re: [Resteasy-developers] Logging Configuration Details

[Bill B. <bb...@re...>]

FYI, JBoss does have a pluggable logging abstraction.

Ryan McDonough wrote:
> I can see your point, but I do respectfully disagree. The idea behind it 
> was to offer choice to end users on logging frameworks. I didn't want 
> people to have to manage 2 different logging configurations just to get 
> at the log messages from RESTEasy. If I'm using JBoss AS, I'm most 
> likely going to be using log4j, but if I'm running stand alone, maybe 
> JDK logging will be sufficient. I've also not been much of a fan of JDK 
> logging since configuration is kind of a pain. I've used log4j 
> frequently, but I don't want to impose that restriction onto anyone 
> else, which was the reason behind slf4j.
> 
>  
> 
> On a related note, from a framework debugging perspective, I'd like to 
> be able to offer detailed information available to developers, much the 
> same way Hibernate does it:
> 
>  
> 
> http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/hibernate/Hibernate_Reference_Guide/Configuration-Logging.html
> 
>  
> 
> and how it's done in JBoss AS:
> 
>  
> 
> http://docs.jboss.org/process-guide/en/html/logging.html
> 
>  
> 
> I'd like to be able to offer the same level of details going forward. 
> This is what the LoggingCategories class.
> 
>  
> 
> Ryan-
> 
> 
> 
> On Mon, Jul 7, 2008 at 10:03 AM, Bill Burke <bb...@re... 
> <mailto:bb...@re...>> wrote:
> 
>     -1 on slf4j.  I'm so sick of these shitty logging frameworks and the
>     dependency problems and bloat problems they create.  Let's use JDK
>     logging instead.  Its good enough for what we want to do.
> 
>     Ryan J. McDonough wrote:
> 
>         -----BEGIN PGP SIGNED MESSAGE-----
>         Hash: SHA1
> 
>         Since we didn't have logging in RESTEasy I introduced the slf4j
>          logging API to the project over the weekend. I have put the
>         following  wiki page up here to detail some of the changes:
> 
>         http://wiki.jboss.org/wiki/RESTEasyLogging
> 
>         Going forward, I'd like to see logging instead of System.out ;)
> 
>         Ryan-
>         -----BEGIN PGP SIGNATURE-----
>         Version: GnuPG v1.4.7 (Darwin)
> 
>         iD8DBQFIcYdHK/xjmUY6JwURAl9iAJ453Bq+zrfPUvsmUgO83CaCmJ/9/ACfTDGm
>         18+LjZ87CRYVgDJtkO5djKM=
>         =hKND
>         -----END PGP SIGNATURE-----
> 
>         -------------------------------------------------------------------------
>         Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>         Studies have shown that voting for your favorite open source
>         project,
>         along with a healthy diet, reduces your potential for chronic
>         lameness
>         and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>         _______________________________________________
>         Resteasy-developers mailing list
>         Res...@li...
>         <mailto:Res...@li...>
>         https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com <http://bill.burkecentral.com/>
> 
> 
> 
> 
> -- 
> Ryan J. McDonough
> http://www.damnhandy.com

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] bad pom.xml version property

[Ryan J. M. <ry...@da...>]

On Jul 8, 2008, at 7:21 AM, Martin Algesten wrote:

>
> In parent pom.xml we define:
>
>         <properties>
>                 <resteasy.version>1.0-beta-6</resteasy.version>
>         </properties>
>
> - and this property is then used wherever the version is needed.
> Superficially this may look like it works, but it won't. The maven
> pom.xml often exist outside a context where the property definition
> will work. For my local test project I have dependency on the child
> project such as:
>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-jaxrs</artifactId>
>       <version>1.0-beta-6</version>
>     </dependency>
>
> And I don't define <resteasy.version> anywhere. This results in:
>
> Downloading: http://repo1.maven.org/maven2//org/jboss/resteasy/resteasy-jaxrs-all/$
> {resteasy.version}/resteasy-jaxrs-all-${resteasy.version}.pom

Yeah, I see the same thing but only when I try an build my address  
book example app.

>
> and eventually an error that it can't find the dependency.
>
> The reason this works in the /examples is that the exact property
> <resteasy.version> has been defined there as well, hence maven
> resolves it - but we can't require every project linking to resteasy
> to define this property.

Well also the 1.0-beta-6 isn't deployed to any repo yet either.
>
>
> The solution is unfortunately to duplicate the version of the parent
> pom around endlessly - however this is where the release plugin I
> talked about earlier comes in handy. If we can get the project to work
> with that plugin, it will help us maintain/update these versions as we
> move forward.

+1 on the release plugin and I've been thinking the same thing. I've  
used it many times and it solves the problem of having to update the  
project version manually. Plus, it does all that nice tagging and  
such ;)

>
>
> I've refactored the pom versions to use the standard maven behaviour
> of inheriting parent pom version and use ${project.version} for
> relationships between child modules - so for now releasing means
> editing the parent versions manually.

If we only have to do it once, I'm ok with that.

> Happy to work on the release plugin if you agree this is the way
> forward.

+1 here. I think it makes the whole process easier.
>
>
> Btw I also made sl4j-log4j dependency optional since I hate log4j with
> a passion, and depending on resteasy currently pulled that crud into
> my project.

But do you share the same hatred of slf4j? I agree we should not  
impose the log4j on any one, but I'm still partial to including slf4j  
so that a log4j or other provider is optional but RESTEasy logging  
details are written to the log of their choice. If folks just simply  
don't like the idea of slf4j, we can yank it, but then again I hate  
JDK logging and System.out with a passion ;) Thoughts?

BTW, Martin, good to have you on board!

Ryan-

>
>
> M
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers