解决Uncaught (in promise) Error: Navigation cancelled from “/...“ to “/...“ with a new navigation.

解决

Uncaught (in promise) Error: Navigation cancelled from “/Search#1608911018888” to “/Search#1608911019245” with a new navigation.

这个错误是vue-router内部错误,没有进行catch处理,导致的编程式导航跳转问题,往同一地址跳转,或者在跳转的 mounted/activated 等函数中再次向其他地址跳转会报错。

pushreplace都会导致这个情况的发生

解决方法为在路由中进行如下配置:

import VueRouter from 'vue-router';
Vue.use(VueRouter);
//解决编程式路由往同一地址跳转时会报错的情况
const rop = VueRouter.prototype.push;
const ror = VueRouter.prototype.replace;
//push
VueRouter.prototype.push = function (location, onResolve, onReject) {
    if (onResolve || onReject) return rop.call(this, location, onResolve, onReject)
    return rop.call(this, location).catch(err => err)
};
//replace
VueRouter.prototype.replace = function (location, onResolve, onReject) {
    if (onResolve || onReject) return ror.call(this, location, onResolve, onReject)
    return ror.call(this, location).catch(err => err)
};


..............................

new Vue({
        el: '#q-app',
        router: router,
});

参考链接


Tab切换以及缓存页面处理的几种方式

前言

相信tab切换对于大家来说都不算陌生,后台管理系统中多会用到。如果不知道的话,可以看一下浏览器上方的标签页切换,大概效果就是这样。

1.如何切换

  1. 使用动态组件,相信大家都能看懂(部分代码省略)

    //通过点击就可以实现两个组件来回切换
    <button @click="changeView">切换view</button>
    <component :is="currentView"></component>
    
    import pageA from "@/views/pageA";
    import pageB from "@/views/pageB";
    
    computed: {
      currentView(){
          return this.viewList[this.index];
      }
    },
     methods: {
      changeView() {
        this.index=(++this.index)%2
      }
    }

    注:这个多用于单页下的几个子模块使用,一般切换比较多使用下面的路由

  2. 使用路由(这个就是配置路由的问题了,不作赘述)

2.动态生成tab

一般UI框架给我们的tab切换都像是上面的那种,需要自己写入几个tab页之类的配置。但是我们如果想要通过点击左边的目录来生成一个tab页并且可以随时关闭呢(如下图)?

只需要给路由一个点击事件,把你的路由地址保存到一个列表,渲染成另一个平铺的tab目录即可

假设你的布局是这样,左边的目录,上边的tab,有字的是页面

<menu>
  <menu-item v-for="(item,index) in menuList" :key="index" @click="addToTabList(item.path)">
    <router-link :to="item.path">{{item.name}}</router-link>
  <menu-item>
</menu>
<template>
  <menu class="left"/>//menu代码部分如上
  <div class="right">
    <tab-list>
      <tab-item v-for="(item,index) in tabList" :key="index">
        <router-link :to="item.path">{{item.name}}</router-link>
        <icon class="delete" @click="deleteTab"></icon>
      </tab-item>
    </tab-list>
    <page-view>
      <router-view></router-view>//这里是页面展示
    </page-view>
  </div>
</template>

以上代码并非实际代码,只提供一个大概的思路。至于addToTabListdeleteTab怎么做就是数组方法的简单pushsplice操作了。为了效果好看,我们可能还需要一些tabactive样式,这里不作演示。

3.缓存组件

仅仅是做tab切换,远远是不够的,毕竟大家想要tab页就是要来回切换操作,我们需要保存他在不同tab里操作的进度,比如说填写的表单信息,或者已经查询好的数据列表等。
那么我们要怎么缓存组件呢?
只需要用到vue中的keep-alive组件

3.1 keep-alive

  • <keep-alive>是Vue的内置组件,能在组件切换过程中将状态保留在内存中,防止重复渲染DOM。
  • <keep-alive> 包裹动态组件时,会缓存不活动的组件实例,而不是销毁它们。
  • <keep-alive> 与 <transition>相似,只是一个抽象组件,它不会在DOM树中渲染(真实或者虚拟都不会),也不在父组件链中存在,比如:你永远在 this.$parent 中找不到 keep-alive 。

注:不能使用keep-alive来缓存固定组件,会无效

//无效
<keep-alive>
  <my-component></my-component>
</keep-alive>

3.2 使用

3.2.1 老版本vue 2.1之前的使用

<keep-alive>
    <router-view v-if="$route.meta.keepAlive"></router-view>
