profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mcculls/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

mcculls/osgi-in-action 18

Automatically exported from code.google.com/p/osgi-in-action

mcculls/guice-betas 4

Unofficial BETA builds of Google-Guice with experimental features (for testing purposes only!)

mcculls/hudson 3

Hudson Platform

mcculls/guice 2

Guice (pronounced 'juice') is a lightweight dependency injection framework for Java 6 and above, brought to you by Google.

flatwhite/nexus-oss 0

Sonatype Nexus OSS

mcculls/bnd 0

bnd, the swiss army knife for OSGi. A tool to build bundles.

mcculls/byte-buddy 0

Runtime code generation for the Java virtual machine.

mcculls/cglib 0

cglib - Byte Code Generation Library is high level API to generate and transform Java byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.

mcculls/gshell 0

GShell 2.x

pull request commentDataDog/dd-trace-js

Support for ShareDB (datadog-plugin-sharedb)

Codecov Report

Merging #1436 (e305ea6) into master (7e72f2a) will decrease coverage by 0.13%. The diff coverage is 77.77%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1436      +/-   ##
==========================================
- Coverage   94.29%   94.16%   -0.14%     
==========================================
  Files         155      156       +1     
  Lines        6385     6439      +54     
==========================================
+ Hits         6021     6063      +42     
- Misses        364      376      +12     
Impacted Files Coverage Δ
packages/dd-trace/src/plugins/index.js 100.00% <ø> (ø)
packages/datadog-plugin-sharedb/src/index.js 77.77% <77.77%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 7e72f2a...e305ea6. Read the comment docs.

dwinrick-lever

comment created time in an hour

push eventDataDog/documentation

Ruth Naebeck

commit sha 440341f3c665063a7772401e37702d386fbc413c

update for build

view details

push time in an hour

created tagDataDog/documentation

tagmaster4674

The source for Datadog's documentation site.

created time in an hour

created tagDataDog/documentation

tagmaster4673

The source for Datadog's documentation site.

created time in 2 hours

pull request commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

@ivoanjo thanks for taking a look at this still draft PR.

I've talked to @delner last month about it as well, and there's quite a bit of stuff that works well here, but also a lot of work that will spawn from this: more clear separation for per-product lifecycle management and dependencies.

I'll break this down into smaller, digestible parts. Some will be easy to implement without much change, other will likely won't be done by the time I finish the main goal of removing lazy initialization.

marcotc

comment created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

+require 'forwardable'+require 'ddtrace/configuration/settings'+require 'ddtrace/configuration/components'+require 'ddtrace/configuration/pin_setup'++module Datadog+  module Tracing+    # This class encapsulates all tracer runtime data and objects.+    #+    # Any stateful component or information that the tracer requires+    # to execute must be directly or indirectly managed by {Runtime}.+    #+    # Any object who's life cycle is not captured by {Runtime} should be+    # part of the generic tracer structure, unaffected by configuration+    # or runtime state.+    #+    # Creating a new {Runtime} will effectively configure and initialized a new+    # running instance of the tracer.+    #+    # Reconfiguration the {Runtime} will affect the running tracer instance without+    # a complete restart of the tracer internals.+    #+    # Destroying the {Runtime} will shutdown the current tracer instance.+    #+    # The tracer has started if and only if (iff) the {Runtime} has been started.+    # The tracer is shut down if and only if (iff) the {Runtime} is shut down.+    #+    # A production user of the tracer will only initialize at most a single {Runtime}+    # instance throughout the lifetime of the host application. Changes to the tracer+    # state will be handled by {Runtime#configure} invocations.+    #+    # TODO: {Runtime} currently indirectly manages the Profiler, though Components.+    # TODO: The Profiler life cycle management should be eventually extracted to its own runtime.+    class Runtime

Agree, there should be a Runtime per product, handling its own things. And I guess one for shared stuff like the logger.

marcotc

comment created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

