Checkout Tools
  • last updated 50 mins ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ESB-28915] - updated log4j for logging to seperate files
[ESB-28915] - updated log4j for logging to seperate files
It appears that the AggregateFile Appender does not have the v4 aggregate services.

It appears that the AggregateFile Appender does not have the v4 aggregate services.

ESB-28915: [PRODUCT] Maintain logs by instance for Get parts services
ESB-28915: [PRODUCT] Maintain logs by instance for Get parts services
It looks like the FreePaid service, which is not an aggregate service, is going ot the AggregateFileAppender, but the Aggregate Services for V4 are not.

It looks like the FreePaid service, which is not an aggregate service, is going ot the AggregateFileAppender, but the Aggregate Services for V4 are not.

I think that logs from the V4 controller and the V4 Aggregate services will go to the SpringFileAppender. is that what we want?

I think that logs from the V4 controller and the V4 Aggregate services will go to the SpringFileAppender. is that what we want?

ESB-28735: get parts v4 controller hardcodes values for isAggregate in validate methods
ESB-28735: get parts v4 controller hardcodes values for isAggregate in validate methods
ESB-27909: [JAVA] Change all Java Services to use Spring Actuator for the health check
ESB-27909: [JAVA] Change all Java Services to use Spring Actuator for the health check
  • More
  • ESB-103
  • summarized and closed
should be esbuat1.genpt.net

should be esbuat1.genpt.net

should be esb2.genpt.net

should be esb2.genpt.net

Should be esb1.genpt.net

Should be esb1.genpt.net

ESB-27506: [JAVA] Migrate startup properties from startup scripts to YAML files - nsight-product availability/b2b
ESB-27506: [JAVA] Migrate startup properties from startup scripts to YAML files - nsight-product availability/b2b
  • More
  • ESB-24
  • finished reviewing
it is confusing to have a variable named V2 that is actually the V3 class .

it is confusing to have a variable named V2 that is actually the V3 class .

This is a good candidate for an Enum. It could go in the model package.

This is a good candidate for an Enum. It could go in the model package.

This is a good candidate for an Enum. It could go in the model package.

This is a good candidate for an Enum. It could go in the model package.

It would be more efficient to have 1 filter statement and 1 collect. For instance, .filter(s -> s.getDeliveryServiceType().compareToIgnoreCase(deliveryServiceType) == 0 && s.getDayOfTheWeek().compa...

It would be more efficient to have 1 filter statement and 1 collect. For instance,
.filter(s -> s.getDeliveryServiceType().compareToIgnoreCase(deliveryServiceType) == 0
&& s.getDayOfTheWeek().compareToIgnoreCase(dayOfWeek) == 0)
.collect(Collectors.toList());

Can we rename the name of the table to site_delivery_lead_time? Usually, table names are not plural. Could we change the order of the clustering key to delivery_service_type, day_of_week, reason_co...

Can we rename the name of the table to site_delivery_lead_time? Usually, table names are not plural.
Could we change the order of the clustering key to delivery_service_type, day_of_week, reason_code? I think this will be used more than the other way around during triage.

In this class we are still using v1 SplunkLogger.

In this class we are still using v1 SplunkLogger.

I see in some classes that we are still using v2 SplunkLogger, but in other classes, we are using v3.SplunkLogger. Do we need to have a v3? What's the difference?

I see in some classes that we are still using v2 SplunkLogger, but in other classes, we are using v3.SplunkLogger. Do we need to have a v3? What's the difference?