</keep-alive>
<router-view v-if="!$route.meta.keepAlive"></router-view>

需要在路由信息里面设置router的元信息meta

export default new Router({
  routes: [
    {
      path: '/a',
      name: 'A',
      component: A,
      meta: {
        keepAlive: false // 不需要缓存
      }
    },
    {
      path: '/b',
      name: 'B',
      component: B,
      meta: {
        keepAlive: true // 需要被缓存
      }
    }
  ]
})

3.2.2 比较新而且简单的用法

  • 直接缓存所有组件/路由
<keep-alive>
    <router-view/>
</keep-alive>
<keep-alive>
   <component :is="view"></component>
</keep-alive>
  • 使用include来处理需要缓存的组件/路由

include有几种用法,可以是数组,字符串用标点隔开,也可以是正则,使用正则的时候需要使用v-bind来绑定。

<keep-alive include="['a','b']">//缓存name为a,b的组件
<keep-alive include ="a,b">//缓存name为a,b的组件
<keep-alive :include="/^store/">//缓存name以store开头的组件
    <router-view/>//可以为router-view
    <component :is="view"></component>//也可以是动态组件
</keep-alive>
  • 使用exclude来排除不需要缓存的路由

include正好相反,在exclude里的组件不会被缓存。用法类似,不作赘述

3.2.3 一种比较奇怪的情况

当页面跳转方式有A->CB->C两种,但是我们从A到C的时候,不需要缓存,从B到C的时候需要缓存。这时候就要用到路由的钩子结合老版本用法来实现了。

export default {
  data() {
    return {};
  },
  methods: {},
  beforeRouteLeave(to, from, next) {
    to.meta.keepAlive = false; // 让下一页不缓存
    next();
  }
};
export default {
  data() {
    return {};
  },
  methods: {},
  beforeRouteLeave(to, from, next) {
    // 设置下一个路由的 meta
    to.meta.keepAlive = true; //下一页缓存
    next();
  }
};

3.3 缓存组件的生命周期函数

缓存组件第一次打开的时候,和普通组件一样,也需要执行createdmounted等函数。
但是在被再次激活被停用时,这几个普通组件的生命周期函数都不会执行,会执行两个比较独特的生命周期函数。

  • activated
    这个会在缓存的组件重新激活时调用
  • deactivated
    这个会在缓存的组件停用时调用

参考链接


certbot-auto不再支持所有的操作系统,新的ssl证书方法

最近在一台服务器执行letsencrypt-auto命令出现错误:

$ sudo ./certbot-auto 
Your system is not supported by certbot-auto anymore.
certbot-auto and its Certbot installation will no longer receive updates.
You will not receive any bug fixes including those fixing server compatibility
or security problems.
Please visit https://certbot.eff.org/ to check for other alternatives.
Saving debug log to /var/log/letsencrypt/letsencrypt.log

系统不再被支持!!!

