Automatically exported from code.google.com/p/osgi-in-action
Unofficial BETA builds of Google-Guice with experimental features (for testing purposes only!)
Hudson Platform
Guice (pronounced 'juice') is a lightweight dependency injection framework for Java 6 and above, brought to you by Google.
Sonatype Nexus OSS
bnd, the swiss army knife for OSGi. A tool to build bundles.
Runtime code generation for the Java virtual machine.
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.
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 is77.77%.
@@ 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 dataPowered by Codecov. Last update 7e72f2a...e305ea6. Read the comment docs.
comment created time in an hour
push eventDataDog/documentation
commit sha 440341f3c665063a7772401e37702d386fbc413c
update for build
push time in an hour
created tagDataDog/documentation
The source for Datadog's documentation site.
created time in an hour
created tagDataDog/documentation
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.
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.
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.
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.
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?+ [email protected]?+ 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.
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 !.
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).
comment created time in 2 hours
created tagDataDog/documentation
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.
comment created time in 2 hours
PR opened DataDog/documentation
<!-- 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.
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.
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.
comment created time in 2 hours
push eventDataDog/documentation
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).
commit sha 783c81156acba84178dfc99ab82cd9634d654a54
Doc Review #1 Approved suggestions. Co-authored-by: Kari Halsted <[email protected]>
commit sha e445708c6b06df1815d5dc06452379fc60999354
Doc Review #2 Co-authored-by: Kari Halsted <[email protected]>
commit sha e43476e863394f6d6201d79f06936e0c9d486b24
Doc Review #3 Co-authored-by: Kari Halsted <[email protected]>
commit sha b2776ea69b381049a58f43e729bc3478e2607fb8
Update api_test.md
commit sha 13d5aa22f468ca7d36f6047dea2a44525fcd0681
Doc Review #4 Co-authored-by: Kari Halsted <[email protected]>
commit sha 1bdde948fc2fc695044def2dc05428ff695469ca
Merge pull request #10885 from DataDog/alai97/synthetics-api-tests-getting-started Getting Started with Synthetic Monitoring > API Tests
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
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.
pr closed time in 2 hours
issue closedDataDog/trace-examples
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
caleb15issue commentDataDog/trace-examples
Yep, ddtrace-run is required. Once I prepended that it started working.
comment created time in 2 hours
push eventDataDog/documentation
commit sha 8e00293dca9529a1ecf2265058cea74f74ddb2b9
Add blog link
commit sha 1a2bbf0771bf94138f06569ddf9a07dbe6280ffd
Merge pull request #10921 from DataDog/jorie/add-blog-ci-link Add blog link
push time in 2 hours
PR merged DataDog/documentation
<!-- 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.
pr closed time in 2 hours
PR opened sonatype/docker-nexus3
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 ;)
pr created time in 2 hours
push eventDataDog/documentation
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)
push time in 2 hours
delete branch DataDog/documentation
delete branch : kaylyn/serverless-codeowners
delete time in 2 hours
PR merged DataDog/documentation
What does this PR do?
Updates to add the Serverless product github team to be tagged to review Serverless PRs.
pr closed time in 2 hours
pull request commentDataDog/documentation
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.
comment created time in 2 hours