isDebugEnabled usage
by Jesus M. Rodriguez
I saw some code yesterday that reminded me of the usage for isDebugEnabled().
The code is:
private void debugMessage(String msg) {
if (log.isDebugEnabled()) {
log.debug(msg);
}
}
Then a bunch of calls to that: debugMessage("some message here");
This sort of defeats the purpose of wrapping the log.debug(). While I've always
been a fan of ALWAYS wrapping log.debug(), I've gone with the wrap them
if the strings are being concatenated.
See the discussion on spacewalk list:
http://www.mail-archive.com/spacewalk-devel@redhat.com/msg01204.html
So for candlepin, let's go with just doing log.debug("simple string")
when needed
and wrap the ones where you are dealing with concatenation i.e.
log.debug("Found token in curator " + subToken + " " + token);
Some would argue this is premature optimization, but having had to go through
this with 3 projects now, I'd like to go ahead and just head off this now before
we have 100k of code.
Thanks
jesus
PS sloccount shows
Totals grouped by language (dominant language first):
java: 10370 (90.61%)
python: 711 (6.21%)
sh: 249 (2.18%)
ruby: 115 (1.00%)
14 years, 3 months
equals
by Jesus M. Rodriguez
I brought this up in the hallway today, figured I'd share. What is the
best practices
around equals methods? I made a change to a Consumer's facts list in a test
and expected the test to fail.
Consumer con1 = new Consumer("name", owner, consumerType);
Consumer con2 = new Consumer(con1);
con1.getFacts().put("name1", "value1");
...
assertEquals(con1, con2);
It did NOT fail. The equals of the Consumer checks only that the uuid's are
equal. For the most part this makes sense, but is that really what equals
should check? part of me says no it should check everything, but for the
most part maybe all we care about is that the uuid's are the same for Consumers.
Thoughts?
jesus
14 years, 3 months
RFC security configuration
by Bryan Kearney
So I played with the new security stuff from rails.. looks good. One
question for the group based on a quick conversation which Dmitri and I had:
Does it make sense to add to the candlepin configuration the ability to
1) Define the actual filter to use for Basic Auth
2) Define the actual filter to use for certificate auth?
Or.. another option:
Does it make sense to support properties like
auth.basic= true
auth.ssl=true
??
-- bk
14 years, 3 months
buildr patching
by Jesus M. Rodriguez
If you run into an OP_RE error when running buildr, this means you
have gems 1.3.6 and buildr 1.3.5.
Easiest way to fix this is to patch buildr. I have added a page to the
wiki describing the process, and
linked to it from the Building instructions page. Once buildr 1.4
comes out we can remove them.
The error in question looks like this:
/usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2503:in
`const_missing': uninitialized constant Gem::Requirement::OP_RE
(NameError)
from /usr/lib/ruby/gems/1.8/gems/buildr-1.3.5/lib/buildr/packaging/version_requirement.rb:24
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
`require'
....
Here's how to fix it: https://fedorahosted.org/candlepin/wiki/PatchingBuildr
jesus
14 years, 3 months
deleted entity passed to persist:
by Adam Young
If you see the above error, it seems to mean that a delete is violating
a constraint.
I got this exception with the following code:
@DELETE
@Path("/{dbid}")
public void unbind(@PathParam("dbid") Long dbid) {
Entitlement toDelete = entitlementCurator.find(dbid);
if (toDelete != null) {
//toDelete.getConsumer().getEntitlements().remove(toDelete);
entitlementCurator.delete(toDelete);
return;
}
throw new NotFoundException(
"Entitlement with ID '" + dbid + "' could not be found");
}
To get rid of the error, uncomment out the line //toDelete...
14 years, 3 months
handling of exceptions
by Jesus M. Rodriguez
In a discussion with Prad, Adrian asked how we should handle
exceptions in candlepin.
Right now we seem to throw BadRequestException[1] whenever we have a problem.
The idea is we want to send back a 400 (or other proper HTTP code),
then the client
can read the response. In the response we want a JSON string that they can read
what really happened.
Unfortunately, our current implementation yields a plain text string
(not json) even
if I change the code to be .type("application/json"). But if I pass a
jaxb object to the
Exception class it gets serialized properly.
So we'll create a ExceptionMessage object that can be jaxbified, that
would contain
the following attributes:
name i.e. "invalid_argument"
message i.e. text string as to what happened
display message i.e. text string that can be displayed to the user
Then BadRequestException (and other wrapped exceptions) will contain an
ExceptionMessage object inside.
A few things need to happen in this as well:
* need to figure out proper HTTP error codes and WHEN to send them
* create ExceptionMessage class
* create the wrapper exception classes
[1] BadRequestException is a wrapper around jax-rs WebApplicationException where
we set the Response status to be BAD_REQUEST (400).
14 years, 3 months
Allow clients to specificy their own UUIDs, and not use the auto generated o...
by Jesus M. Rodriguez
Bryan,
why are we allowing clients to specify their own UUIDs?
Seems like there could be collisions. Also, it seems odd
that the copy ctor doesn't actually make an exact copy.
jesus
Sent to you by jmrodri via Google Reader: Allow clients to specificy
their own UUIDs, and not use the auto generated ones. via Fedora Hosted
Git Repositories - candlepin.git/rss log by Bryan Kearney
<bkearney(a)redhat.com> on 3/18/10
Allow clients to specificy their own UUIDs, and not use the auto
generated ones.
- [DH]
proxy/src/main/java/org/fedoraproject/candlepin/model/Consumer.java
- [DH]
proxy/src/test/java/org/fedoraproject/candlepin/model/test/ConsumerTest.java
- [DH]
proxy/src/test/java/org/fedoraproject/candlepin/resource/test/ConsumerResourceTest.java
Things you can do from here:
- Subscribe to Fedora Hosted Git Repositories - candlepin.git/rss log
using Google Reader
- Get started using Google Reader to easily keep up with all your
favorite sites
14 years, 3 months
Re: Is this acceptable?
by Justin Harris
----- "Adam Young" <ayoung(a)redhat.com> wrote:
> We are currently only going to unbind by entitlement ID. Thus to do
> unbind by product
>
> GET http://host:8080/candlepin/consumers/<uuid>/entitlements and
> iterate
> through the collection to find the entitlement id for the given
> product
>
> Then:
>
> DELETE http://host:8080/candlepin/consumers/<uuid>/entitlements/<id>
>
>
> I'd prefer it if instead the first step were:
>
> GET http://host:8080/candlepin/consumers/<uuid>/products/<id>
>
> Which would return a page with entitlement ID on it.
To sidestep your original question entirely...
This feels like we are going too far down the hierarchy.
I would think that the first call is good, then for the second:
DELETE http://host:8080/candlepin/entitlements/<id>
So with the first GET, you are requesting the collection of entitlements that are
entitled to the specified consumer, but when dealing with a specific entitlement by id, just use
the "global" collection to reference it.
Bryan - is this consistent with HATEOAS?
- justin
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
14 years, 3 months