查看certbot(https://github.com/certbot/certbot/releases)

2021年1月的更新日志:

●certbot-auto was deprecated on all systems. For more information about this
change, see
https://community.letsencrypt.org/t/certbot-auto-no-longer-works-on-debian-based-systems/139702/7.

可知:

certbot-auto不再支持所有的操作系统!根据作者的说法,certbot团队认为维护certbot-auto在几乎所有流行的UNIX系统以及各种环境上的正常运行是一项繁重的工作,加之certbot-auto是基于python 2编写的,而python 2即将寿终正寝,将certbot-auto迁移至python 3需要大量工作,这非常困难,因此团队决定放弃certbot-auto的维护。

既然如此,现在我们还能继续使用certbot吗?certbot团队使用了基于snap的新的分发方法。

1. 环境
操作系统:CentOS 7

Webserver:Nginx

2. 安装letsencrypt
2.1. 安装letsencrypt之前,需要先安装snaps

a. 先安装epel

$ yum install epel-release

b. 安装snapd

$ yum install snapd

c. 启用snapd.socket

$ systemctl enable --now snapd.socket

d. 创建/var/lib/snapd/snap/snap之间的链接。

$ ln -s /var/lib/snapd/snap /snap

e. 退出账号并重新登录,或者重启系统,确保snap启用。

f. 将snap更新至最新版本。

$ sudo snap install core

$ sudo snap refresh core

2.2. 卸载已安装的certbot

如果之前在系统上已经部署过certbot,则需要先将其进行卸载。

a. 卸载certbot

$ yum remove certbot

b. 根据certbot安装位置删除相关文件。

$ rm /usr/local/bin/certbot-auto

c. 删除certbot附加软件包。

$ rm -rf /opt/eff.org/certbot

2.3. 安装certbot

a. 通过snap安装certbot

$ snap install --classic certbot

b. 创建/snap/bin/certbot的软链接,方便certbot命令的使用。

$ ln -s /snap/bin/certbot /usr/bin/certbot

3. letsencrypt的使用
3.1. 获取证书。

a. 生成证书。

确保nginx处于运行状态,需要获取证书的站点在80端口,并且可以正常访问。

$ certbot certonly --nginx --email xxx@mail.com -d a.do.com -d b.do.com

b. 更新nginx配置并重启nginx

3.2. 更新证书。

$ certbot renew

ubuntu系统的话,使用如下命令方式安装:

$ sudo snap install --classic certbot

参考链接


certbot-auto不再支持所有的操作系统,新的ssl证书方法

JavaScript正则表达式匹配成对出现的标记(平衡组-balanced group)

XRegExp.matchRecursive(str, left, right, [flags], [options])

Requires the XRegExp.matchRecursive addon, which is bundled in `xregexp-all.js`.

Returns an array of match strings between outermost left and right delimiters, or an array of objects with detailed match parts and position data. An error is thrown if delimiters are unbalanced within the data.

Parameters:
  • `str` {`String`}
    String to search.
  • `left` {`String`}
    Left delimiter as an XRegExp pattern.
  • `right` {`String`}
    Right delimiter as an XRegExp pattern.
  • [`flags`] {`String`}
    Any combination of XRegExp flags, used for the left and right delimiters.
  • [`options`] {`Object`}
    Lets you specify `valueNames` and `escapeChar` options.
Returns:
  • {`Array`}
    Array of matches, or an empty array.

Example

// Basic usage
let str = '(t((e))s)t()(ing)';
XRegExp.matchRecursive(str, '\\(', '\\)', 'g');
// -> ['t((e))s', '', 'ing']

// Extended information mode with valueNames
str = 'Here is <div> <div>an</div></div> example';
XRegExp.matchRecursive(str, '<div\\s*>', '</div>', 'gi', {
  valueNames: ['between', 'left', 'match', 'right']
});
/* -> [
{name: 'between', value: 'Here is ',       start: 0,  end: 8},
{name: 'left',    value: '<div>',          start: 8,  end: 13},
{name: 'match',   value: ' <div>an</div>', start: 13, end: 27},
{name: 'right',   value: '</div>',         start: 27, end: 33},
{name: 'between', value: ' example',       start: 33, end: 41}
] */

// Omitting unneeded parts with null valueNames, and using escapeChar
str = '...{1}.\\{{function(x,y){return {y:x}}}';
XRegExp.matchRecursive(str, '{', '}', 'g', {
  valueNames: ['literal', null, 'value', null],
  escapeChar: '\\'
});
/* -> [
{name: 'literal', value: '...',  start: 0, end: 3},
{name: 'value',   value: '1',    start: 4, end: 5},
{name: 'literal', value: '.\\{', start: 6, end: 9},
{name: 'value',   value: 'function(x,y){return {y:x}}', start: 10, end: 37}
] */

// Sticky mode via flag y
str = '<1><<<2>>><3>4<5>';
XRegExp.matchRecursive(str, '<', '>', 'gy');
// -> ['1', '<<2>>', '3']

参考链接


解决Android自定义键盘与系统键盘交替出现会出现弹跳闪烁问题

在Android应用的某个界面上,配置出现使用自定义键盘,系统键盘的相邻的两个独立的输入框,当用户在两个输入框之间来回切换的时候,会出现弹跳闪烁问题。

这个问题发生的原因是,系统键盘的关闭是异步的,我们需要等待系统键盘关闭后再显示我们的键盘,否则会出现系统键盘关闭的过程中,我们自定义键盘同时出现,出现两者叠加的瞬间状态。

解决方法参考下面的代码:

import android.annotation.SuppressLint;
import android.content.Context;
import android.os.Bundle;
import android.os.Handler;
import android.os.Looper;
import android.os.ResultReceiver;
import android.support.annotation.NonNull;
import android.support.annotation.Nullable;
import android.util.AttributeSet;
import android.view.MotionEvent;
import android.view.View;
import android.view.inputmethod.InputMethodManager;
import android.widget.EditText;

import java.lang.reflect.Method;

public class PasswordEdit extends EditText {
    // 主线程通知调用结果
    private final static Handler handler = new Handler(Looper.getMainLooper());

    public PasswordEdit(@NonNull final Context context) {
        super(context);
        initPasswordEdit(context);
    }

    public PasswordEdit(@NonNull final Context context, @Nullable final AttributeSet attr) {
        super(context, attr);
        initPasswordEdit(context);
    }

    public PasswordEdit(@NonNull final Context context, @Nullable final AttributeSet attr, int defStyleAttr) {
        super(context, attr, defStyleAttr);
        initPasswordEdit(context);
    }

    public PasswordEdit(@NonNull final Context context, @Nullable final AttributeSet attrs, int defStyleAttr, int defStyleRes) {
        super(context, attrs, defStyleAttr, defStyleRes);
        initPasswordEdit(context);
    }

    private void doStartPasswordEditKeyBoard(@NonNull final Context context) {
        final InputMethodManager imm = ((InputMethodManager) context.getSystemService(Context.INPUT_METHOD_SERVICE));
        //关闭键盘,如果键盘正在显示,或者正在关闭,等待键盘关闭完成的通知
        final boolean wait = imm.hideSoftInputFromWindow(this.getWindowToken(), 0, new ResultReceiver(handler) {
            @Override
            protected void onReceiveResult(final int resultCode, @Nullable final Bundle resultData) {
                // 收到通知时,需要检查一下焦点是否已经移走,如果已经不在了,就不需要弹出键盘了
                if (PasswordEdit.this.hasFocus()) {
                    // 此处需要递归处理,原因为异步状态下,收到通知的时候,键盘可能已经处于弹出状态了
                    doStartPasswordEditKeyBoard(context);
                }
            }
        });
        // 键盘已经处于隐藏状态
        if (!wait) {
            StartPasswordKeyBoard();
        }
    }

    // 阻止系统键盘在输入框获得焦点的时候自动弹出
    private void disableShowSoftInputOnFocus() {
        if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.LOLLIPOP) {
            this.setShowSoftInputOnFocus(false);
        } else {
            try {
                Method method = EditText.class.getMethod("setShowSoftInputOnFocus", Boolean.TYPE);
                method.setAccessible(true);
                method.invoke(this, false);
            } catch (Exception e) {
                //e.printStackTrace();
            }
        }
    }

    @SuppressLint("ClickableViewAccessibility")
    private void initPasswordEdit(@NonNull final Context context) {
        this.setLongClickable(false);
        this.disableShowSoftInputOnFocus();
        this.setOnTouchListener(new OnTouchListener() {
            @Override
            public boolean onTouch(@NonNull final View view, @NonNull final MotionEvent motionEvent) {
                doStartPasswordEditKeyBoard(context);
                return true;
            }
        });
    }

    public void StartPasswordKeyBoard() {
        //显示自定义的密码键盘的代码
    }
}

