GithubHelp home page GithubHelp logo

oswaldobapvicjr / agents Goto Github PK

View Code? Open in Web Editor NEW
4.0 4.0 3.0 248 KB

A lightweight timer/cron agents framework for Java applications

License: Apache License 2.0

Java 100.00%
agent cron cron-jobs cronjob-scheduler crontab executor java scheduler timer timer-agent

agents's Introduction

Hi there

  • I'm a Product Owner and Software Developer from São Paulo, Brazil.
  • I'm currently working with Java (Back-end) for a telecom solution in the AWS cloud.
  • I like to create tools to help developers increase productivity.
  • Ask me about JSON, OOP, design patterns, unit testing, and cloud-native software design.

GitHub stats

agents's People

Contributors

academy-codex avatar dependabot[bot] avatar oswaldobapvicjr avatar snyk-bot avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar

agents's Issues

Interval modulation flag

Enhancement/Feature request

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
A new flag (suggested name: modulate) that enables/disables interval modulation for the first execution of an agent.

Describe alternatives you've considered
Not applicable.

Solution details

Currently, there is a sort of "modulation" applied by default for all agents. For example: if the current hour is 3 am and the agent interval is 4 hours then the first execution will occur at 4 am, and then the next ones will occur at 8 am, noon, 4 pm, etc.

The new flag would indicate whether the interval should be adjusted to cause the next execution to occur on the interval boundary.

Expected behavior

  • (modulate=true): if the current hour is 3h25 am and the agent interval is 4 hours then the first execution will occur at 4 am, and then the next ones will occur at 8 am, noon, 4 pm, etc.

  • (modulate=false): if the current hour is 3h25 am and the agent interval is 4 hours then the first execution will occur at 3h25 am, and then the next ones will occur at 7h25 am, 11h25, 15h25 pm, etc.

By default, if the modulation flag shall be false (if not specified via annotation or the property is not available in XML/JSON/YAML).

Additional details

  • The code shall be developed in the issue/0010 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

Migrate from Travis and Coveralls to GitHub Actions and Codecov

Enhancement

Proposed solution

Upgrade project configuration and badges:

  • Build status: Travis CI > GitHub Actions
  • Code coverage: Coveralls > Codecov

Additional details

  • The code shall be developed in the issue/0007 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

Upgrade JaCoCo to 0.8.7 to fix build issues with JDK 17

Enhancement

Proposed solution

Upgrade JaCoCo dependency from 0.8.6 to 0.8.7 to fix build issues with JDK 17-ea.

Additional details

  • The code shall be developed in the issue/0001 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

External configuration via YAML file

Enhancement

This enhancement introduces the possibility to set up agents' configurations, such as name, interval, and type via YAML file.
So, for every annotated agent, the system shall search for an optional XML, JSON, and YAML configuration, considering the following precedence:

Configuration source precedence (for each and every agent): annotation < XML file < JSON file < YAML file

An example of a valid YAML file with two agents specified:

agents:
- class: com.mycompany.agents.Agent1
  type: timer
  interval: 30s
- class: com.mycompany.agents.Agent2
  type: cron
  interval: 0 0 * * SUN

Notes:

  • Any external file (XML, JSON, or YAML) is optional
  • If the YAML file is found (only one file allowed), then not all annotated agents need to be present in that file
  • If an annotated agent is found in the YAML file (matched by the class name), then the system shall use only configuration data from the YAML (in other words, no configuration from any other less-precedence source shall be used)
  • For every agent which configuration is overwritten using YAML, the system shall log the configuration source as being "YAML"
  • In case of exceptions parsing an agent via YAML, a WARNING log shall be generated, but the loading shall continue normally, considering the immediately lower-precedence configuration source (either JSON, XML, or annotation, as fallback)

Additional details

  • The code shall be developed in the issue/0005 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

Toggle statistic data processing

Enhancement/Feature request

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Enable/disable statistic data processing for an agent.

Describe alternatives you've considered
Not applicable.

Additional details

  • The code shall be developed in the issue/0015 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

Null Pointer Exception when no external configuration is supplied

Describe the bug
When none of .yaml,.json or .xml are supplied and we try to autowire a bean for AgentManager using AgentManager.defaultInstance() then a NullPointerException is thrown.
This happens because a container.getBean(..) is invoked in the fillAuxiliaryObjects() function call in ConfigurationHolder class and when none of the external configurations are present then getBean() returns null. This causes the following line of initialising agentsByClassName to throw a null pointer exceptin as the config is null.

Expected behavior
Even when no external configuration is supplied, a default instance of AgentManager should be wired with no agents and a global configuration. This is due to the fact that user may invoke scanPackages("..") programatically after a default instance is wired.

Additional context
Stack Trace:

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [net.obvj.agents.conf.ConfigurationHolder]: Constructor threw exception; nested exception is java.lang.NullPointerException: Cannot invoke "net.obvj.agents.conf.Configuration.getGlobalConfiguration()" because "config" is null at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:224) ~[spring-beans-5.3.16.jar:5.3.16] at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87) ~[spring-beans-5.3.16.jar:5.3.16] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1326) ~[spring-beans-5.3.16.jar:5.3.16] ... 45 common frames omitted Caused by: java.lang.NullPointerException: Cannot invoke "net.obvj.agents.conf.Configuration.getGlobalConfiguration()" because "config" is null at net.obvj.agents.conf.ConfigurationHolder.fillAuxiliaryObjects(ConfigurationHolder.java:96) ~[classes/:na] at net.obvj.agents.conf.ConfigurationHolder.<init>(ConfigurationHolder.java:61) ~[classes/:na] at net.obvj.agents.conf.ConfigurationHolder.<init>(ConfigurationHolder.java:55) ~[classes/:na] at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:na] at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[na:na] at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:na] at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[na:na] at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480) ~[na:na] at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:211) ~[spring-beans-5.3.16.jar:5.3.16] ... 47 common frames omitted

