Spring boot version compatibility issue when using actuator in Alpha

[zhang_lei]

1. I want to extend management based on Actuator in Alpha，But the custom  of 
Actuator is not compatible in spring boot 1.x and spring boot 2.x
I think it can be solved by adding  alpha-spring-boot-compatibility module, 
alpha-spring-boot-compatibility contains alpha-spring-boot-1-starter and 
alpha-spring-boot-2-starter. 


Customize Alpha Endpoint in spring boot 1.x
package org.apache.servicecomb.pack.alpha.server.actuate.endpoint;

import org.apache.servicecomb.pack.alpha.core.NodeStatus;
import org.apache.servicecomb.pack.alpha.core.actuate.endpoint.AlphaStatus;
import org.springframework.boot.actuate.endpoint.Endpoint;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@ConfigurationProperties(prefix = "endpoints.alpha")
@Component
public class AlphaEndpoint implements Endpoint {

  public static final String END_POINT_ID = "alpha";

  private AlphaStatus alphaStatus = new AlphaStatus();

  @Override
  public String getId() {
return END_POINT_ID;
  }

  @Override
  public boolean isEnabled() {
return true;
  }

  @Override
  public boolean isSensitive() {
return false;
  }

  @Override
  public AlphaStatus invoke() {
alphaStatus.setNodeType(NodeStatus.TypeEnum.MASTER);
return alphaStatus;
  }

}


Customize Alpha Endpoint in spring boot 2.x
package org.apache.servicecomb.pack.alpha.server.actuate.endpoint;

import org.apache.servicecomb.pack.alpha.core.NodeStatus;
import org.apache.servicecomb.pack.alpha.core.actuate.endpoint.AlphaStatus;
import org.springframework.boot.actuate.endpoint.annotation.Endpoint;
import org.springframework.boot.actuate.endpoint.annotation.ReadOperation;
import org.springframework.context.annotation.Configuration;


@Configuration
@Endpoint(id = "alpha")
public class AlphaEndPoint {

  private AlphaStatus alphaStatus = new AlphaStatus();

  @ReadOperation
  public AlphaStatus endpoint() {
alphaStatus.setNodeType(NodeStatus.TypeEnum.MASTER);
return alphaStatus;
  }
}


Add dependencies in Alpha server，it version same ${spring.boot.version}

  org.apache.servicecomb.pack
  alpha-spring-boot-starter
  ${spring.boot.version}


2. Additional features
Same Actuator Endpoint access path with spring boot 1.x and spring boot 2.x
Customized ActuatorEndpoint compatible spring boot 2.x actuator in spring boot 
1.x, You can access it via http://127.0.0 .1/actuator/xxx when 
using spring boot 1.x

Define ActuatorEndpoint class
package org.apache.servicecomb.pack.alpha.server.actuate.endpoint;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.actuate.endpoint.Endpoint;
import org.springframework.stereotype.Component;

import java.util.List;

@Component
public class ActuatorEndpoint implements Endpoint> {

  @Autowired
  private List endpoints;

  @Override
  public String getId() {
return "actuator";
  }

  @Override
  public boolean isEnabled() {
return true;
  }

  @Override
  public boolean isSensitive() {
return false;
  }

  @Override
  public List invoke() {
return endpoints;
  }
}
Define ActuatorMvcEndpoint class
package org.apache.servicecomb.pack.alpha.server.actuate.endpoint.mvc;

import 
org.apache.servicecomb.pack.alpha.server.actuate.endpoint.ActuatorEndpoint;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.actuate.endpoint.Endpoint;
import org.springframework.boot.actuate.endpoint.mvc.EndpointMvcAdapter;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.*;

import java.util.Optional;
import java.util.function.Predicate;
import java.util.function.Supplier;

import static java.util.Optional.ofNullable;

@Component
public class ActuatorMvcEndpoint extends EndpointMvcAdapter {

  private final ActuatorEndpoint delegate;

  @Autowired
  public ActuatorMvcEndpoint(ActuatorEndpoint delegate) {
super(delegate);
this.delegate = delegate;
  }

