-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spring Framework Integration #1
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR Andrew. I've added a few comments around some desired functionality changed. I'd be happy to work with you to add some of these changes as well.
import org.aspectj.lang.annotation.Around; | ||
import org.aspectj.lang.annotation.Pointcut; | ||
import org.slf4j.Logger; | ||
import org.slf4j.LoggerFactory; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an SDK convention we have been relying on org.apache.commons.logging.Log
for our log framework, only because it is bundled with the AWS SDK already, and keeps the logging consistent between the two. I'd be open to switching to slf4j
across the SDK if a good case could be made for diverging from the AWS SDK, though.
if (AWSXRay.getCurrentSegment() != null) { | ||
LOGGER.trace("Current segment exists"); | ||
} | ||
} catch (SegmentNotFoundException snfe) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The segment not found cases should be passed to the current recorder's ContextMissingStrategy
. We try to protect users from inadvertent tracing context loss (happens most often when trying to trace multi-threaded operations). In order to protect users from losing their tracing context, we must by default throw an exception when a user tries to create a subsegment with no segment in progress. Of course, users may override this if they desire. But the default behavior should pass the exception onto the context missing strategy and allow that strategy to create a default segment, if it so desires.
subsegment.setMetadata(this.generateMetadata(pjp, subsegment)); | ||
return XRayInterceptorUtils.conditionalProceed(pjp); | ||
} catch (Exception e) { | ||
LOGGER.error(e.getMessage()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should avoid re-logging any exceptions that may pass through customer code, as they likely will be logging it already.
classInfo.put("Class", pjp.getTarget().getClass().getSimpleName()); | ||
metadata.put("ClassInfo", classInfo); | ||
String arg = (String) pjp.getArgs()[0]; | ||
subsegment.putSql("SQL Statement",arg); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've reserved the keyword sanitized_query
in our segment schema for such cases, would it be possible to sanitize the query of any literal values and use that keyword here? Perhaps we could also provide a query
only option (non-sanitized) but we should draw user's attention to the fact that they are adding sensitive information to their traces.
Thx for the feedback. I've updated the code with the suggestions and committed for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few comments around the pom and the context missing behavior.
<source>1.8</source> | ||
<target>1.8</target> | ||
</configuration> | ||
</plugin> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you add the Javadoc plugin to align this with other submodule poms?
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.4</version>
Additionally, it may be useful to consider adding another <group>
tag in the main pom.xml
to ensure these com.amazonaws.xray.spring.*
classes are documented together in a group.
<version>2.0.0.RELEASE</version> | ||
<scope>provided</scope> | ||
</dependency> | ||
<dependency> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I'm missing something but it doesn't look like this dependency on javax.servlet.servlet-api
is used in the submodule.
aws-xray-recorder-sdk-spring/pom.xml
Outdated
<parent> | ||
<groupId>com.amazonaws</groupId> | ||
<artifactId>aws-xray-recorder-sdk-pom</artifactId> | ||
<version>1.2.1</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the trouble but the version has bumped to 1.2.2
since this was posted, would it be possible to increment?
@@ -5,3 +5,6 @@ | |||
.project | |||
.classpath | |||
.DS_Store | |||
|
|||
*.iml | |||
/.idea |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick but it may mess up other users' editors - can we add newlines at EOF where missing?
aws-xray-recorder-sdk-spring/pom.xml
Outdated
<dependency> | ||
<groupId>com.amazonaws</groupId> | ||
<artifactId>aws-xray-recorder-sdk-core</artifactId> | ||
<version>1.2.0</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using <version>${awsxrayrecordersdk.version}</version>
will allow this submodule to directly depend on the latest version of the core module.
if (AWSXRay.getCurrentSegment() != null) { | ||
logger.trace("Current segment exists"); | ||
} | ||
} catch (SegmentNotFoundException snfe) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if my previous comment regarding context missing strategies was unclear. The logic inside the getCurrentSegment()
function should reference the context missing strategy as needed - and will only throw the SegmentNotFoundException
if the strategy calls for it.
public Segment getCurrentSegment() {
Optional<Segment> segment = getCurrentSegmentOptional();
if (segment.isPresent()) {
return segment.get();
}
contextMissingStrategy.contextMissing("No segment in progress.", SegmentNotFoundException.class);
return null;
}
So, there should be no need to catch exceptions here. And the boolean endSegment
shouldn't be required either. We can call getSegment()
and compare the value against null
to determine whether or not a subsegment should be created here.
Incorporated latest round of feedback and merged the upstream repo |
# Conflicts: # aws-xray-recorder-sdk/pom.xml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry just one comment about the creation of segments. Looks ready to go otherwise.
@@ -1,5 +1,5 @@ | |||
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | |||
xsi:schemaLocation="http://mapven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> | |||
<project xmlns="http://maven.apache.org/POM/4.0.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 thanks for fixing these across the board!! 😁
protected Object processXRayTrace(ProceedingJoinPoint pjp) throws Throwable { | ||
Segment segment = getCurrentSegment(); | ||
if (segment == null) { | ||
AWSXRay.beginSegment(pjp.getSignature().getName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that this beginSegment
remains while the endSegment
logic was taken out. I'm still not sure we can get away with beginning the segments if one doesn't exist - I think we'd have to leave that up to the SegmentContext
/ ContextMissingStrategy
chosen by the programmer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed and pushed
* Adding Spring modules for X-Ray. * Adding POM description * Fixing issues highlighted from PR #1 * Removing GPG maven plugin override * Reformatting code * Homologizing logging declarations * abstracting spring version to property and removing SLF4J dependency * referencing parent version for module version * removing redundant groupId from POM * adding newline at EOF * Incorporating feedback from PR #1 * Adding newline at EOF * updating POMs * Adding module into main pom * Removing beginSegment() per comments on PR #1 * Bumping version to 1.3.0 for release of Spring integration * Instating the ability for developers to override generateMetadata to create custom metadata outside of the base metadata provoided by XRayInterceptorUtils.generateMetadata.
This integration for the Spring Framework enables the usage of aspects to trace requests down a call stack. Classes can either implement an interface or be annotated to identify themselves as available to the aspect for tracing.