+require 'forwardable'+require 'ddtrace/configuration/settings'+require 'ddtrace/configuration/components'+require 'ddtrace/configuration/pin_setup'++module Datadog+  module Tracing+    # This class encapsulates all tracer runtime data and objects.+    #+    # Any stateful component or information that the tracer requires+    # to execute must be directly or indirectly managed by {Runtime}.+    #+    # Any object who's life cycle is not captured by {Runtime} should be+    # part of the generic tracer structure, unaffected by configuration+    # or runtime state.+    #+    # Creating a new {Runtime} will effectively configure and initialized a new+    # running instance of the tracer.+    #+    # Reconfiguration the {Runtime} will affect the running tracer instance without+    # a complete restart of the tracer internals.+    #+    # Destroying the {Runtime} will shutdown the current tracer instance.+    #+    # The tracer has started if and only if (iff) the {Runtime} has been started.+    # The tracer is shut down if and only if (iff) the {Runtime} is shut down.+    #+    # A production user of the tracer will only initialize at most a single {Runtime}+    # instance throughout the lifetime of the host application. Changes to the tracer+    # state will be handled by {Runtime#configure} invocations.+    #+    # TODO: {Runtime} currently indirectly manages the Profiler, though Components.+    # TODO: The Profiler life cycle management should be eventually extracted to its own runtime.+    class Runtime+      extend Forwardable++      attr_reader :configuration++      # Loads configuration and initializes basic components.+      def initialize(+        configuration = Configuration::Settings.new,+        components = Configuration::Components.new(configuration)+      )+        @configuration = configuration+        @components = components+      end++      # Triggers second step of component initialization.+      def startup!+        @components.startup!(@configuration)+      end++      def_delegators \+        :components,+        :health_metrics, :logger, :profiler, :runtime_metrics, :tracer++      # Alters configuration of the active {Runtime}.+      #+      # This call triggers component re-instantiation.+      def configure(target = configuration, opts = {})+        return Configuration::PinSetup.new(target, opts).call unless target.is_a?(Configuration::Settings)++        yield(target) if block_given?

This is so weird right? This is the part where the abstraction breaks, and this messy Pin stuff comes in.

I really don't like it, but I couldn't find a better place to hide it.

I don't like this #configure method having a "dual" interface, so I think it's best for us to completely separate this Pin stuff altogether.

Unfortunately it's a pretty hard breaking change for clients using Datadog.configure(my_client), which is a well documented and used feature. Ideally it should be a different method then #configure for us.

But I agree with you that this does not belong here. I'm hoping to break this API in 1.0 and remove Pin references from here.

marcotc

comment created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

 require 'ddtrace/ext/runtime' +# TODO: suggested namespace+# Datadog::Tracing::Environment::Ruby::GC+# Datadog::Tracing::Environment::Socket+# Datadog::Tracing::Runtime/Engine

So the name Datadog::Runtime is taken today by a module for stuff like Datadog::Runtime::CGroup, but the "runtime" introduce in this PR is very clearly described as "the" runtime for ddtrace.

I'd like to reclaim the Datadog::Runtime namespace for the runtime class, but that will require moving stuff like Datadog::Runtime::CGroup to a different namespace.

marcotc

comment created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

+require 'ddtrace/tracing/runtime'++module Datadog+  # Manages the {Runtime} life cycle for the host application.+  #+  # The {Runtime} is a container of all stateful tracer internals.+  #+  # {LifeCycle} ensure that the {Runtime} is created,+  # modified and decommissioned correctly during the host+  # application's life cycle.+  module LifeCycle+    extend Forwardable++    def_delegators \+        :runtime,+        :configure, :shutdown!,+        :configuration,+        :health_metrics, :logger, :profiler, :runtime_metrics, :tracer++    protected++    def start!(runtime = Tracing::Runtime.new)+      @runtime = runtime+      runtime.startup!+    end++    private++    attr_reader :runtime++    # Only used internally for testing+    def started?+      !@runtime.nil?+    end++    # Only used internally for testing+    def tear_down!+      shutdown! if started?++      # TODO: this is actually part of contrib+      # TODO: should probably be moved to inside contrib/+      # Reset stateful registry data+      registry.each do |data|+        data.klass.reset_configuration!+      end++      @runtime = nil+    end++    # Only used internally for testing+    def restart!+      tear_down!+      start!+    end

