爱站网关键词密度查询,北京住房和城乡建设部官方网站,crm系统是什么意思啊,网站开发从零到后端 java ee这是我的小型Java EE 7复习系列的第二部分。 在进行了简要概述的第一篇介绍之后#xff0c;我决定请Arjan Tijms撰写有关Java EE 7中他最喜欢的后端新功能的信息。如果您关注Java EE领域#xff0c;您将会知道Arjan。 他是Java EE开发人员#xff0c;JSF和Secur… 后端 java ee 这是我的小型Java EE 7复习系列的第二部分。 在进行了简要概述的第一篇介绍之后我决定请Arjan Tijms撰写有关Java EE 7中他最喜欢的后端新功能的信息。如果您关注Java EE领域您将会知道Arjan。 他是Java EE开发人员JSF和Security EG的长期成员他与Bauke Scholtz 又名BalusC一起创建了OmniFaces 并帮助建立zeef.com 。 1.应用程序提供的管理对象 Java EE长期以来一直具有“管理对象”的概念。 这是一种在应用程序服务器上而不是由应用程序定义的资源。 对于某些类别的应用程序这是最佳做法而对于其他类别的应用程序则不是最佳做法。 Java EE 6通过引入DataSourceDefinition开始了一次小小的变革它允许应用程序定义自己的数据源。 Java EE 7通过MailSessionDefinitionJavaMail 1.5 ConnectionFactoryDefinitionAdministeredObjectDefinitionJCA 1.7和JMSConnectionFactoryDefinitionJMSDestinationDefinitionJMS 2.0对此进行了扩展。 实际上许多应用程序已经使用JavaMail的编程API来创建邮件会话而JCA的使用相对较少。 但是JMS的使用更加广泛并且缺少创建目的地队列和主题的EE兼容编程API。 这个看似很小的功能的重要性在于它可以在JMS历史上首次以完全标准的方式使用而无需在应用程序存档中使用特定于供应商的xml文件或在应用程序服务器中不需要特定于供应商的配置。 请注意这些应用程序提供的资源定义都没有将其余的应用程序代码牢固地绑定到这些应用程序。 该应用程序代码仍然仅看到JNDI名称并且不依赖于资源是通过标准注释标准XML文件专有XML文件还是应用程序服务器上的专有配置放置在JNDI中。 进一步阅读 在Java EE 7中自动配置JMS资源 2.默认资源 与应用程序提供的管理对象密切相关Java EE还引入了一些默认资源的概念。 在使用默认资源的情况下Java EE平台会提供特定类型的随时可用的资源。 Java EE 7引入了数据源的默认值平台的默认JMS连接工厂和默认线程池。 这些默认值的特征在于它们无法以任何标准化方式进行进一步配置。 您必须处理服务器提供的任何内容。 对于数据源这意味着您可以获得可以向其发送SQL的“内容”但是就性能甚至持久性而言没有进一步的保证尽管数据源访问的数据库可能完全基于内存但是实际上它几乎总是服务器特定目录中的文件。 对于JMS连接工厂您将获得到服务器默认JMS提供程序的连接。 由于JMS与SQL数据库不同它是Java EE的强制组成部分因此您通常对这里的功能非常了解。 例如如果所讨论的服务器是生产就绪服务器则默认的JMS提供程序实际上始终是生产就绪服务器。 最后一些实际资源例如ManagedExecutorService使您可以访问实质上是系统的默认线程池的资源。 可以使用与使用Java EE 6中的Asynchronous批注几乎相同的方式来使用此类线程池。您不完全知道该池中有多少个线程也不知道ManagedExecutorService是否由与Asynchronous相同的池支持但对于简单的即席多线程工作默认值通常就足够了。 默认资源的一个特别好的方面是在某些情况下您甚至不必说要使用默认资源。 例如如果您未指定JPA持久性单元的默认数据源那么默认数据源就很好。 进一步阅读 Java EE 7中的默认数据源更少的XML和更多的默认值 Java EE 7中的默认设置 3.提供的应用程序和便携式身份验证机制 除了上面提到的管理对象之外传统上必须在应用程序服务器端定义和配置的另一件事是身份验证机制和身份存储两者都有许多备用名称。 Servlet规范确实定义了4种标准化的身份验证机制应用程序可以通过其web.xml部署描述符FORMBASICDIGESTCLIENT-CERT从中选择但是并未对它们的实际类或接口进行标准化因此后来没有为自定义身份验证机制标准化任何API / SPI。 此外规范中没有关于存储呼叫者姓名/凭证/组的实际位置的任何内容。 就像DataSourceDefinition一样Java EE 6通过标准化用于身份验证机制的API / SPI以及用于从应用程序JASPIC 1.0中进行注册的编程API进行了一次小小的革命。 不幸的是JASPIC的Java EE 6版本有一些关键的遗漏这使得实际上很难使用这些可移植的身份验证机制。 Java EE 7中解决了其中最重要的问题。 就像应用程序提供的管理对象一样应用程序提供的身份验证机制不会将其余的应用程序代码绑定到这些对象上并且可以透明地将它们替换为容器提供的管理对象。 进一步阅读 Java EE 7的身份验证支持有哪些新功能 4.基于CDI的Transactional 在Java EE 7之前高级声明式事务是EJB的领域。 在此模型中EJB旨在用作平台提供的许多功能的通用外观。 尽管EJB从J2EE 1.4中的一项笨拙的重量级规范演变为Java EE 6中实际上相当轻量的规范但将一个规范用作外观的模型不再被认为是理想的模型。 Java EE 6在实际引入CDI方面带来了最大的变化而Java EE 7掀起了另一场小革命其他规范开始改为依赖CDI。 以此为基础一种bean类型的模型开始转换为作为基础的一种bean类型的竞争模型其他规范在此之上进行了扩展。 专门启用此功能的是JTA 1.2引入了Transactional和TransactionScoped。 这些基于Interceptors规范中的拦截器和CDI规范中的范围。 两者都主要适用于CDI bean。 改变模型的方式是在EJB中JTA在后台被隐式使用而在CDI中JTA在某种程度上是不可见的在后台使用CDI。 进一步阅读 JTA 1.2 –不再是您祖父的交易 Arjan ZEEF页面上的JTA 1.2 5.方法验证 Bean验证规范也许是Java EE中最通用的跨层规范之一。 Bean验证可以将验证约束施加到各种Bean上例如CDI Bean和JPA实体。 但是这些验证约束仅在字段级别有效并且通过在类级别扩展有效验证多个字段而起作用。 在Java EE 7中bean验证的适用性由于在方法上也放置了这样的约束因此被称为方法验证从而实现了巨大的飞跃。 更精确地现在可以将约束施加在方法的输入参数上以及方法的返回值上并且输入约束可以在单个参数上以及在多个参数上。 尽管在特定时刻验证了字段级约束例如当JPA实体管理器保留实体或在JSF中进行回发之后则每次通过任意代码调用方法时都会进行方法验证。在Java EE中当方法为在代理的CDI托管bean中并且确实通过代理访问了该方法。 进一步阅读 Bean验证1.1 Feature Spotlight –方法验证 Bean验证1.1在Arjan的ZEEF页面上 6.表达语言可以在任何地方使用 表达式语言是Java EE中使用的一种迷你脚本语言。 它具有悠久的历史从专门针对JSTL到本机并入JSP本机并入JSF以及后来在JSP和JSF之间统一。 在Java EE 7中这种表达语言取得了有史以来的最大飞跃成为完全独立的规范通常完全在JSP和JSF甚至Java EE之外。 这意味着可以在注释电子邮件模板配置文件等中使用表达语言。 就像在Java EE 6中引入CDI一样将来可以在许多其他规范中使用单独使用的表达语言。 进一步阅读 标准偏差Servlet环境中的表达语言3.0插图 Arjan ZEEF页面上的EL 3.0 7.大大简化的JMS API Java EE中较旧的规范之一是JMS它是关于异步消息传递的。 JMS也是很长一段时间自2002年以来就没有更新的规范之一尽管仍然令人惊讶但它的使用年龄确实开始有所显示。 借助JMS 2.0Java EE 7给JMS带来了最大的变化之一。 彻底简化的API。 这些简化的一部分使用了上面提到的默认资源但是它还利用了Java SE 7的自动关闭功能和许多智能默认值以最大程度地减少用户为处理诸如发送消息之类的事情而不得不管理和处理的对象数量。 。 进一步阅读 JMS 2.0中的新增功能第1部分易于使用 Arjan ZEEF页面上的JMS 2.0 8. JPA中的实体图 可以说Java EE中除CDI之外最重要的规范之一就是JPA。 无论Java EE应用程序是基于JSF的MVC还是基于JAX-RS的Web服务它们几乎总是具有一些持久性要求。 持久性的困难之一是确定什么是正确的数据量。 显然这不应太少但也不应太大因为这通常会带来很大的性能影响。 JPA的重要调整参数一直是特定关系的渴望和懒惰加载。 此选择主要在实体本身上进行结构化和硬编码。 这样做的问题是在不同情况下可能需要使用或多或少的数据的同一实体。 例如在所有用户的概述中您可能只想显示用户名而在详细视图中您还希望显示地址和其他联系方式。 在Java EE 7之前可以通过编写单独的查询而无需为每种情况获取太少或太多的数据来完成此操作。 虽然这解决了问题但它不是最佳的尤其是当它涉及大型查询时并不是最佳选择唯一的区别是为某个实体获取了多少关联数据。 在JPA 2.1中Java EE 7为此引入了实体图的概念。 通过一个命名的图现在可以确定是否需要以图样式概念来获取哪些数据。 这些图是分别定义的可以在运行时与许多不同的查询关联。 进一步阅读 JPA 2.1实体图–第1部分命名实体图 Arjan ZEEF页面上的JPA 2.1 9.访问托管线程池 上面在讨论默认资源时简要提到的是Java EE 7中提供了对默认线程池的访问。 实际上支持不仅限于此而且Java EE 7在此之后引入了整个规范。 Java EE规范的并发工具。 使用此规范您不仅可以获取该默认线程池还可以获取并使用单独的线程池。 这对于QoS用例非常重要特别是在将相互依赖的工作安排到同一池中的情况下可以防止大量死锁情况。 不幸的是由于无法以标准方式实际定义这些池因此在一定程度上限制了这些附加池的实际可用性。 这与本概述开头的“应用程序提供的管理对象”项有些矛盾。 尽管存在这个问题但对于有些较低级别的异步和并行编程此规范提供了很多选择。 CDI调整拦截器规格批处理 在Java EE 7中Interceptors规范从CDI分离出来为CDI铺平了道路使CDI可以更专注于成为Java EE的核心bean模型同时使拦截器在整个平台上更通用。 CDI本身并没有进行大修也没有获得真正的新功能而是获得了一些较小但非常受欢迎的功能例如更容易以编程方式获取Bean实例的方式以及在激活作用域和触发作用域时触发的事件。停用。 自动启用CDI无需bean.xml即可激活CDI应该是一个主要功能但是在实践中似乎用途有限。 如果没有bean.xml文件则仅扫描具有所谓“ bean定义注释”的bean尤其对于初学者而言这并不总是很清楚。 传统上Java EE主要处理通常运行时间较短的请求和响应。 有一个计时器服务可用于后台作业但这是一个相对基本的功能。 几乎没有任何作业管理检查点或重新启动的概念。 在Java EE中引入了一个全新的规范来专门解决这些问题。 Java Platform 1.0批处理应用程序规范。 这解决了在其中指定了作业的XML文件的问题这些文件本身包含执行实际顺序应用程序逻辑的所谓步骤。 进一步阅读 CDI 1.1 拦截器1.2 批次1.0 感谢Arjan抽出宝贵的时间来编译所有这些内容。 下一篇文章将介绍前沿技术的十大功能同时还将介绍一位知名的客座博客。 在此之前还有很多时间可以使用Java EE7。以下是一些资源可帮助您开始使用JBoss EAP 7和WildFly EAP 7 Alpha和Java EE 7入门 带有JBoss工具的OpenShift 3上的Java EE 7应用程序 GitHub上的Java EE 7示例 翻译自: https://www.javacodegeeks.com/2015/12/refresher-top-10-java-ee-7-backend-features.html后端 java ee
