-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We have a task to get better exception handling from the API and the client. We'd like to have better error messages and possibly error codes, as well as json serializable.
Today we throw the following exceptions:
ForbiddenException - thrown from ConsumerResource NotFoundException - thrown from a few Resources BadRequestException - thrown from almost all Resources WebApplicationException (parent to the above) - called directly
The above exceptions extend WebApplicationException and for the return type to be "text/plain", which means you can't parse it as JSON on the client side. This is odd since all other responses are in JSON, it would be nice to be consistent. Sadly it isn't enough to leave off the type call as it will default to text/plain.
In order to get it serializable the thought is to create a class to be used as the payload for the Exceptions, say something like ExceptionMessage. This class will be annotated with JAXB objects and can be used to return as JSON or XML based on the Accept header, just like the other API calls do.
The thought is to have it contain the following:
* error code - int * label - string * display message - string (i18n probably)
We may not need the error code since the HTTP codes might be enough, then we'd just need to have decent message strings.
HTTP status codes - http://en.wikipedia.org/wiki/List_of_HTTP_status_codes ResponseStatus javadoc - http://bit.ly/aMhkkM
Now on the exception side, we can continue to create wrapper exceptions like BadRequestException OR we could use standard exceptions and use the RESTeasy ExceptionMapper to map a standard exception to a proper Response code. I personally like the wrapper exceptions since it makes it more explicit, then use the ExceptionMapper for a final catchall like NullPointerException, and other gross things that we might want to offer a nicer error message to easy the pain :)
All in all the main key is to identify better error messages that the client can use and make it consistent for Resource developers.
jesus
- -- jesus m. rodriguez | jesusr@redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+
On 04/07/2010 05:34 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We have a task to get better exception handling from the API and the client. We'd like to have better error messages and possibly error codes, as well as json serializable.
Today we throw the following exceptions:
ForbiddenException - thrown from ConsumerResource NotFoundException - thrown from a few Resources BadRequestException - thrown from almost all Resources WebApplicationException (parent to the above) - called directly
The above exceptions extend WebApplicationException and for the return type to be "text/plain", which means you can't parse it as JSON on the client side. This is odd since all other responses are in JSON, it would be nice to be consistent. Sadly it isn't enough to leave off the type call as it will default to text/plain.
In order to get it serializable the thought is to create a class to be used as the payload for the Exceptions, say something like ExceptionMessage. This class will be annotated with JAXB objects and can be used to return as JSON or XML based on the Accept header, just like the other API calls do.
The thought is to have it contain the following:
- error code - int
- label - string
- display message - string (i18n probably)
We may not need the error code since the HTTP codes might be enough, then we'd just need to have decent message strings.
If we do have an error code internally, we would need a way to map that to http error code. I would be all for label/string and pick the correct status code you want. If the labels are unique, it may be the same as the error code.
HTTP status codes - http://en.wikipedia.org/wiki/List_of_HTTP_status_codes ResponseStatus javadoc - http://bit.ly/aMhkkM
Now on the exception side, we can continue to create wrapper exceptions like BadRequestException OR we could use standard exceptions and use the RESTeasy ExceptionMapper to map a standard exception to a proper Response code. I personally like the wrapper exceptions since it makes it more explicit, then use the ExceptionMapper for a final catchall like NullPointerException, and other gross things that we might want to offer a nicer error message to easy the pain :)
+1
All in all the main key is to identify better error messages that the client can use and make it consistent for Resource developers.
Just thinking ahead, how would validation error fit into this? Would it be a 406, with label of "validation_failed" and the message would be the items whic hfailed? Or.. would we have a one-off validation_Exception?
-- bk
On 04/08/2010 09:31 AM, Bryan Kearney wrote:
On 04/07/2010 05:34 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We have a task to get better exception handling from the API and the client. We'd like to have better error messages and possibly error codes, as well as json serializable.
Today we throw the following exceptions:
ForbiddenException - thrown from ConsumerResource NotFoundException - thrown from a few Resources BadRequestException - thrown from almost all Resources WebApplicationException (parent to the above) - called directly
The above exceptions extend WebApplicationException and for the return type to be "text/plain", which means you can't parse it as JSON on the client side. This is odd since all other responses are in JSON, it would be nice to be consistent. Sadly it isn't enough to leave off the type call as it will default to text/plain.
In order to get it serializable the thought is to create a class to be used as the payload for the Exceptions, say something like ExceptionMessage. This class will be annotated with JAXB objects and can be used to return as JSON or XML based on the Accept header, just like the other API calls do.
The thought is to have it contain the following:
- error code - int
- label - string
- display message - string (i18n probably)
We may not need the error code since the HTTP codes might be enough, then we'd just need to have decent message strings.
If we do have an error code internally, we would need a way to map that to http error code. I would be all for label/string and pick the correct status code you want. If the labels are unique, it may be the same as the error code.
HTTP status codes - http://en.wikipedia.org/wiki/List_of_HTTP_status_codes ResponseStatus javadoc - http://bit.ly/aMhkkM
Now on the exception side, we can continue to create wrapper exceptions like BadRequestException OR we could use standard exceptions and use the RESTeasy ExceptionMapper to map a standard exception to a proper Response code. I personally like the wrapper exceptions since it makes it more explicit, then use the ExceptionMapper for a final catchall like NullPointerException, and other gross things that we might want to offer a nicer error message to easy the pain :)
+1
All in all the main key is to identify better error messages that the client can use and make it consistent for Resource developers.
Just thinking ahead, how would validation error fit into this? Would it be a 406, with label of "validation_failed" and the message would be the items whic hfailed? Or.. would we have a one-off validation_Exception?
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
In addition to the error codes, can't we provide custom error pages, that could potentially be straight JSON, with the error info in a standard format?
On 10-04-08 10:58 AM, Adam Young wrote:
On 04/08/2010 09:31 AM, Bryan Kearney wrote:
On 04/07/2010 05:34 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We have a task to get better exception handling from the API and the client. We'd like to have better error messages and possibly error codes, as well as json serializable.
Today we throw the following exceptions:
ForbiddenException - thrown from ConsumerResource NotFoundException - thrown from a few Resources BadRequestException - thrown from almost all Resources WebApplicationException (parent to the above) - called directly
The above exceptions extend WebApplicationException and for the return type to be "text/plain", which means you can't parse it as JSON on the client side. This is odd since all other responses are in JSON, it would be nice to be consistent. Sadly it isn't enough to leave off the type call as it will default to text/plain.
In order to get it serializable the thought is to create a class to be used as the payload for the Exceptions, say something like ExceptionMessage. This class will be annotated with JAXB objects and can be used to return as JSON or XML based on the Accept header, just like the other API calls do.
The thought is to have it contain the following:
- error code - int
- label - string
- display message - string (i18n probably)
We may not need the error code since the HTTP codes might be enough, then we'd just need to have decent message strings.
If we do have an error code internally, we would need a way to map that to http error code. I would be all for label/string and pick the correct status code you want. If the labels are unique, it may be the same as the error code.
HTTP status codes - http://en.wikipedia.org/wiki/List_of_HTTP_status_codes ResponseStatus javadoc - http://bit.ly/aMhkkM
Now on the exception side, we can continue to create wrapper exceptions like BadRequestException OR we could use standard exceptions and use the RESTeasy ExceptionMapper to map a standard exception to a proper Response code. I personally like the wrapper exceptions since it makes it more explicit, then use the ExceptionMapper for a final catchall like NullPointerException, and other gross things that we might want to offer a nicer error message to easy the pain :)
+1
All in all the main key is to identify better error messages that the client can use and make it consistent for Resource developers.
Just thinking ahead, how would validation error fit into this? Would it be a 406, with label of "validation_failed" and the message would be the items whic hfailed? Or.. would we have a one-off validation_Exception?
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
In addition to the error codes, can't we provide custom error pages, that could potentially be straight JSON, with the error info in a standard format?
i think content-type should take care of that? We could serialize exception information differently, depending on whether the client requests json or plan text (or xml).
-d
On Fri, Apr 9, 2010 at 9:32 AM, Dmitri Dolguikh dmitri@redhat.com wrote:
In addition to the error codes, can't we provide custom error pages, that could potentially be straight JSON, with the error info in a standard format?
i think content-type should take care of that? We could serialize exception information differently, depending on whether the client requests json or plan text (or xml).
+1 That's actually the intent.
jesus
Another thing to noodle.. we will want the user service to be able to throw exceptions with interesting messages at login time. Does the current approach allow the filters to throw exceptions.
-- bk
On 04/09/2010 09:32 AM, Dmitri Dolguikh wrote:
On 10-04-08 10:58 AM, Adam Young wrote:
On 04/08/2010 09:31 AM, Bryan Kearney wrote:
On 04/07/2010 05:34 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We have a task to get better exception handling from the API and the client. We'd like to have better error messages and possibly error codes, as well as json serializable.
Today we throw the following exceptions:
ForbiddenException - thrown from ConsumerResource NotFoundException - thrown from a few Resources BadRequestException - thrown from almost all Resources WebApplicationException (parent to the above) - called directly
The above exceptions extend WebApplicationException and for the return type to be "text/plain", which means you can't parse it as JSON on the client side. This is odd since all other responses are in JSON, it would be nice to be consistent. Sadly it isn't enough to leave off the type call as it will default to text/plain.
In order to get it serializable the thought is to create a class to be used as the payload for the Exceptions, say something like ExceptionMessage. This class will be annotated with JAXB objects and can be used to return as JSON or XML based on the Accept header, just like the other API calls do.
The thought is to have it contain the following:
- error code - int
- label - string
- display message - string (i18n probably)
We may not need the error code since the HTTP codes might be enough, then we'd just need to have decent message strings.
If we do have an error code internally, we would need a way to map that to http error code. I would be all for label/string and pick the correct status code you want. If the labels are unique, it may be the same as the error code.
HTTP status codes - http://en.wikipedia.org/wiki/List_of_HTTP_status_codes ResponseStatus javadoc - http://bit.ly/aMhkkM
Now on the exception side, we can continue to create wrapper exceptions like BadRequestException OR we could use standard exceptions and use the RESTeasy ExceptionMapper to map a standard exception to a proper Response code. I personally like the wrapper exceptions since it makes it more explicit, then use the ExceptionMapper for a final catchall like NullPointerException, and other gross things that we might want to offer a nicer error message to easy the pain :)
+1
All in all the main key is to identify better error messages that the client can use and make it consistent for Resource developers.
Just thinking ahead, how would validation error fit into this? Would it be a 406, with label of "validation_failed" and the message would be the items whic hfailed? Or.. would we have a one-off validation_Exception?
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
In addition to the error codes, can't we provide custom error pages, that could potentially be straight JSON, with the error info in a standard format?
i think content-type should take care of that? We could serialize exception information differently, depending on whether the client requests json or plan text (or xml).
-d
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
I committed the first cut of parseable exceptions. The 'interesting' parts:
CandlepinExceptionMapper.java - the bit that maps exceptions thrown by Resources to http responses CandlepinException.java - base class for exceptions BadRequestException.java - I modified just one exception to be handled by the ExceptionMapper, as a trial/demo
please note that CandlepinExceptionMapper had to be registered via guice (see CandlepinModule.java).
Comments/thoughts are welcome (and are encouraged). Cheers, -Dmitri
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
I committed the first cut of parseable exceptions. The 'interesting' parts:
CandlepinExceptionMapper.java - the bit that maps exceptions thrown by Resources to http responses CandlepinException.java - base class for exceptions BadRequestException.java - I modified just one exception to be handled by the ExceptionMapper, as a trial/demo
Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
please note that CandlepinExceptionMapper had to be registered via guice (see CandlepinModule.java).
And guice looks for all folks who implement the mapper? Is this injected at every method boundary?
-- bk
On 10-04-12 3:56 PM, Bryan Kearney wrote:
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
I committed the first cut of parseable exceptions. The 'interesting' parts:
CandlepinExceptionMapper.java - the bit that maps exceptions thrown by Resources to http responses CandlepinException.java - base class for exceptions BadRequestException.java - I modified just one exception to be handled by the ExceptionMapper, as a trial/demo
Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
I'm not sure. I thought it was short message/long message. More or less for disambiguation of http return codes.
please note that CandlepinExceptionMapper had to be registered via guice (see CandlepinModule.java).
And guice looks for all folks who implement the mapper? Is this injected at every method boundary?
Binding the mapper using guice triggers registration of Provider (in resteasy lingo), which exception mapper is. Exception mapper handles the conversion of exceptions to responses (& JAXB handles serialization). I made a common super-class for candlepin exceptions to be thrown by Resources, and that exception mapper will handle them all (so no additional mapping is required for the rest of the exceptions).
-d
On 04/12/2010 03:41 PM, Dmitri Dolguikh wrote:
On 10-04-12 3:56 PM, Bryan Kearney wrote:
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
I committed the first cut of parseable exceptions. The 'interesting' parts:
CandlepinExceptionMapper.java - the bit that maps exceptions thrown by Resources to http responses CandlepinException.java - base class for exceptions BadRequestException.java - I modified just one exception to be handled by the ExceptionMapper, as a trial/demo
Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
I'm not sure. I thought it was short message/long message. More or less for disambiguation of http return codes.
Well.. before we go too far. Lets figure this out (as well as i18n). If we are going to go throgh the code, lets do it once.
-- bk
On Mon, Apr 12, 2010 at 03:46:13PM -0400, Bryan Kearney wrote:
On 04/12/2010 03:41 PM, Dmitri Dolguikh wrote:
On 10-04-12 3:56 PM, Bryan Kearney wrote:
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
I committed the first cut of parseable exceptions. The 'interesting' parts:
CandlepinExceptionMapper.java - the bit that maps exceptions thrown by Resources to http responses CandlepinException.java - base class for exceptions BadRequestException.java - I modified just one exception to be handled by the ExceptionMapper, as a trial/demo
Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
I like the current implementation with the mapper handling the proper serialization and the specific BadRequestException.
I'm not sure. I thought it was short message/long message. More or less for disambiguation of http return codes.
Well.. before we go too far. Lets figure this out (as well as i18n). If we are going to go throgh the code, lets do it once.
+1 so what would we like to have with respect to the messages? We could stick with short & long messages, and just use i18n keys for it.
jesus
On 04/12/2010 05:28 PM, Jesus Rodriguez wrote:
On Mon, Apr 12, 2010 at 03:46:13PM -0400, Bryan Kearney wrote:
On 04/12/2010 03:41 PM, Dmitri Dolguikh wrote:
On 10-04-12 3:56 PM, Bryan Kearney wrote:
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
I committed the first cut of parseable exceptions. The 'interesting' parts:
CandlepinExceptionMapper.java - the bit that maps exceptions thrown by Resources to http responses CandlepinException.java - base class for exceptions BadRequestException.java - I modified just one exception to be handled by the ExceptionMapper, as a trial/demo
Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
I like the current implementation with the mapper handling the proper serialization and the specific BadRequestException.
I'm not sure. I thought it was short message/long message. More or less for disambiguation of http return codes.
Well.. before we go too far. Lets figure this out (as well as i18n). If we are going to go throgh the code, lets do it once.
+1 so what would we like to have with respect to the messages? We could stick with short& long messages, and just use i18n keys for it.
I had been assuming something akin to the following:
new Exception("not_found", "The Consumer with ID %s was not found", consumer.id)
where the first string is a type or id, the second string is what will eventually be localized, and then a collection of objects which can be the messages. We could get fancy and do a hash for the last parameter and do key->value substitution instead of positional.
-- bk
On 10-04-13 9:13 AM, Bryan Kearney wrote:
On 04/12/2010 05:28 PM, Jesus Rodriguez wrote:
On Mon, Apr 12, 2010 at 03:46:13PM -0400, Bryan Kearney wrote:
On 04/12/2010 03:41 PM, Dmitri Dolguikh wrote:
On 10-04-12 3:56 PM, Bryan Kearney wrote:
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
I committed the first cut of parseable exceptions. The 'interesting' parts:
CandlepinExceptionMapper.java - the bit that maps exceptions thrown by Resources to http responses CandlepinException.java - base class for exceptions BadRequestException.java - I modified just one exception to be handled by the ExceptionMapper, as a trial/demo
Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
I like the current implementation with the mapper handling the proper serialization and the specific BadRequestException.
I'm not sure. I thought it was short message/long message. More or less for disambiguation of http return codes.
Well.. before we go too far. Lets figure this out (as well as i18n). If we are going to go throgh the code, lets do it once.
+1 so what would we like to have with respect to the messages? We could stick with short& long messages, and just use i18n keys for it.
I had been assuming something akin to the following:
new Exception("not_found", "The Consumer with ID %s was not found", consumer.id)
where the first string is a type or id, the second string is what will eventually be localized, and then a collection of objects which can be the messages. We could get fancy and do a hash for the last parameter and do key->value substitution instead of positional.
-- bk
I think that makes sense/works. I'm going to code it up and we'll see what everybody (and by that i mean Jesus and Bryan) thinks. -d
On 04/13/2010 08:59 AM, Dmitri Dolguikh wrote:
On 10-04-13 9:13 AM, Bryan Kearney wrote:
On 04/12/2010 05:28 PM, Jesus Rodriguez wrote:
On Mon, Apr 12, 2010 at 03:46:13PM -0400, Bryan Kearney wrote:
On 04/12/2010 03:41 PM, Dmitri Dolguikh wrote:
On 10-04-12 3:56 PM, Bryan Kearney wrote:
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
> I committed the first cut of parseable exceptions. The 'interesting' > parts: > > CandlepinExceptionMapper.java - the bit that maps exceptions thrown by > Resources to http responses > CandlepinException.java - base class for exceptions > BadRequestException.java - I modified just one exception to be handled > by the ExceptionMapper, as a trial/demo > Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
I like the current implementation with the mapper handling the proper serialization and the specific BadRequestException.
I'm not sure. I thought it was short message/long message. More or less for disambiguation of http return codes.
Well.. before we go too far. Lets figure this out (as well as i18n). If we are going to go throgh the code, lets do it once.
+1 so what would we like to have with respect to the messages? We could stick with short& long messages, and just use i18n keys for it.
I had been assuming something akin to the following:
new Exception("not_found", "The Consumer with ID %s was not found", consumer.id)
where the first string is a type or id, the second string is what will eventually be localized, and then a collection of objects which can be the messages. We could get fancy and do a hash for the last parameter and do key->value substitution instead of positional.
-- bk
I think that makes sense/works. I'm going to code it up and we'll see what everybody (and by that i mean Jesus and Bryan) thinks.
What is the latest and greatest i18n framework? Perhaps there is a better way. Guice is frickn voodoo.. so there may be a magic way for guice to do it.
-- bk
On Tue, Apr 13, 2010 at 09:06:06AM -0400, Bryan Kearney wrote:
On 04/13/2010 08:59 AM, Dmitri Dolguikh wrote:
[snip]
I think that makes sense/works. I'm going to code it up and we'll see what everybody (and by that i mean Jesus and Bryan) thinks.
What is the latest and greatest i18n framework? Perhaps there is a better way. Guice is frickn voodoo.. so there may be a magic way for guice to do it.
i18n framework? We just wrote a wrapper into xliff files in Spacewalk, though for Candlepin I think we can stick with properties files.
Basically we treated everything as keys, there was a LocalizationManager which everyone could get access to and lm.getMessage("somekey"). The keys were sometimes namespaced while other times just the English text: lm.getMessage("Subscription Management")
jesus
On Tue, Apr 13, 2010 at 09:06:06AM -0400, Bryan Kearney wrote: <snip>
What is the latest and greatest i18n framework? Perhaps there is a better way. Guice is frickn voodoo.. so there may be a magic way for guice to do it.
I like any of the ports of gnu gettext. IMO having the en_us string right in the code is much nicer than a key into a resource bundle. gettext-commons[1] looks pretty good.
-- bk
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
[1] http://code.google.com/p/gettext-commons/
-James
On Tue, Apr 13, 2010 at 09:15:31AM -0400, James Bowes wrote:
On Tue, Apr 13, 2010 at 09:06:06AM -0400, Bryan Kearney wrote:
<snip> > What is the latest and greatest i18n framework? Perhaps there is a > better way. Guice is frickn voodoo.. so there may be a magic way for > guice to do it. >
I like any of the ports of gnu gettext. IMO having the en_us string right in the code is much nicer than a key into a resource bundle. gettext-commons[1] looks pretty good.
keys don't have to be namespaces when using resource bundles. That was done mostly to identify where the string came from i.e. button.jsp.edit vs Edit.
But agreed, gettext-commons does look neat. Though like gettext in python & ruby, there *IS* a seperate build step to creating the bundles i..e .po files.
For cli and rpm builds this is *NOT* an issue. But will this have any impact on eclipse? since things done in the cli build step aren't usually done in eclipse.
All in all, it looks kinda nice.
jesus
----- "Jesus Rodriguez" jesusr@redhat.com wrote:
On Tue, Apr 13, 2010 at 09:15:31AM -0400, James Bowes wrote:
On Tue, Apr 13, 2010 at 09:06:06AM -0400, Bryan Kearney wrote:
<snip> > What is the latest and greatest i18n framework? Perhaps there is a
better way. Guice is frickn voodoo.. so there may be a magic way
for
guice to do it.
I like any of the ports of gnu gettext. IMO having the en_us string right in the code is much nicer than a key into a resource bundle. gettext-commons[1] looks pretty good.
keys don't have to be namespaces when using resource bundles. That was done mostly to identify where the string came from i.e. button.jsp.edit vs Edit.
But agreed, gettext-commons does look neat. Though like gettext in python & ruby, there *IS* a seperate build step to creating the bundles i..e .po files.
For cli and rpm builds this is *NOT* an issue. But will this have any impact on eclipse? since things done in the cli build step aren't usually done in eclipse.
IMO we should standardize on *one* build system, and I think that buildr works well for what we are doing. If people want to do fancy stuff with their IDE, that's fine - but I think that using a single tool as the "official" way would save us from a lot of duplicate work.
All in all, it looks kinda nice.
jesus
-- jesus m. rodriguez | jesusr@redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
candlepin@lists.fedorahosted.org