注意,在继承实现自定义的密码键盘弹窗的时候,可以参考Android源代码中的PopWindow的处理逻辑。如果是使用`WindowManager.addView` 的方式添加到窗口,那么在关闭View的时候需要使用 `WindowManager.removeViewImmediate`来移除,否则一样会出现与输入法弹窗冲突。 代码同样参考PopWindow。

另外,如果自定义输入法的View增加了 FLAG_NOT_TOUCH_MODAL 属性,那么会导致事件穿透到输入法窗口下面的Window,如果点击区域恰好有个 EditText,则可能诱发系统输入法的弹出。如果自定义键盘通过监听 ACTION_OUTSIDE来关闭窗口,那么会出现系统键盘先弹出,输入法的View再关闭的奇怪流程。因此这种情况下,我们需要参考PopWindow来监听ACTION_DOWN事件。

如下图:

监测系统键盘是否已经关闭,参考代码如下:

ViewCompat.setWindowInsetsAnimationCallback(this, new WindowInsetsAnimationCompat.Callback(WindowInsetsAnimationCompat.Callback.DISPATCH_MODE_CONTINUE_ON_SUBTREE) {
    @NonNull
    @Override 
    public WindowInsetsCompat onProgress(@NonNull WindowInsetsCompat insets, @NonNull List<WindowInsetsAnimationCompat> runningAnimations) {
        return insets;
    }

    @Override 
    public void onEnd(@NonNull WindowInsetsAnimationCompat animation) {
        if (animation.getTypeMask() == WindowInsetsCompat.Type.ime()) {
            final WindowInsetsCompat insets = ViewCompat.getRootWindowInsets(View.this);
            if(null != insets) {
                // 此处判断键盘是否已经被关闭,已经关闭返回true,否则返回false
                insets.isVisible(WindowInsetsCompat.Type.ime());
            }
        }
    }
});

