is there a way of having a language-mixed component framework like OSGi? I'd like to mix modules or bundles that are written in C and Java. On the site of NativeOSGi (https://github.com/abroekhuis/NativeOSGi) there is a hint, however the project seems to be not maintained anymore. Is there a way of getting Apache Celix and Felix to work together?
The easiest way of making Felix and Celix work together is through the OSGi Remote Services specification. Work is currently being done to make Amdatu Remote (an implementation of that specification) interoperate with Celix. I would encourage you to ask on the Celix mailing list, as they can probably tell you more about its current status.
Like Marcel said, the best way to go would be using Remote Services.
Since the Amdatu Remote Services has been working on a new release I am not sure if the current version is compatible with the Celix implementation. If this is not the case, we should work on getting it up and running again.
You mentioned NativeOSGi, and while the github page isn't maintained, we are still working on it (sadly a bit slow..). Basically the idea is to make Celix implement the NativeOSGi API (or base the NativeOSGi API on Celix, just a matter of perspective). Since Celix has had a 1.0 release, we have started working on the API, so expect to see some progress on the trunk wrt NativeOSGi.
I hope this helps a bit, if there are any other questions, feel free to ask!
Related
I have a Java application using Grizzly 1.9.59, Apparently around the version 1.5.x version 2.0 was also released with a totally new and incompatible API. Both versions are being developed 1.x being legacy.
So taking in consideration that both versions are being developed is it safe to assume they offer the same capabilities? What would be a really good reason to upgrade to 2.3.15(latest)?
Is there any documentation comparing both versions feature wise?
Does anyone know if they plan to stop developing 1.x, if so when?
I can't answer the question fully. But from their website:
The latest stable release of Grizzly is 2.3.14. Older versions of Grizzly (2.2.x, 1.9.x, 1.0.x) are still available and can be found on Maven Central.
So they see 1.9.x as an old version and on their website there are no direct download links, to 1.9.x. To me at least this indicates a wish to make uses adapt to the newest version.
So taking in consideration that both versions are being developed is it safe to assume they offer the same capabilities?
NO! It is not, many libraries run a legacy version, which primarily receives bug fixes and minor updates. File the new fancy version receives the awesome updates.
What would be a really good reason to upgrade to 2.3.15(latest)?
At some point when 1.x.x no longer is developed you will have to do it anyways. But really it is a cost/benefit situation you are in
How much time will it take to do
Will you continued to use Grizzly
Is the new API, so hard to learn?
How much do I need to change the rest of my code
and so on, personally I would make the jump, if I where looking for a long term solution.
Is there any documentation comparing both versions feature wise?
I have not been able to find any, not even on there Jira
Does anyone know if they plan to stop developing 1.x, if so when?
Try their mailing list for answers to that, they properly no more and might be able to provide a feature table as well.
Summary:
Their website focus on the newest version (and refer to prior as old versions), though 1.9.x still is in development. You can not be certain the two different versions has the same features and capabilities. If they stop developing 1.x.x you would still need to update to the newest version.
For questions about more project specific things try their mailing list
A small note, your question is pretty open. I know my answer is more a comment but not enough space in the comments.
I was trying to get some info from documentation, but it seems that it is one of those projects that you have to check out and play with it to figure the answers out ...
I noticed of hight activity on mailing list and quite a lot of commits, it's a good sign. But when I was looking into the code base (btw 536MB big - not a good sign), I didn't find to much J2EE app fashion in it. No spring, ejb, weird folder structure, quite a lot of non-standard jar libraries. It's like the developers didn't like it so they've done things their own way :-)
I've been using a few similar platforms, mainly portals and for example Liferay is quite easy to work with because it looks as one would expect it to. It is based on Spring, it has, transparent service and dao layer, it has simple plugin architecture (plugin = WAR) etc., typical J2EE development.
I'd like to know what are the key aspects that a developer should be aware of before he decides to use it. And as it is quite non-standard J2EE application, how much time consuming is to get to know it to be able to be productive.
What are its (dis)advantages in comparison with other ERP systems like OpenBravo. If I need mainly Cart rather then ERP backend, should I be interested in OpenTaps ?
I was also playing with Broadleaf Commerce which is way easier to start with.
Thanks very much in advance.
There is a learning curve and it's not easy to get skilled developers who understand the core of the system which is the Entity Engine and Entity Model.
The database model is built on the Universal Data Model which is why it can support a very wide range of data types. Even JIRA is built on the OFBiz Entity engine.
There are many Ecommerce shopping carts built on OFBiz, and it depends on the extent to which you need to customize products or build configurable packages.
It's very well suited for vanilla products i.e. pick and choose, compare, add to cart. Easy to call web services and expose web services, easy to integrate with PayPal etc. So if you're selling Tshirts and Flowers, it's good.
Anything like configuring a complex product like a laptop with various options will require some custom coding in Beanshell (BSH) or Groovy in addition to Java code.
Also it does not naturally integrate with app servers, it runs on it's inbuilt Tomcat but porting to Weblogic etc will be some effort.
The other problem is not enough detailed documentation, I would not say it is missing, it's light - the developer cannot expect an easy tutorial for eveything, it's more "ask and you shall receive" and you will get help on the forums - Usually you get direct replies from David Jones who wrote the framework, so that is helpful. But people who start with OFBiz need at least 3 - 4 months of studying the code and running simple applications before actually building anything.
That's my personal opinion, hope this helps.
I have not worked with Opentaps so really can't comment on that.
Re other Open Source ERP projects: watch out for projects dominated by one company, where the Open Source thing is a marketing vehicle, and it's really Open Core.
Open core means you pay for "plugins" to complete your system, and there is no incentive to standardise and to move functionality into the core.
If it's dominated by one company, they may take the project private at any time, as happened with Compiere.
OFBiz is a genuine community project hosted by the Apache Software Foundation.
When I looked into Java EE6 doc and some other articles, Java EE6 is a platform.
To me, platform is just Java with bunch of API/framework available like JSF, JPA, Web services like REST. (more like bunch of jars maybe?)
So anyway I got Netbean6.9/Java EE6/GlassFish v3 bundle but figured I don't need JSF at all.
Is there a way to remove JSF from Java EE6 so that I can save some disc space on my server?
Sorry if my statement doesn't make sense because I'm not fully understand what exactly Java EE6 by reading documentation.. (or this JSF is bundled with Netbean6.9...)
Update:
I'm building REST web app so far using JAX-RS and JPA (toplink essential) and for UI side, JSF was going to be used but we decided not to, so wondering if things that won't get used can be removed. (after reading comments I think removing JSF is not good idea though)
Java EE is a set of interfaces/annotations/etc for performing tons of different kinds of tasks commonly needed when building, well, 'Enterprise' applications. (the definition of which is its own multipage thread.) Glassfish is includes an implementation for each of the different APIs that make up JavaEE. Basically, when you use Glassfish, you can just go ahead and use anything in a 'javax ' package and it will be there for you, working. (although sometimes not the most performant or scalable implementation available...)
There are several options for java web containers that don't include implementations of the entire J2EE API built in. Tomcat and Jetty are probably the two most popular and widely used. Tomcat installs and integrates right into netbeans very well. But if you find yourself wanting to use something in most javax packages, you will need to provide an implementation, include the jar files yourself, etc.
--
Also, as an aside, the very, very nice Glassfish administration console (which is to me the chief motivator for using Glassfish) is done in JSF, so no, you can't really remove it :)
Regarding JavaEE, you don't need any jar file, but only a compliant application server, Glassfish in your case. And no, you can't remove features you don't need. But you don't have to use them if you don't want to... ;-)
In order to be J2EE certified there are certain requirements that must be met, and removing some of the functionality may cause problems.
For a nice discussion on what it means to be certified, you can start with this:
http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
A Java EE application server can
handle transactions, security,
scalability, concurrency and
management of the components that are
deployed to it, in order to enable
developers to concentrate more on the
business logic of the components
rather than on infrastructure and
integration tasks.
If you find that you don't want to use much of J2EE you can look at something like the Spring framework (http://www.springsource.org/) which will offer more capabilities than just tomcat/jetty, but you can add/remove the parts you don't need, though you will need to include the core.
If you just need JAX-WS for example, then you can just add that manually, but, depending on your application you may find that there are many parts you will eventually need to make your life easier.
I need to build a CRUD application to maintain a simple set of tables. Normally I would do this in php but I cannot deploy this in the client environment.
I want to do this reasonably quickly and vanilla J2EE, EJBs, spring, Hibernate etc. is just plain overkill.
I am looking at either Rife or Lift frameworks. They both seem to have RAD capabilities, good Webpage as UI support, reasonable ORM support, and, can be deployed as a package with Jetty or Tomcat.
Does anyone out there have experience of these? I would be interested in any opinion no matter how subjective. Also can anyone suggest anything better!
Thanks for the Advice.
I was intially attracted to Lift and Rife because I can deploy the developed apps as a compiled WAR file -- with no source code inside. I was also impressed by the fact that large parts of twitter have been rewritten in lift.
I Rife would seem to be ideal for my purposes but it has not been updted since 2007 which is a bit worrying.
So it looks like Grails and Groovy here I come!
I am not familiar with Lift or Rife, but I have used Grails. The default scaffolding (much like Rails) will get you most of the way there. Runs on Tomcat and Jetty just fine.
Unless you want to use Scala LIFT may be a bad choice. I haven't tried Rife so I can't give any feedback on that.
What are you trying to do? The more information you give the better suggestions can be made.
Look into
Play (This may be an excellent fit for you)
Grails
Restlet
Rails inside JRuby
All of the above can be backed into a WAR, most offer there own way for running self contained, and everything except Restlet has some built in ORM.
I evaluated Rife and it is a solid choice, but it is really geared towards those who want to do it in Java code (although it doesn't force that for all components of the web application). Coming from PHP I would think that Grails as Jeffery suggested is a more natural fit, unless you do know Java already.
Have you considered Quercus? It can be deployed on Jetty or Tomcat, although it will obviously have a more natural home on Resin. The open source version would probably be fast enough for you.
I would like to create a RESTful app on Google App Engine. I would like to provide XML and JSON services. I have briefly experimented with Restlet, Resteasy, and Jersey. I haven't had much success with any of them, other than some simple examples in Restlet.
Could you share your experiences creating a Restful web application on Google App Engine using Java or provide any insight on the aforementioned toolkits on GAE?
Thanks!
Edit (2009-07-25):
I have decided to use Restlet for the time being. It seems to work flawlessly so far. Please post any other insights/opinions you may have. What problems have you encountered? Have you successfully used Jersey/Restlet/Resteasy on GAE/J? If so, we want to hear about it!
I'm happy to report that Restlet M3 works FLAWLESSLY on AppEngine 1.2.2. I have followed the "First steps" and "First resource" tutorials found http://restlet.com/technical-resources/restlet-framework/guide.
So, it seems to me that Restlet is the answer for your GAE/J Restful applications.
I'm using Jersey on GAE. Here is the link for those who are interested about setting it up: (I'm using GAE SDK v1.4.0):
http://tugdualgrall.blogspot.com/2010/02/create-and-deploy-jax-rs-rest-service.html
I am going to begin exploring this as well, but haven't started yet. I did find this framework, that says it should work, but like I said haven't tried it yet.
http://wiki.restlet.org/docs_1.2/13-restlet/275-restlet/252-restlet.html
If you get it working, or manage to get one of the above suggestions working, update everyone as I am sure there is interest in this.
I'm using Restlet together with Guice on Google AppEngine. IMHO they fit together very well. See my recent blog post for further details: http://haraldpehl.blogspot.com/2009/11/google-appengine-restlet.html
Since these valiant older solutions were patched together, Google has apparently supplied an Eclipse plugin to create a starter project that produces an App Engine app, an Android APK, and a Web app, all talking to one another over an interface defined by a single set of annotated object declarations.
Haven't tried this yet myself, but do have a look before trying any of the more heterogeneous examples described in the earlier messages above:
https://developers.google.com/eclipse/docs/appengine_connected_android
This Google video is also quite informative:
http://www.youtube.com/watch?v=NU_wNR_UUn4
For what it's worth, there has been quite a bit of discussion on Jersey user lists wrt how to make Jersey work on GAE. It is bit tedious work due to GAE restrictions (missing classes from white lists -- hopefully resolved over time), but apparently can be made to work.
So while not trivially easy, that might be your best bet; esp. since many of the problems faced are the same for all frameworks (imposed by GAE).
Well, I would highly advice you to have a look at play framework
Have a look at the video on the homepage
It has a gae module
With siena as a orm to handle gae datastore
From all the java frameworks I've seen so far, I think it has the easier learning curve,
great documentation,
a tutorial to develop a complete application
very active and helpfull community,
free as in beer and also as in speech
highly scalable due to it's stateless out of the box design
rest friendly
highly customizable via it's modules and plugin approach
more over, taking into account it's for a college course, it's really easy to hack into the code, I could handle a couple of tickets and new features without any experience at all with java, just a couple of year developing web applications with php
other benefits
it's really easy to start, no complicated setup involved, just download and unzip the file and your are ready
great development experience, just fix the code and hit refresh, play autocompiles changes on the fly when running on development mode
fast and lightweight
fullstack, you don't have to integrate cumbersome frameworks to make it work
great errors report, no more endless error stack trace, just shows you the line with error
no xml configuration anywhere around
great support for tdd with selenium integrated test
I think the main advantage as a learning tool, is that it's possible to peek into the source code without feeling lost and the community support... The documentation is very clear, and you can learn a lot by just having a look at the source code...
I recently put together a project template with Jersey, Guice and AppEngine at GitHub. It has been developed with SimpleDS, but it can be modified to work with Objectify / JDO easily. The project is live here.
It should be a good starting point for new projects.
Here is a very very good tutorial Restlet/Android/GAE/Objectify with an example of a simple application. Sorry it's in french, but you can juste copy/paste the code, or use google traduction.
I followed it and had a working Android / GAE server communicating together in a 2 hours. It's a good base to start or test Restlet.
http://www.tutos-android.com/webservice-rest-android-appengine-restlet-objectify
Good Luck
The 2 most cumbersome GAE REST API actions to make work, whether Java or .py, are graphics and how to undisplay private information. My little gae rest feed forked another project. I'm sure Java succeeds where python stuck due to the Java takes and gives more ways (advantages) as well as longer (slower) time to succeed (disadvantage) while python projects opens less ways to succeed (disadvantageous) and less development time (advantageous rapid development) to succeed the same.