Can I expect that I replace the Java .jar files and client-side .js files of version 2.4 or 2.5 of CometD in an existing software that is running fine, with the same files in 2.9.1 and it all runs the same?
1- Are the API of CometD exactly the same on all 2.x versions?
2- Is there an upgrade guide that I can use?
Also, I noticed that on the client side, CometD 2.4/2.5 is not AMD and is a single file, but on 2.9.1 it is AMD-based. Is there a single .js file that contains all client-side CometD code?
You can expect upgrades from 2.4/2.5 to 2.9.x to be either without problems, or requiring very little changes, so yes, it should be typically be a drop-in replacement.
While you're upgrading, I suggest to move to CometD 3. You can find here the migration guide from CometD 2.x.
CometD 2.9.x is AMD compliant, and the single file you should include in your HTML is typically org/cometd.js along with a binding for a toolkit (either jquery or dojo).
If you use extensions, you should add also those, see for example http://docs.cometd.org/3/reference/#_primer, or if you don't want to use Maven, this other section.
Follow also the tutorials, that should get you going.
Full documentation link.
Related
Is it possible to do what "mvn jetty:run" does, ie. run it against an extracted webapp and auto-reload/auto-restart the webapp if any of the extracted files have been changed?
Beware! I'm NOT talking about updated WAR files and auto-deploying them. My IDEs currently update the class files directly inside the "extracted" webapp file structure.
Context: I'm wondering what (freely licensed, ie apache/lgpl, not CDDL/GPL) Java EE 7 solution provides the fastest roundtrip times for developing test units against the full stack/bugfixing.
I'm also thinking about continuing to use Jetty 9.4, maybe with openejb, because I'm not using most of the JavaEE features anyways. I'm not really a big fan of IoC/DI because if you try to avoid scanning overhead, you put configuration into XML, whereas setting up an embedded server programmatically is strongly typed and cleaner IMHO (remember jetty.xml? programming Java using XML, wtf...). I also don't like JSTL/JSP etc. because templates feel like PHP and j2html seems much more Java-like to me.
But what I want is JPA transaction handling/connection pools for my Jersey servlets. Currently I'm doing that inside a RequestListener, and a more seamless support seems preferable, though not at the cost of being able to run a full stack jetty embedded server in my unit tests without much hassle.
Update
I'm using a simple BASH script using inotifywait now. It simply uses Glassfish's and WildFly's RESTful admin consoles for redeploy:
https://github.com/jjYBdx4IL/snippets/blob/master/bash/jee_autodeploy.sh
It doesn't even deploy the war, instead it simply deploys the build directory. It should be fast enough for most use cases. And if your app grows too large and increases reload times beyond a certain point, one should probably start thinking about refactoring it into multiple modules anyways.
You could try using OpenLiberty, which was released today and is the core (Java EE 7 complaint) subset of WebSphere Liberty. It comes with an eclipse plugin known as "WebSphere Developer tools" and is under the EPL-1.0 license.
http://openliberty.io/
Can I use Fortify to scan scala-code or the generated java (jar) files ? I know that I can do the jar option technically but are there any known challenges with respect to the generated java code?
Fortify SCA now officially supports Scala (since December 2017).
Adding this support was a collaborative project between Lightbend and Micro Focus.
I did most of the engineering work on the Lightbend side, writing a compiler plugin that translates Scala code to an intermediate form that Fortify understands. Micro Focus added Scala-specific security rules and made any necessary adjustments to the Fortify back end. (They also made sure that existing Java rules also worked for equivalent Scala code, when appropriate.)
See:
https://www.lightbend.com/blog/developing-secure-scala-applications-with-fortify-for-scala (45 minute webinar)
https://lightbend.com/fortify (form to ask Lightbend sales for more info)
https://developer.lightbend.com/docs/fortify/current/ (technical documentation)
Note that Fortify SCA is commercial software and so is the new Scala plugin. To use them, you must
have a Fortify SCA license (or use Fortify on Demand)
also be a Lightbend subscriber
I saw a response from James Roper (Play) to this question.
https://groups.google.com/forum/#!topic/play-framework/MtatDozyDjg
Basically he says that any issues that could be found by a static code analysis tool are a mistake in an API and should be fixed. JAVA cannot do this because of backwards compatibility.
I have tested scala code using Fortify SCA engine 3.8, 4.21. The Fortify found no issues. If I recall correctly, I saw a lot of warning during translation stage, so I assume that Fortify does not have native parser for the scala code.
For our ERP platform (NetSuite) customization code rests in the Cloud. We (different entities) can directly make changes to it but there is no source control available to us in cloud.
It is possible to fetch the code files through a SOAP API.
I was wondering if it is possible to get the files through API using Apache ANT and shove into TFS/SVN?
I am not familiar with Apache ANT so I do not know the capabilities of ANT that if it can fetch any info through API?
(you can also suggest any better approach to source control the code in cloud)
Ant has several third party task plugins for version control tasks. Plus, you can always use the <exec/> task to build an equivalent command line checkout. However, I do not recommend people use Ant to fetch versions from your version control system. This ends up being a chicken v. egg issue.
Your build script is in version control. You need to fetch it in order to run Ant against it. If you're fetching your build script, why not the rest of your project?
Once you checked out your project in a working directory, and want to do an update, why not let Ant do the update? Because your build script is also version controlled. Doing an update and build at the same time could have you running the wrong version of your build script against your build.
Maybe you're going to check in the files that were modified by the build system. Not a good idea. You should rarely, if ever, check in files you built. If you need them, rebuild them. Built files are usually binary in nature, and can vary greatly from one version to another. In most cases, your version control system will be checking in completely new versions of the built object instead of using diff format. That takes up a lot of room in your version control system.
Even worse, you can't diff the built objects, so you can't really verify their content or trace their history. And, built objects tend to age very quickly. Something built last month is already obsolete. With in a year, the vast majority of the information in your version control system will be nothing but obsolete binary, and very little stored is useful code.
Besides, your version control system has nothing to do with building your files. Imagine between Release 2.1 and Release 2.2, you change version control systems from Subversion to Git. Now, a bug in Release 2.1 needs to be fixed, and you need to create Release 2.1.1. Your checkout code in your build scripts will no longer work.
If you're using NetSuite IDE, you're using Eclipse, and Eclipse is great at handling version control. Eclipse can handle both SVN and TFS (although I don't know why anyone would use TFS). Eclipse tracks file changes quite nicely. In fact, Eclipse gets confused when you change files behind its back (like you do an update outside of Eclipse).
Let Eclipse handle your version control issues. It presents a common interface to almost all version control systems. This way, your build system can handle the builds.
I'm not sure what other requirements you might have, but if you use the NetSuite IDE (Eclipse + bundled plugin), you can use it to pull and push files to NetSuite. And then you can use any source control system you like (we use SVN, for instance).
Is it possible to send a javascript command to a site and determine the GWT version running in the browser? The reason I ask is because our QA folks are certifying our software and need a way to look at the version running without taking our word for it by looking at the IDE.
I know that I can do java -jar gwt-dev.jar, but normally we do not deploy that with the software.
The built-in GWT linkers generate a $gwt_version variable in the *.cache.* files.
Assuming you don't have other frames in your app, your GWT app will be in the first frame so you can then get the GWT version used to compile it with frames[0].$gwt_version.
We are using SpringSource-TC-Server and we are considering upgrading to java7. (Currently using java6).
We have not seen any reports on SpringSource-TC-Server not working well with java7 but we do not know of any name worthy projects that have migrated to such an environment.
I'm looking for answer(s) about the following:
Are there any known issues?
Are there any projects who migrated and can report on how it went?
Java 7 is officially supported since vFabric tc Server 2.7.0:
http://www.vmware.com/support/vfabric-tcserver/doc/vfabric-tcserver-rn-2.7.0.html#whatsnew
Since you're using tc Server instead of plain Tomcat probably due to commercial support, it's reasonable only to migrate the underlying Java JDK to the latest version when it is officially supported by the employed version of tc Server. Otherwise, you'd be running it in an unsupported configuration, which isn't far from running a plain unsupported open source version of Tomcat.
Operating tc Server on Java 7 in an officially supported arrangement of versions gives you 2 advantages:
It would have been thoroughly tested by vmWare for any incompatibilities so that you wouldn't have to deal with testing by yourself.
If any problems do occur, you can always get support from vmWare in resolving them.
I know it doesn't directly address your questions, as we in my company also haven't upgraded yet and are only planning to do so.
I just had an impression that your approach makes no sense for a commercially supported product and wanted to outline the reasonable (IMO) approach that is in wide use.
As to any known issues, Java 7 is known for its backward incompatible changes to the XML stack, especially the migration to JAXB 2.2 which changes handling of java.lang.Boolean objects (see the other question - What are the pitfalls when upgrading to Java 7). This can spring up in many different places, I've seen it cause problems in Apache CXF's cxf-codegen-plugin that generates Java stubs from WSDL since the wsdl2java tool it launches makes use of JAXB - the generated method names for boolean elements were no longer in the form of java.lang.Boolean isSomeBooleanProperty() but in the form of java.lang.Boolean getSomeBooleanProperty() which broke code depending on those stubs.
So perform thorough testing if you deal with SOAP web services or XML in general.