I think I tried that, but they happen too early in the application require cycle. I'll give it another shot at it.

marcotc

comment created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

+module Datadog+  # Responsible for the behavior the tracer after it's completely+  # loaded, but before `require 'ddtrace'` returns control to+  # the user.+  class Initialization++    # @param tracer [Datadog] an application-level Datadog APM tracer object+    def initialize(tracer)+      @tracer = tracer+    end++    # Initializes the tracer.+    #+    # This performs performs any initialization necessary+    # before control is returned to the host application.+    #+    # The tracer should be ready for use after this call.+    #+    # This method is invoked once per application life cycle.+    def initialize!

I don't quite understand the rule for us to use ! in our codebase. E.g. why initialize! but not start_life_cycle!?

I think we go for a "very danger" is !, but I don't think it's set in stone. start_life_cycle! seems like a ! if initialize is a !.

marcotc

comment created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

+module Datadog+  # Responsible for the behavior the tracer after it's completely+  # loaded, but before `require 'ddtrace'` returns control to+  # the user.+  class Initialization++    # @param tracer [Datadog] an application-level Datadog APM tracer object+    def initialize(tracer)

For this whole PR, there should exist a separate runtime/initializer for each of our separate products (profiler initializer/runtime, ci initialize/runtime).

I haven't had the chance to refactor it as such, but each product should own its lifecycle separately.

lib/ddtrace/initialization.rb will likely bring them all together (or expose precise hooks so that profiler, ci, etc can hook themselves in).

marcotc

comment created time in 2 hours

created tagDataDog/documentation

tagmaster4672

The source for Datadog's documentation site.

created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

 def reduce_log_verbosity       end     end   end++  # Load and extend Contrib by default+  extend Contrib::Extensions end

This is a tricky one: ideally lib/ddtrace.rb doesn't need to know that contrib exists. Contrib is additive to the core library, and configures itself as such (or at least that's what we wanted).

Some parts are more core than other, and can't be feasibly separated, but for contrib that was the goal with having it all under lib/ddtrace/contrib.

There's one point where the "Datadog product" is created, bringing this all together and breaking this separation, but I was trying to avoid it if possible here.

marcotc

comment created time in 2 hours

PR opened DataDog/documentation

DOCS-2083 Azure US3 Portal

<!-- Note: Please remember to review the Datadog Documentation Contribution Guidelines if you have not yet done so. -->

What does this PR do?

  • Add documentation for Azure US3 Portal

Motivation

Jira request from PM

Preview

https://docs-staging.datadoghq.com/ruth/docs-2083/integrations/azure/

