osgi | 易学教程

Configure Response object for Rest Services inside a Jersey-Grizzly server, in OSGi container (CORS error prevention with Jersey 1x)

阅读更多关于 Configure Response object for Rest Services inside a Jersey-Grizzly server, in OSGi container (CORS error prevention with Jersey 1x)

问题 The last couple of days, I have been struggling with an issue. I've created a rest service hosted by a Grizzly server inside an OSGi container. Everything is working perfectly at this point. Now, I want to add a header in every response.Not so complex or illogical right? Yet, I can't find a way to do it. I have tried to: 1) Get the response object inside the rest functions as this question suggests (pretty textbook when you are not under OSGi). 2) Add a handler using the code above (in this

开发OpenDaylight组件的完整流程

阅读更多关于开发OpenDaylight组件的完整流程

在前面介绍学习了OpenDaylight的几个重要模块后，这里再来介绍下完整开发一个模块的过程。 OSGI的bundles提供被其他OSGI组件调用的服务。这个教程中展示的是Data Packet Service去解析数据包（其接口为 IDataPacketService）。这个小组件不能提供函数供其他bundles调用，但是可以让我们很好的理解为了接收到一个 Packet-in消息事件，必须要实现 IListenDataPacket 接口。当Packet-in消息到达控制器，SAL模块就会通知实现这些接口的组件。详细过程请见 http://www.frank-durr.de/?p=84 实验室的婷婷学姐翻译了此篇文章，就直接贴过来了，供大家学习译文：在这个教程里，我会详细解释如何为opendaylight开发一个OSGI组件来实现常规的网络控制逻辑。与REST 接口不同，当一个packet到达并在交换设备流表中失配的时候，将会触发一个packet-in事件，OSGI组件接收packet-in事件。因此，为了实现流响应式编程，OSGI组件是研究OpenDaylight一个很好的切入口。即使是对于有经验的java程序员，开发OSGI组件的学习曲线也是相当陡峭的，OpenDaylight使用十分强大的开发工具，例如Maven和OSGI、这些程序架构都十分的复杂

浅谈OpenDaylight的二次开发

阅读更多关于浅谈OpenDaylight的二次开发

OpenDaylight作为一款开源SDN网络控制器，依托于强大的社区支持以及功能特性，成为了目前主流的SDN网络控制器开发平台。在比较稳定的OpenDaylight Helium版本中，已经为开发者提供了大量的网络管理功能与二次开发接口。但是由于OpenDaylight架构复杂以及开发工具的多样化，造成了二次开发思路不够清晰的问题。本文旨在为读者梳理出一条比较清晰的OpenDaylight二次开发路线，降低OpenDaylight的二次开发难度。一、 OpenDaylight架构简析要想清晰的看到OpenDaylight为我们提供了什么，最直观的方式就是对OpenDaylight架构图进行梳理，如图1：图1 如大家所知道的那样，OpenDaylight的结构层次从下到上依次划分为数据平面（包括物理交换设备与虚拟交换设备等）、南向接口与协议插件、控制平面（包括核心控制部分与相关服务）、上层网络应用与服务。数据平面设备的相关技术开发已经超出了OpenDaylight二次开发范畴，因此我们的目光限定在南向协议与插件、控制器服务与上层应用的开发。总体来说，OpenDaylight的二次开发可以分为以下三个层面：基于OpenDaylight REST APIs的上层网络应用开发基于SAL内核相关服务的控制器组件与上层网络应用开发

为什么它有典型FaaS能力，却是非典型FaaS架构？

阅读更多关于为什么它有典型FaaS能力，却是非典型FaaS架构？

阿里妹导读：FaaS—Function as a service，函数即服务。它是2014年由于亚马逊的AWS Lambda的兴起，而被大家广泛认知。FaaS能力是NBF中的一项非常重要的能力，NBF是一个非典型的FaaS架构，但是具备了典型的FaaS能力。文章将详细介绍NBF的FaaS容器架构、服务发布、服务路由和强大的Serverless能力以及NBF-FaaS在阿里大促期间的实践心得。 1.NBF NBF (New-Retail Business Framework) 是供应链中台基础技术团队研发的新零售服务开放框架，提供了标准化业务定义、快捷服务开发和生态开放的能力，旨在为生态伙伴提供一整套完整的新零售PaaS和SaaS的解决方案。 2.FaaS 2.1定义 FaaS是Serverless的一种典型形式，由 Serverless平台提供负载均衡、高可用、自动扩缩容、服务治理等最佳实践，将这些最佳实践对 Developer 透明化，进一步缩短 Developer 从想法到产品的时间，降低开发成本，同时保障 Developer 开发的服务的可靠性。通过事件驱动的方式，开发者的Function通过Event有效触发，比如 HTTP 请求、消息事件等。 2.2典型架构 Event Sources Function 事件驱动的集合； Function Instances

素小暖讲JVM：第九章类加载与执行子系统的案例与实战

阅读更多关于素小暖讲JVM：第九章类加载与执行子系统的案例与实战

本系列是用来记录《深入理解Java虚拟机》这本书的读书笔记。方便自己查看，也方便大家查阅。欲速则不达，欲达则欲速！第九章类加载与执行子系统的案例与实战代码编译的结果从本地机器码转变为字节码是存储格式发展的一小步，却是编程语言发展的一大步。一、案例分析 1、tomcat：正统的类加载器架构主流的java web服务器，如tomcat、jetty、weblogic、websphere等服务器，都实现了自定义的类加载。因为一个功能健全的web服务器，要解决以下问题：（1）部署在同一个服务器上的两个web应用程序所使用的java类库可以实现相互隔离。服务器应当保证两个应用程序的类库可以互相独立使用。（2）部署在同一个服务器上的两个web应用程序所使用的java类库可以互相分享。如果部分类库不能分享，虚拟机的方法区就会很容易出现过度膨胀的风险。（3）服务器需要尽可能的保证自身的安全不受部署的web应用程序影响。基于安全考虑，服务器所使用的类库应该与应用程序的类库互相独立。（4）支持JSP应用的web服务器，大多数需要支持hotswap功能。我们知道，JSP文件最终要编译成java class才能由虚拟机执行，但JSP文件由于其纯文本存储的特性，运行时修改的概率远远大于第三方类库或程序自身class文件。由于存在上述问题，在部署web应用时

Why am I getting this “split package” warning?

阅读更多关于 Why am I getting this “split package” warning?

问题 I'm building a .kar-file, but when I run mvn package I'm getting this error: [INFO] --- maven-bundle-plugin:2.4.0:bundle (default-bundle) @ common --- [WARNING] Bundle se.eman.path.to.my.package:common:bundle:1.0.0-SNAPSHOT : Split package, multiple jars provide the same package:com/sun/xml/bind/v2 Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning Package found in [Jar:jaxb-impl, Jar:jaxb-core] Class path [Jar:., Jar:camel-core

Best way to load dynamically routes in Apache Camel

阅读更多关于 Best way to load dynamically routes in Apache Camel

问题 we have developped application based on Karaf and Apache Camel. While our application is entirely based on bundles ( OSGI ) we are also loading the Camel context ( and its' Route Contexts ) on startup, whcih would mean that we have defined some static routes. My question is. Is there a way to dynamically LOAD routes while the application is running without the need to reread the Camel Context as this will reset/restart the already existing routes. The same would apply to already created

Best way to load dynamically routes in Apache Camel

阅读更多关于 Best way to load dynamically routes in Apache Camel

OSGI - CDI / is it usable right now ? [Oct 2012]

阅读更多关于 OSGI - CDI / is it usable right now ? [Oct 2012]

问题 I'm quite new to Java EE 6 and OSGI concept, and i'm quite excited about it... The most exciting feature is the dynamic dependancy injection at execution time. I've seen some really great presentation where the application is ajaxly updated when a bundle is activated or unactivated, i like that way of decoupling the application in modules and updated it at run time ... Second though, i'm quite boring about XML configuration files, i think Java EE 6 with javax.inject and others annotations is

OSGI - CDI / is it usable right now ? [Oct 2012]

阅读更多关于 OSGI - CDI / is it usable right now ? [Oct 2012]

订阅 osgi