上面的代码依赖

androidx.core:core:1.6.0

参考链接


Tomcat 10运行项目出现java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener的问题

Tomcat 9更新到Tomcat 10,运行项目,发现报错:

java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
        at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:151)
        at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2470)
        at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:866)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1370)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1224)
        at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:540)
        at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:521)
        at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4589)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5121)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:743)
        at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1865)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:288)
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
        at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
        at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:428)
        at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:376)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:288)
        at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
        at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
        at java.management/com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
        at java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
        at java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
        at java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
        at java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
        at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
        at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
        at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
        at java.base/java.lang.Thread.run(Thread.java:832)
        Caused by: java.lang.ClassNotFoundException: javax.servlet.ServletContextListener
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1401)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1224)
        ... 56 more

项目无法正常启动,看官方提示才知道,原来javax改成了jakarta了,所以找不到对应的包文件。我就不对项目进行修改,用回Tomcat 9就挺好的。

继续阅读Tomcat 10运行项目出现java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener的问题

Jakarta EE - Java EE的终结者

什么是 Jakarta EE

Jakarta EE并不是新技术,他的前身就是大家熟悉的Java EE,老一辈的程序员可能还记得J2EE,是的,他们都是同一个东西,至于为什么会改来改去,这里面就有很多故事了。

1998年12月,SUN公司发布了JDK1.2,开始使用Java 2 这一名称,第二年Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商共同制订了一个基于Java组件技术的企业应用系统开发规范,名字很自然就取为Java 2 Platform Enterprise Edition简称J2EE,后面的事情大家也知道,JDK版本升的很快,J2EE名称如果跟着Java版本走必然会给开发人员造成困惑不利于该技术的推广,终于在2006年,SUN公司在发布Java 5后正式将J2EE改名为Java EE(Java Platform, Enterprise Edition),很多早期j2ee开发者虽然现在用的是最新的java ee标准但他们还是认为自己在用j2ee,当然,只是名称的改变并没有给开发者带来什么麻烦,相比之下下面这个就是要命。

2009年,Oracle宣布收购SUN,Java相关技术自然归Oracle所有,在2017年,Oracle 宣布开源 Java EE 并将项目移交给 Eclipse 基金会,但Oracle移交的很不痛快,提了很多要求,其中就包括不能再使用Java EE这个名称,虽然有点无理但Eclipse基金会还是接受了这个要求并且改名为Jakarta EE,经历了从j2ee到java ee的改名再经历一次似乎也无所谓,但要命的是Oracle要求Jakarta EE不能修改javax命名空间,这个就意味着java ee移交后代码就此封版,如果想修改代码,不好意思,请另起炉灶,所以,Oracle你移交的意义在哪?

那么从Java EE到Jakarta EE会给企业带来什么影响?下面我们一起分析。

名称的转变

这个对企业影响不大,对开发者影响也不大,你可以愉快用着Jakarta EE最新标准的同时跟同事说java ee发布新版本了。

命名空间的转变

如果你是用Maven进行开发,那么Java EE的依赖是这么定义的

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>8.0.1</version>
    <scope>provided</scope>
</dependency>

我们可以看到groupId是javax,并且源码的结构如下:

.
└── javax
    ├── annotation
    ├── batch
    ├── decorator
    ├── ejb
    ├── el
    ├── enterprise
    ├── faces
    ├── inject
    ├── interceptor
    ├── jms
    ├── json
    ├── mail
    ├── management
    ├── persistence
    ├── resource
    ├── security
    ├── servlet
    ├── transaction
    ├── validation
    ├── websocket
    ├── ws
    └── xml

所有的源码都定义在javax.*这个路径下,根据Oracle的要求Jakarta EE不能修改javax命名空间,那么Jakarta EE只能将代码中javax修改为jakarta,因此最新版本Jakarta Maven描述是长这样的:

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>9.0.0-RC2</version>
    <scope>provided</scope>
</dependency>

源码目录:

.
└── jakarta
    ├── activation
    ├── annotation
    ├── batch
    ├── decorator
    ├── ejb
    ├── el
    ├── enterprise
    ├── faces
    ├── inject
    ├── interceptor
    ├── jms
    ├── json
    ├── jws
    ├── mail
    ├── persistence
    ├── resource
    ├── security
    ├── servlet
    ├── transaction
    ├── validation
    ├── websocket
    ├── ws
    └── xml