  @RequestMapping(value = "/{endpoint}", method = RequestMethod.GET)
  @ResponseBody
  public Object endpoint(@PathVariable("endpoint") String id, 
@RequestParam(required = false) Boolean enabled,
 @RequestParam(required = false) Boolean sensitive) {
Predicate isEnabled =
endpoint -> matches(endpoint::isEnabled, ofNullable(enabled));

Predicate isSensitive =
endpoint -> matches(endpoint::isSensitive, ofNullable(sensitive));

Predicate matchEndPoint =
endpoint -> matches(endpoint::getId, ofNullable(id));

return this.delegate.invoke().stream()
.filter(matchEndPoint.and(isEnabled.and(isSensitive)))
.findAny().get().invoke();
  }

  private  boolean matches(Supplier supplier, Optional value) {
return !value.isPresent() || supplier.get().equals(value.get());
  }
}


张 磊

部门: 亿阳信通IT运维支撑产品线
地址: 北京市海淀区杏石口路99号西山赢府商务中心2410 
邮编: 

Re: [DISCUSSION] create a new project servicecomb-samples

[Mohammad Asif Siddiqui]

Hi All,  
  
It's good relocate all the samples of servicecomb to a common place but all the 
current projects should have clear pointers on their main Readme to re-direct 
user to samples, also samples can be arranged properly in the new project using 
some indexing so that it's easy for new users to find out the correct samples. 
Just my Opinion.  
  
Regards  
Asif

On 2019/01/21 07:26:42, "bismy"  wrote: 
> Hello all, 
> 
> 
> I suggest the create a new project servicecomb-samples to hosting code of 
> servicecomb examples. Currently we have samples in each project, but is not 
> enough for reasons:
> 
> 
> 1. Create new examples will make project huge and hard to distribute. 
> 2. We can not create examples based on released version.
> 3. Lack of examples to show integrated features use both of java-chassis and 
> saga features. 
> 
> 
> Any ideas?

Re: Release note page

[Mohammad Asif Siddiqui]

Hi All,  
  
In my opinion its good to use project wiki for accounting the changes done 
which needs to be there in Release Notes, I think all the project committers 
who merges the PR can take a call while merging that if those changes need to 
be mention in the Release Notes, if yes then we can use a tag in PR like 
'mentionInReleaseNotes' and later on when we make a Release then we can pick up 
the notes using the tag and on another hand Committer themselve can add it in 
wiki after the PR merge. Just my Opinion.  

  
Regards  
Asif

On 2019/01/26 01:09:01, Willem Jiang  wrote: 
> Hi team,
> 
> As we using JIRA to track the issues or new features,  it's easy for
> us to generate the release note by press a button in JIRA.  But it
> could be a challenge for us to write down the upgrade notes or specify
> the API changes in the release note.  So I suggest we use wiki to
> track this kind of document and publish it into our website once the
> release is complete.
> 
> We can use the github project wiki [1](the committers has the right)
> or cwiki[2] (Please let me know your cwiki account, I can give you the
> write right)
> Any thought?
> 
> [1]https://github.com/apache/servicecomb-java-chassis/wiki
> [2]https://cwiki.apache.org/confluence/display/SERVICECOMB
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 

[discuss][java-chassis] change core mechanism from strong type to weak type

[wjm wjm]

currently, core mechanism is strong type
that caused to generate class dynamically in many special classloader, it's
dangerous:

   - need to generate almost all business classes in edge, maybe cause jvm
   meta overflow
   - unable to support advanced features of swagger, such as allOf
   - caused some unnecessary data model convert


so we need to change core mechanism from strong type to weak type, we had
disscussed this before.

the new problem is,  because the two mechanism is not compatible, we must
make decisions about:

   - if plan it to be version 2.0.0
   - if we create branch for it
   - if not create branch, then same functions will have two implements,
   how to named the package
   - if create branch, then i will replace old  implement directly,  that
   cause compile problems

any suggestion?