Additional Notes

  • https://github.com/DataDog/dogweb/pull/62430
  • [Gitlab](

Reviewer checklist

  • [ ] Review the changed files.
  • [ ] Review the URLs listed in the Preview section.
  • [ ] Review any mentions of "Contact Datadog support" for internal support documentation.
+41 -1

0 comment

18 changed files

pr created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

 module Contrib     module Extensions       def self.extended(base)         Datadog.extend(Helpers)-        Datadog.extend(Configuration)+        Datadog::Tracing::Runtime.prepend(Configuration)         Datadog::Configuration::Settings.include(Configuration::Settings)       end        # Helper methods for Datadog module.       module Helpers+        # Registry is a global, declarative repository of all available integrations.+        #+        # Integrations should register themselves with the registry as early as+        # possible as the initial tracer configuration can only activate integrations+        # if they have already been registered.+        #+        # Despite that, integrations *can* be appended to the registry at any point+        # of the program execution. Newly appended integrations can then be+        # activated during tracer reconfiguration.+        #+        # The registry itself is stateless: it does not depend on runtime configuration+        # and must execute correctly after successive configuration changes.+        # The registered integrations themselves can depend on the stateful configuration+        # of the tracer.         def registry-          configuration.registry+          @registry ||= Registry.new         end       end

That makes sense, I'll try to constantenize this one.

marcotc

comment created time in 2 hours

Pull request review commentDataDog/dd-trace-rb

[WIP] Eager tracer initialization

 def build_tracer(settings, agent_settings)             default_service: settings.service,             enabled: settings.tracer.enabled,             partial_flush: settings.tracer.partial_flush.enabled,-            tags: build_tracer_tags(settings)+            tags: build_tracer_tags(settings),+            sampler: PrioritySampler.new(+              base_sampler: AllSampler.new,+              post_sampler: Sampling::RuleSampler.new(+                rate_limit: settings.sampling.rate_limit,+                default_sample_rate: settings.sampling.default_rate,+              )+            )

This is actually the default behaviour, it's kind of hard to reason about this today, because whatever sampler you pass to sampler: it gets converted to a PrioritySampler if not already. The default is an AllSampler as base_sampler and RuleSampler as post_sampler..

Btw, this changes is here because letting Datadog::Tracer resolve the default sampler puts us in a circular dependency between tracer initialization and configuration initialization.

marcotc

comment created time in 2 hours

push eventDataDog/documentation

Austin Lai

commit sha c15ec958b0f8ccf02a5b3c03190b78fd085a32f7

Getting Started with Synthetic Monitoring > API Tests I would like to verify that I correctly entered a new link in the Further Reading section (link #6).

view details

Austin Lai

commit sha 783c81156acba84178dfc99ab82cd9634d654a54

Doc Review #1 Approved suggestions. Co-authored-by: Kari Halsted <12926135+kayayarai@users.noreply.github.com>

view details

Austin Lai

commit sha e445708c6b06df1815d5dc06452379fc60999354

Doc Review #2 Co-authored-by: Kari Halsted <12926135+kayayarai@users.noreply.github.com>

view details

Austin Lai

commit sha e43476e863394f6d6201d79f06936e0c9d486b24

Doc Review #3 Co-authored-by: Kari Halsted <12926135+kayayarai@users.noreply.github.com>

view details

Austin Lai

commit sha b2776ea69b381049a58f43e729bc3478e2607fb8

Update api_test.md

view details

Austin Lai

commit sha 13d5aa22f468ca7d36f6047dea2a44525fcd0681

Doc Review #4 Co-authored-by: Kari Halsted <12926135+kayayarai@users.noreply.github.com>

view details

Austin Lai

commit sha 1bdde948fc2fc695044def2dc05428ff695469ca

Merge pull request #10885 from DataDog/alai97/synthetics-api-tests-getting-started Getting Started with Synthetic Monitoring > API Tests

view details

push time in 2 hours

delete branch DataDog/documentation

delete branch : alai97/synthetics-api-tests-getting-started

delete time in 2 hours

PR merged DataDog/documentation

Reviewers
Getting Started with Synthetic Monitoring > API Tests getting_started

I would like to verify that I correctly entered a new link in the Further Reading section (link #6).

<!-- Note: Please remember to review the Datadog Documentation Contribution Guidelines if you have not yet done so. -->

What does this PR do?

<!-- A brief description of the change being made with this pull request.-->

Revamp the Getting Started with API Tests page with updated content.

Motivation

<!-- What inspired you to submit this pull request?-->

DOCS-1979

Preview

<!-- Impacted pages preview links-->

<!-- This only works if you are part of the Datadog organization and working off of a branch - it will not work with a fork.

Replace the branch name and add the complete path: --> https://docs-staging.datadoghq.com/alai97/synthetics-api-tests-getting-started/getting_started/synthetics/api_test

Additional Notes

<!-- Anything else we should know when reviewing?-->


Reviewer checklist

  • [ ] Review the changed files.
  • [ ] Review the URLs listed in the Preview section.
  • [ ] Review any mentions of "Contact Datadog support" for internal support documentation.
+47 -20

0 comment

1 changed file

alai97

pr closed time in 2 hours

issue closedDataDog/trace-examples

[python/ASGI] how to run?

For execution it says "If you already have datadog agent running as well as ASGI server: uvicorn, you could run: uvicorn app:app." I'm a bit confused by what it means by "datadog agent". Would the datadog daemonset on the same node (deployed by the official datadog helm chart) be enough or should I also prepend the daphne command with ddtrace-run, like so?

ddtrace-run daphne --argsgohere ff.asgi:application

Note that we are using django and the latest version of ddtrace python library and helm chart.

closed time in 2 hours

caleb15

issue commentDataDog/trace-examples

[python/ASGI] how to run?

Yep, ddtrace-run is required. Once I prepended that it started working.

caleb15

comment created time in 2 hours

create barnchDataDog/documentation

branch : ruth/docs-2083

created branch time in 2 hours

push eventDataDog/documentation

Jorie Helwig

commit sha 8e00293dca9529a1ecf2265058cea74f74ddb2b9

Add blog link

view details

Kari Halsted

commit sha 1a2bbf0771bf94138f06569ddf9a07dbe6280ffd

Merge pull request #10921 from DataDog/jorie/add-blog-ci-link Add blog link

view details

push time in 2 hours

delete branch DataDog/documentation

delete branch : jorie/add-blog-ci-link

delete time in 2 hours

PR merged DataDog/documentation

Add blog link synthetics

<!-- Note: Please remember to review the Datadog Documentation Contribution Guidelines if you have not yet done so. -->

What does this PR do?

Add blog link

Motivation

On call tasks

Preview

<!-- Impacted pages preview links-->

<!-- This only works if you are part of the Datadog organization and working off of a branch - it will not work with a fork.

Replace the branch name and add the complete path: --> https://docs-staging.datadoghq.com/jorie/add-blog-ci-link/synthetics/ci/?tab=apitest

Additional Notes

<!-- Anything else we should know when reviewing?-->


Reviewer checklist

  • [ ] Review the changed files.
  • [ ] Review the URLs listed in the Preview section.
  • [ ] Review any mentions of "Contact Datadog support" for internal support documentation.
+3 -0

0 comment

1 changed file

jtappa

pr closed time in 2 hours

PR opened sonatype/docker-nexus3

NEXUS-27617: Using new chef recipe that doesn't include java management review

To get onto openjdk 8u282 we need to manually deal with java, as 282 is no longer the latest bulid, and the current (292) has a bug that is causing SAML to not function (fix is in 302 which is still in EA)

This pull request makes the following changes:

  • Switched to the new 3x-docker chef recipe (which has no java recipe)
  • Manually download/install the 8u282 openjdk build

This PR depends on an upcoming PR in https://github.com/sonatype/chef-nexus-repository-manager once someone gets me access to create branches over there ;)

+5 -1

0 comment

1 changed file

pr created time in 2 hours

push eventDataDog/documentation

Kaylyn

commit sha e92b226d3044c8f9a6ad3645247f3068a9c6ad97

adding the serverless product github team as a codeowner to the serverless section so that they can get pinged on PRs that need reviewed (#10910)

view details

push time in 2 hours

delete branch DataDog/documentation

delete branch : kaylyn/serverless-codeowners

delete time in 2 hours

PR merged DataDog/documentation

Serverless codeowners Github

What does this PR do?

Updates to add the Serverless product github team to be tagged to review Serverless PRs.

+4 -0

0 comment

1 changed file

apigirl

pr closed time in 2 hours

pull request commentDataDog/documentation

Adding a new library

hey, this is a good catch! for this library I would prefer to have it at the bottom just because it is not going to be used nearly as much as the other ones.

apigirl

comment created time in 2 hours