可以看到除了顶层包名称不一样下面的定义都一样,那么包路径更改会有什么影响?影响非常大。

  • 所有java ee应用服务器比如Weblogic,GlassFish等如果要支持最新版本的jakarta ee就必须修改源码重新编译,并且如果支持了jakarta ee就无法支持java ee,也就是无法向前兼容,Tomcat虽然只是Servlet容器但是Servlet本身就是Java EE的一部分,因此也逃不过修改的命运。据说Tomcat可以对应用进行自动代码转换以支持jakarta,因此在不远的将来我们可以看到各种奇技淫巧去兼容jakarta,是不是想起了被IE支配的恐惧。
  • 企业如果需要用到jakarta ee最新特性必须修改现有代码,修改并不复杂,就是把代码中import javax.*替换为import jakarta.*,修改完重新编译打包部署,似乎很简单,事实上没那么简单。
  • 对企业来说,保持应用服务器处于最新版本是必须的,因为新版本可能修复了老版本的漏洞,并且性能上也可能有一定的提升,但如果升级应用服务器的同时也要修改源码代码就很大,修改的成本,带来的风险并不是所有企业都能接受的。
  • 假设修改了一个应用,那么就需要部署到新版本应用服务器上,由于新服务器不兼容老应用因此需要运维两套应用服务器,运维成本提高,两套应用服务器也可能涉及license问题,不知道各厂商要怎么解决这个问题。

总之企业面临两难的境地,要么升级改系统源码,要么保持不变不升级,要么部分升级运维两套应用服务器,刀刀都要命。

未来

在如今各种诸如spring boot框架的包装下,在应用层面已经找不到Java EE的影子了,这些框架完全有能力抛弃jakarta自己实现,对于这些框架来说,跟随jakarta的意义似乎不大。对于企业来说,拥抱spring boot已经大势所趋,Java EE又搞出这么一件事,只会更加坚定企业转型的决心。对于开发者来说,Java EE已经是古董级的技术,Spring Boot不香吗,有什么理由去用jakarta EE。Oracle似乎也是看到了Java EE行将就木就索性移交出去,还能换取Eclipse基金会的董事会席位,但我还是看不懂Oracle对Java EE致命的这一刀目的何在,weblogic和中间件也是Oracle重要的两块业务,这两块业务都依赖Java EE,这么做只会两败俱伤。

参考


Android扩大View点击范围

Android4.0设计规定的有效可触摸的UI元素标准是48dp,转化为一个物理尺寸约为9毫米。7~10毫米,这是一个用户手指能准确并且舒适触摸的区域。

如下图所示,你的UI元素可能小于48dp,图标仅有32dp,按钮仅有40dp,但是他们的实际可操作焦点区域最好都应达到48dp的大小。

1 触屏手机点击区域的小秘密

为使小的UI区域获得良好的触摸交互,根据View的特性,目前碰到了两种情况:

1.如ImageView,设置其padding值,可触摸区域将向外扩展;

2.如Button,设置其padding值,可触摸区域不变,其内内容显示区域向内压缩;

情况1的控件,可直接设置其padding值达到目的,如 android:padding="10dp"  

情况2的控件,可使用TouchDelegate动态修改其触摸区域,达到扩大点击范围的效果

/**
 * 扩大View的触摸和点击响应范围,最大不超过其父View范围
 *
 * @param view
 * @param top
 * @param bottom
 * @param left
 * @param right
 */
public static void expandViewTouchDelegate(final View view, final int top,
                                           final int bottom, final int left, final int right) {

    ((View) view.getParent()).post(new Runnable() {
        @Override
        public void run() {
            Rect bounds = new Rect();
            view.setEnabled(true);
            view.getHitRect(bounds);

            bounds.top -= top;
            bounds.bottom += bottom;
            bounds.left -= left;
            bounds.right += right;

            TouchDelegate touchDelegate = new TouchDelegate(bounds, view);

            if (View.class.isInstance(view.getParent())) {
                ((View) view.getParent()).setTouchDelegate(touchDelegate);
            }
        }
    });
}

采取此种方法的两点注意:

1、若View的自定义触摸范围超出Parent的大小,则超出的那部分无效。
2、一个Parent只能设置一个View的TouchDelegate,设置多个时只有最后设置的生效。

若需要恢复该View的触摸范围:

/**
 * 还原View的触摸和点击响应范围,最小不小于View自身范围
 *
 * @param view
 */
