Is it possible to use Nashorn (the new JavaScript engine for Java8) together with each of the three Java 8 compact profiles?
Yes, you can use Nashorn in all compact profiles. This is explicitly documented in the compact profiles for embedded documentation:
Compact1 Profile APIs
Similar to the legacy Connected Device Configuration (CDC) with the Foundation Profile, secure sockets layer (SSL), logging, and scripting language support, including Javascript. When configured with the minimal JVM, the compact1 profile APIs have a static footprint of about 12MB.
Each compact profile is a superset of the previous one, so by virtue of being usable in compact1, Nashorn is also usable in compact2 and compact3.
As further evidence, bug JDK-8027532 was filed and resolved to ensure Nashorn doesn't use any classes outside of compact1.
Note that there is no requirement for JVMs to provide any particular script engine. Thus while Nashorn is compatible with all compact profiles, a particular JVM may not make it available.
Related
Currently there are so many suggested steps that have been posted for excluding log4j-core library from dependency or upgrading to the latest (above version 2.15) version according to Spring Blog . Are there any recommended tools that can be used for protecting spring application deployed in Google App Engine or Pivotal Cloud Foundry(PCF) for protecting instead of patching them for redeployment?
Another necessary question is, does it make my application(microservice spring application) to be vulnerable if it uses another microservice for some of its service if it depends on another microservice and if that microservice already uses vulnerable version of log4j-core?
In regard to your first question, you can set an environment variable in order to disable the replacement lookups in log4j:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Please note that this only works for log4j >= 2.10.
I believe you can set environment variables in PCF without having to redeploy the service (of course, a restart would be needed), so no new release would be needed. See: https://docs.pivotal.io/pivotalcf/2-3/devguide/deploy-apps/environment-variable.html and https://cli.cloudfoundry.org/en-US/v6/set-env.html
In order to see whether your spring-boot application is vulnerable to the exploit, you could use a spring-boot test I created for that purpose: https://github.com/chilit-nl/log4shell-example - You could test your application with and without the environment variable, to see if it has any effect (assuming that your application currently is vulnerable).
Short answer to your first question is may be. You can protect your application/service by using rules in WAF to discard the ${jndi://ldap pattern. However, there are so many mutations of this (base64 encoding etc.) that it will not be foolproof. If you are worried about dependencies, you should set the JVM Parameter and redeploy your app to prevent the lookup as a workaround.
Regarding your 2nd question - the answer is yes if the the 2nd micro service is being passed the same input and it's logging.
Can a Java 6 application work on Webpshere 8.5 if the nodes are built using Java 7? I have an EAR which was developed using Java6 and deployed on Websphere 8.5 using EA but the Webservice always gives 404.
Thanks.
It appears that that no support is provided for Java SE 6 in that version of WebSphere.
From the online documentation for WebSphere 8.5.5 (not sure if this is the version you are using tho')
Notice: Java SE 6 is being removed from service. Java SE 8 is the
recommended Java SDK because it provides the latest features and
security updates. You can continue to use Java SE 6, but no service
can be provided after the end of the support date, which might expose
your environment to security risks.
In fact, it appears that not even Java SE 7 is supported in this version of WebSphere either
There is a confusion here about the meaning of "version" and how it applies to JavaEE applications:
There is the version of the JVM which is selected to run the server.
There is the JavaEE specification level used to encode XML documents (web.xml, application.xml, ejb-jar.xml, etc) which are within an application.
There is the JavaEE specification level which is supported by the server.
There is the java compiler level which is set for classes packaged within an application.
There is, technically speaking, no specific version associated with an application. That an application is at Java 7 can mean "the classes of the application were compiled to java7", or, "the XML descriptors are set to the versions available to JavaEE7", or, "the function of the application requires a container which supports JavaEE7".
A key detail is that when running with WebSphere, its the server which decides to which JavaEE specification the application is run, not any feature of the application.
I'm guessing that in the original question, "Java 6 application" means the application was compiled to java6 and that the application features are limited to those available in java6. That should work on all of WebSphere v7.0, v8.0, v8.5, and v9.0 (at all service levels).
There are some complications to consider when using a distributed topology (having a DMGr node and more than one application server nodes). A frequent complication is that one or more of the application server nodes is at a lower version than the DMgr node. This is a supported scenario (with some limits on how big of a version difference is supported). The scenario is typical when a topology (a collection of federated nodes) is being migrated gradually from a particular WebSphere version to a higher version, and during the migration a mixture of node versions is available. When this is the case, the DMgr tracks the version of the application server nodes and constrains processing of the application to ensure the deployment is valid to all of the application server nodes to which the application is deployed.
Since the JavaEE level is set by the application server version, and since, generally, higher versions of the application server implement higher JavaEE levels, applications can function differently when migrated between application server versions. Whether this is the case for this question cannot be known without looking in more detail at the exact failure which is occurring.
I'm having trouble undrstanding the difference about both platforms?
Both seem to offer an environment for deploying and managing applications.
First I thought app servers use OSGi under the hood, I don't think so now but I see large AS (jboss, glassfish, websphere, etc) use OSGi.
What's the big picture?
Thank you
There is (to some extend) an overload of the term "application".
OSGi is a runtime environment (and development model) for modular Java applications. The term "application" in this case can be really, really low level. For example, an application server can be considered such an "application".
Application servers are also a runtime environment (and development model) for Java applications. However, the term "application" in this case typically refers to a higher level application type (eg., web applications). Application servers typically include a rich set of higher functionality and programming APIs for building web applications (Servlets), persisting data into databases (JPA) and clustering capabilities. Most application servers these days are composed of modules (eg., core, servlet engine, EJB container, etc.). Some application servers use OSGi under the covers. Others have their own modular runtime environment which also offers OSGi capabilities.
But it's also possible to develop higher level applications (such as web applications) directly using only OSGi runtime environment. However, an OSGi framework itself does not include any of the additional functionality. It has to be assembled yourself. There are some "distributions" that include a framework and several modules.
What is the best choice for an open source Enterprise-level application server when using Java 6 and Spring 3.1? Glassfish or JBOSS? Looking for good support e.g. online documentation, features, ease of use and set up, good performance, security, scalability, high availability features etc. that an enterprise would require. Enterprise being a large commercial or government client.
Are you using EJBs? If not, I would recommend jetty. jetty is a very light-weight container for doing most of the exploration/testing you would want to do in a project. Another plus that jetty delivers is that it is configured with only the most basic features enabled/configured by default.
Are you using Maven? If so, I would also recommend jetty-maven-plugin. In the past, I've had some success with using the jetty-maven-plugin for local testing on a previous project.
I have been trying to understand a bit more about the wider picture of OSGi without reading thru the entire specification. As with so many things, the introduction to what OSGi actually is was probably written by someone who had been working on it for a decade and perhaps wasn't best placed to put themselves in the mindset of someone who knows nothing about it :-)
Looking at Felix's example DictionaryService, I don't really understand what is going on. Is OSGi a distinct instance of a JVM into which you load bundles which can then find each other?
Obviously it is not just this because other answers on StackOverflow are explicit that OSGi can solve the dependency problem of a distributed system containing modules deployed within distinct JVMs (plus the FAQ keeps talking about networks).
In this latter case, how does a component running in one JVM interact with another component in a separate JVM? Can the two components "use" each other as if they were running within the same JVM (i.e. via local method calls), and how does OSGi manage the marshalling of data across a network (do you have to use Serializable for example)?
Or does the component author have to use some other distinct mechanism (either provided by OSGi or written themselves) for communication between remote components?
Any help much appreciated!
Yes, OSGi only deals with bundles and services running on the same VM. However, one should note that it is a distinct feature of OSGi that it facilitates running multiple applications (in a controlled way and sharing common modules) on the same JVM at all.
When it comes to accessing services outside the clients JVM, there is currently no standardized solution. Paremus Infiniflow and the derived open-source project Newton use an SCA approach. The upcoming 4.2 release of the OSGi specs will address one side of the problem, namely how to use generic distribution software in such a way that it can bring remote services into the client's JVM.
As somebody mentioned R-OSGi, this approach also deals with the other side of the problem, being how to manage dependencies between distributed OSGi frameworks. Since R-OSGi is not generic distribution software but explicitly deals with the lifecycle issues and dependency management of OSGi bundles.
As far as I know, OSGi does not solve this problem out of the box. There are OSGi-bundles, for example Remote OSGi, which allow the programmer to distribute services across a network.
Not yet, i think it's being worked on for the next release.
But some companies have already implemented distributed osgi. One i'm aware of is Paremus' Infiniflow (http://www.paremus.com/products/products.html). At linkedin they are also working on this. More info here: Building Linkedin next gen architecture with osgi and here: Matt raible: building linkedin next gen architecture
Here's a summary of the changes for OSGI 4.2: Some thoughts on the OSGi R4.2 draft, There's a section on RFC-119 dealing with distributed OSGi.
AFAIK, bundles are running in the same JVM, but are not loaded using the same class loader (that why you can use two different versions of the same bundle at the same time).
To interact with components in another JVM, you must use a network protocol such as rmi.
The OSGi alliance is working on a standard for distributed OSGi:
http://www.osgi.org/download/osgi-4.2-early-draft2.pdf
There even is an early Apache implementation of this new standard:
http://cxf.apache.org/distributed-osgi.html
#Patriarch24
The accepted answer to this question would seem to indicate otherwise (unless I'm misreading it). Also, taken from the FAQ:
The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring a restart
(Emphasis my own). Although in the same FAQ it describes OSGi as in-VM.
Why am I so confused about this? Why is such a basic question about a decade-old technology not clear?
The original problem of OSGI was more related to distribution of code (and then configuration of bundle) than to distribution of execution.
People looking at distributed components are rather looking towards SCA
The "introduction" link is not really an intro, it is a FAQ entry. For more information, see http://www.osgi.org/About/WhatIsOSGi Not hard to find I would think.
Anyway, OSGi is an in-VM SOA. That is, the OSGi Framework is about what happens inside the VM, it provides a framework for structuring your application inside the VM so you can built it too a large extent from components. So the core has nothing to do with distribution, it is completely oblivious of who implements the services, it just provides a mechanism for modules to meet each other in a loosely coupled way.
That said, the µService model reifies the joints between the modules and it turns out that you can build support on top of the framework that provides distribution to the other components. In the last releases we specified some mechanisms that make this standardized in the core and provide a special service Remote Service Admin that can manage a distributed topology.
If you are looking for a distributed OSGi centric Cloud runtime - then the Paremus Service Fabric ( https://docs.paremus.com/display/SF16/Introduction ) provides these capabilities.
One or more Systems each consisting of a number of OSGi assemblies (Blueprint or Declarative Services) can be dynamically deployed and maintained across a population of OSGi runtime Frameworks (Knopflerfish, Felix or Equinox).
A light weight RSA remote framework is provided which provides Service discovery by default using DDS (a seriously good middleware messaging technology) - (thought ZooKeeper and other approach can be used). Currently supported re-moting protocols include RMI and Avro.
Regards
Richard