External configuration via XML

Enhancement

This enhancement introduces the possibility to set up agents' configurations, such as name, interval, and type via XML file.
So, for every annotated agent, the system shall search for an optional XML configuration, which will always have more precedence than the annotation configuration. In other words, the XML configuration, if available, will overwrite the original annotation parameters.

The agents' class name must be used to associate a unique agent between XML and annotation configuration sources.

An example of XML file:

<agents>
  <agent>
    <class>com.mycompany.agents.MyAgent</class>
    <type>timer</type>
    <interval>10s</interval> <!-- every 10 seconds -->
  </agent>
  <agent>
    <class>com.mycompany.agents.MyAgent2</class>
    <type>cron</type>
    <interval>0 0 * * SUN</interval> <!-- once a week, on Sundays, at 0h00 -->
  </agent>
<agents>

Notes:

  • The XML file is optional
  • If the XML file is found (only one file allowed), then not all annotated agents need to be present in that file
  • If an annotated agent is found in the XML file (matched by the class name), then the system shall use only configuration data from the XML (in other words, no configuration from any other less-precedence source shall be used)
  • For every agent which configuration is overwritten using XML, the system shall log the configuration source as being "XML"
  • In case of exceptions parsing an agent via XML, a WARNING log shall be generated, but the loading shall continue normally, considering the immediately lower-precedence configuration source (i.e., the annotation configuration will be used as a fallback, as no other configuration source is yet available)
  • The code shall be designed for extensibility, given the future enhancements in the roadmap (e.g.: allowing configuration via JSON and YAML too).

Additional details

  • The code shall be developed in the issue/0003 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

Confectory integration

Enhancement/Feature request

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Add confectory-datamapper-jackson2-* and remove boilerplate code present for configuration files loading.

Describe alternatives you've considered
Not applicable.

Additional details

  • The code shall be developed in the issue/0011 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

External configuration via JSON

Enhancement

This enhancement introduces the possibility to set up agents' configurations, such as name, interval, and type via JSON file.
So, for every annotated agent, the system shall search for an optional XML and JSON configuration, which will always have more precedence than the annotation configuration.

In other words, the XML configuration, if available, will overwrite the original annotation parameters. And the JSON configuration, if available, will overwrite either the annotation or the XML configuration parameters.

An example of a valid JSON file with two agents specified:

{
  "agents": [
    {
      "class": "com.mycompany.agents.Agent1",
      "type": "timer",
      "interval": "30s"
    },
    {
      "class": "com.mycompany.agents.Agent2",
      "type": "cron",
      "interval": "0 0 * * SUN"
    }
  ]
}

Configuration source precedence (for each and every agent): annotation < XML file < JSON file

Notes:

  • Both XML and JSON files are optional
  • If the JSON file is found (only one file allowed), then not all annotated agents need to be present in that file
  • If an annotated agent is found in the JSON file (matched by the class name), then the system shall use only configuration data from the JSON (in other words, no configuration from any other less-precedence source shall be used)
  • For every agent which configuration is overwritten using JSON, the system shall log the configuration source as being "JSON"
  • In case of exceptions parsing an agent via JSON, a WARNING log shall be generated, but the loading shall continue normally, considering the immediately lower-precedence configuration source (XML or annotation, as fallback)
  • The code shall be designed for extensibility, given the future enhancements in the roadmap (e.g.: allowing configuration via YAML too).

Additional details

  • The code shall be developed in the issue/0004 branch.

Quality criteria

The following criteria will be observed during the Code Review:

Code coverage

  • The produced code shall be secured by unit tests.
  • Test coverage shall remain the same or increase.

Documentation

  • All methods shall be documented with Javadoc, providing examples of usage.
  • Javadoc pages shall be compilable with no errors or warnings
  • README.md shall be updated if applicable

Renaming Suggestion of Method Names to Make Them More Descriptive

Renaming Suggestion of Method Names to Make Them More Descriptive


Description

We have developed a tool (NameSpotter) for identifying non-descriptive method names, and using this tool we find a non-descriptive method name in your repository:

/* Non-descriptive Method Name in src/main/java/net/obvj/agents/util/TimeInterval.java */
public static TimeInterval of (String input)
    {
        int digits = extractFirstDigitGroupFrom(input);
        String timeUnitDescription = extractFirstLetterGroupFrom(input);

        TimeUnit timeUnit = timeUnitDescription.isEmpty() ? TimeUnit.DEFAULT
                : TimeUnit.findByIdentifier(timeUnitDescription);

        return new TimeInterval(digits, timeUnit);
    }

We considered "of" as non-descriptive because it is too generic, and we can not infer the function of this method until we look into the method body or the comments above. We proposed renaming the method name to "parseString2TimeInterval". Consequently, when we look at this method name, we will be informed that this method is written for parsing a String input into a TimeInterval object.

Do you agree with the judgment?

  • If not, could you please leave your valuable opinion?

  • If you do agree, the relevant modification has been submitted as a PR, and thanks for your precious time to consider it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.