public static void restoreViewTouchDelegate(final View view) {

    ((View) view.getParent()).post(new Runnable() {
        @Override
        public void run() {
            Rect bounds = new Rect();
            bounds.setEmpty();
            TouchDelegate touchDelegate = new TouchDelegate(bounds, view);

            if (View.class.isInstance(view.getParent())) {
                ((View) view.getParent()).setTouchDelegate(touchDelegate);
            }
        }
    });
}

使用TouchDelegate扩大View的触摸响应范围是一种比较灵活的方法,有时可与设置padding的方式结合使用。

更新

======

后期实际开发中发现,使用post runnable的方式去设置Delegate区域大小的原因是,如该View师在Activity的OnCreate()或Fragment的OnCreateView()中绘制,此时UI界面尚未开始绘制,无法获得正确的坐标;

若将此法应用在ListView的getView()中绘制每个ItemView时,则Delegate的设置将部分失效,原因是ListView的绘制较特殊,可能无法获取到部分还未绘制出的View的正确坐标。解决方案具体可参考以下参考阅读所列。

 

参考阅读:通过自定义View的方式,及某些其他情况的处理:

1.《Android使用TouchDelegate增加View的触摸范围》 http://blog.csdn.net/sgwhp/article/details/10963383

2.《ListView Tips & Tricks #5: Enlarged Touchable Areas》 http://cyrilmottier.com/2012/02/16/listview-tips-tricks-5-enlarged-touchable-areas/

3.《Extend touchable areas #Android》 https://plus.google.com/u/0/+JulienDodokal/posts/8zoV3RQvReS

参考链接


Openmediavault 4.x升级到5.x

移除旧版本的openmediavault并升级Debian系统,如下:

$ sudo apt update && apt upgrade -y && apt dist-upgrade -y

$ sudo apt-get purge openmediavault-*

$ sudo sed -i "s/stretch/buster/g" /etc/apt/sources.list

$ sudo sed -i "s/stretch/buster/g" /etc/apt/sources.list.d/*

$ sudo sed -i "s/arrakis/usul/g" /etc/apt/sources.list.d/*

$ omvextras="/etc/apt/sources.list.d/omvextras.list"
$ test -f "${omvextras}" && sudo sed -i "/[Dd]ocker/d" ${omvextras}

$ sudo sed -i "s/<mtu><\/mtu>/<mtu>0<\/mtu>/g" /etc/openmediavault/config.xml

$ sudo rm -f /var/cache/openmediavault/archives/Packages

$ armbian="/etc/apt/sources.list.d/armbian.list"
$ test -f "${armbian}" && echo "deb http://apt.armbian.com buster main buster-utils" | sudo tee ${armbian}

$ sudo apt-get update && apt-get dist-upgrade -y --allow-unauthenticated

$ sudo apt --fix-broken install

$ sudo reboot

重新安装openmediavault:

$ sudo apt-get purge openmediavault-omvextrasorg resolvconf

$ wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

$ sudo apt-get update && apt-get dist-upgrade -y

$ sudo reboot

$ sudo apt autoremove -y

$ sudo apt autoclean -y

目前还是推荐下载之后,完全重新安装 openmediavault 5.x 这样操作更简单。

另外,要求系统磁盘空间至少比内存多 2GB, 否则会在安装的使用出现磁盘空间不足的情况,这个现象的原因在于安装的时候,会自动根据内存创建对应大小的交换分区。有个简单的方式就是安装系统的时候,换个小一点的内存,安装完成后再换回来,可以解决这个情况下安装失败的问题。

参考链接


保持函数依赖的分解

大部分是对一个关系模式分解成两个模式的考察,分解为三个以上模式时无损分解和保持依赖的判断比较复杂,考的可能性不大,因此我们只对“一个关系模式分解 成两个模式”这种类型的题的相关判断做一个总结。

以下的论述都基 于这样一个前提:
R是具有函数依赖集F的关系模式,(R1 ,R2)是R的一个分解。

首先我们给出一 个看似无关却非常重要的概念:属性集的闭包 。
令α为一属性集。我们称在函数依赖集F下由α函数确定的所有属性的集合为F下α的闭包,记为α+ 。
下面给出一个计算α+的算法,该算法的输入是函数依赖集F和属性集α,输出存储在变量result中。
算法一:
result:=α;
while(result发生变化)do
    for each 函数依赖β→γ in F do
    begin
        if β⊆result then result:=result∪γ;
    end

属性集闭包的计 算有以下两个常用用途:
·判断α是否为超码,通过计算α+(α在F下的闭包),看α+ 是否包含了R中的所有属性。若是,则α为R的超码。
·通过检验是否β⊆α+,来验证函数依赖是否成立。也就是说,用属性闭包计算α+,看它是否包含β。

看一个例子 吧,2005年11月系分上午37题:

● 给定关系R(A1,A2,A3,A4)上的函数依赖集F={A1→A2,A3→A2,A2→A3,A2→A4},R的候选关键字为________。
(37)A. A1  B. A1A3  C. A1A3A4  D. A1A2A3

首先我们按照上 面的算法计算A1+ 。
result=A1,
由于A1→A2,A1⊆result,所以result=result∪A2=A1A2
由于A2→A3,A2⊆result,所以result=result∪A3=A1A2A3
由于A2→A4,A2⊆result,所以result=result∪A3=A1A2A3A4
由于A3→A2,A3⊆result,所以result=result∪A2=A1A2A3A4

通过计算我们看 到,A1+ =result={A1A2A3A4},所以A1是R的超码,理所当然是R的候选关键字。此题选A 。

好了,有了前面的铺垫,我们进入正题。

 

无损分解的判断 。
如果R1∩R2是R1或R2的超码,则R上的分解(R1,R2)是无损分解。这是一个充分条件,当所有的约束都是函数依赖时它才是必要条件(例如多值依赖 就是一种非函数依赖的约束),不过这已经足够了。

保持依赖的判断 。
如果F上的每一个函数依赖都在其分解后的某一个关系上成立,则这个分解是保持依赖的(这是一个充分条件)。
如果上述判断失败,并不能断言分解不是保持依赖的,还要使用下面的通用方法来做进一步判断。
该方法的表述如下:
算法二:
对F上的每一个α→β使用下面的过程:
result:=α;
while(result发生变化)do
    for each 分解后的Ri
        t=(result∩Ri)+ ∩Ri
        result=result∪t

这里的属性闭包是在函数依赖集F下计算出来的。如果result中包含了β的所有属性,则函数依赖α→β。分解是保持依赖的当且仅当上述过程中F的所有依 赖都被保持。

 

下面给出一个例题,2006年5月系分上午43题:

●设关系模式R<U, F>,其中U={A, B, C, D, E},F={A→BC,C→D,BC→E,E→A},则分解ρ={R1(ABCE),R2(CD)}满足 (43) 。
(43) A.具有无损连接性、保持函数依赖
              B.不具有无损连接性、保持函数依赖
              C.具有无损连接性、不保持函数依赖
              D.不具有无损连接性、不保持函数依赖

先做无损链接的判断。R1∩R2={C},计算C+。

Result=C
由于C→D,C∈result,所以result=result∪D=CD
可见C是R2的超码,该分解是一个无损分解。

再做保持依赖的 判断。
A→BC,BC→E, E→A都在R1上成立(也就是说每一个函数依赖左右两边的属性都在R1中),C→D在R2上成立,因此给分解是保持依赖的。

选A。

再看一个复杂点的例题。2007年5月数工40-41题。

●给定关系模式R<U, F>,U={A, B, C, D, E},F={B→A,D→A,A→E,AC→B},其候选关键字为 
(40) ,则分解ρ={R1(ABCE),R2(CD)}满足 (41) 。
(40) A.ABD
              B.ABE
              C.ACD
              D.CD
(41) A.具有无损连接性、保持函数依赖
              B.不具有无损连接性、保持函数依赖
              C.具有无损连接性、不保持函数依赖
              D.不具有无损连接性、不保持函数依赖

看见了吧,和前 面一题多么的相像!
对于第一问,分别计算ABCD四个选项的闭包,
(ABD)+ = { ABDE }
(ABE)+ = { ABE }
(ACD)+ = { ABCDE }
(CD)+ = { ABCDE }
选D。

再看第二问。
先做无损链接的判断。R1∩R2={C},计算C+。

result=C
因此C既不是R1也不是R2的超码,该分解不具有无损分解性。

再做保持依赖的 判断。
B→A,A→E,AC→B在R1上成立,D→A在R1和R2上都不成立,因此需做进一步判断。
由于B→A,A→E,AC→B都是被保持的(因为它们的元素都在R1中),因此我们要判断的是D→A是不是也被保持。

对于D→A应用 算法二:
result=D
对R1,result∩R1=ф(空集,找不到空集的符号,就用这个表示吧),t=ф,result=D
再对R2,result∩R2=D,D+ =ADE ,t=D+ ∩R2=D,result=D
一个循环后result未发生变化,因此最后result=D,并未包含A,所以D→A未被保持,该分解不是保持依赖的。

选D。

参考链接