SIwpas, Java EE Web Profile Compatible Server CR2 Has Released

Discussions

News: SIwpas, Java EE Web Profile Compatible Server CR2 Has Released

  1. SIwpas, Java EE Web Profile Server CR-2 (Canidate Release-2) is published.

    What is SIwpas?
    SIwpas aim is to integrate Apache Software Foundation(ASF) JavaTM Platform,
    Enterprise Edition 6 (Java EE 6) Web Profile Specification related projects
    into the Apache Tomcat 7 for becoming a Java EE 6 Web Profile Certified server.
    If there is no compatible implementation of the required specification  in ASF,
    we use open source implementation that has been developed elsewhere.

    SIwpas is licensed under the ASL-2.0 (Apache License Version 2.0).

    Release Content
    In this release we have upgraded the components and fixed
    lots of bugs. Starting with this release, we begin to
    support EJB 3.1 Lite features fully. We have removed all
    other coarse grained features of the EJBs, like remote access, IIOP
    support, message driven beans etc.

    Now, you can use EJB session beans and other cool features  in your
    next Java EE Web project like any other POJOs but getting more benefits.

    Thanks to Apache OpenEJB, next generation EJB container :)

    Supporting EJB Lite Features
    EJB 3.1 specification specifies the following items that any
    EJB 3.1 Lite container must support,

    • Components: Stateless, Stateful,Singleton
    • Session Bean Client Views : Local/No-Interfaces
    • Service : Interceptors,Container Managed Transaction, Bean Managed Transaction,Declarative Security, Programmatic Security,
    • Misc : Embeddable API

    Currently SIwpas supports all of them, but we need more work for becoming fully certified.

    Dependency Injection
    Starting with this release, you can inject JSR-299, (CDI) beans into EJB beans
    and vice-versa. Moreover, you can inject Java EE resources into the JSR-299, (CDI)
    beans.

    More Samples
    We have added more samples that show how to use SIwpas

    Samples SVN Location

    http://siwpas.googlecode.com/svn/trunk/samples/

    You can get more information about SIwpas from our project page.

    Project Web Page
    http://code.google.com/p/siwpas/

    Project Issue Page
    http://code.google.com/p/siwpas/issues/list

    Download Location
    http://code.google.com/p/siwpas/downloads/list

    SIwpas Team,

    Enjoy!

    Gurkan Erdogdu

    ASF Member,http://apache.org

    PMC Chair, Apache OpenWebBeans

    CTO, MechSoft Mechanical and Software Solutions, http://www.mechsoft.com.tr

    Threaded Messages (18)

  2. What happened to Geronimo?[ Go to top ]

    Just curious... I thought Geronimo was ASF's Java EE application server that pulls together all their Java EE projects such as Tomcat, OpenEJB, ??OpenWebBeans, OpenJPA, MyFaces, etc.?  Why is a new Java EE application server being created under the ASF?  Can't Geronimo be scaled back to Web Profile if desired?

  3. What happened to Geronimo?[ Go to top ]

    Geronimo is just there and it is a great Java EE server! SIwpas has not been developed under ASF, it just uses ASF web related projects. For other concerns, please read web page of the SIwpas.

    Geronimo's first point is to implement Java EE 6 fully, and this is a huge effort. SIwpas aim is just to wor with web profile related projects, not with CORBA, Remote EJBs, MDBs etc.

  4. What happened to Geronimo?[ Go to top ]

    Geronimo is just there and it is a great Java EE server! SIwpas has not been developed under ASF, it just uses ASF web related projects. For other concerns, please read web page of the SIwpas.

    I still don't fully understand. If you take the projects from ASF, you can simply take them all and you have a Java EE Web Profile compatible server. What's left for you to implement?

    Or do you only take 'some' projects from ASF and implement others yourself? (like JBoss develops tons of stuff themselves but takes the servlet container largely from Apache and the JSF implementation completely from Oracle (previously Apache too).

  5. What happened to Geronimo?[ Go to top ]

    For example, take OpenEJB. Currently OpenEJB does not support CDI and not provide EJB Lite separately.  We provide support for CDI + OpenEJB, injection CDI beans into EJBs and vice versa.

    Also, take Tomcat, Tomcat does not support anything except JSP + Servlet + EL. We provide CDI support for it, therefore Servlets + Filters + Tag Classes etc. can use CDI features. Moreover, we support deployment of EJBs in WARs etc.

    There is an integration project for those kind of stuff. Currently, it is under SVN.

    For MyFaces,adding some CDI integration code.

    BeanValidation, OpenJPA they have been working as is.

    Our single and sole aim is to provide Java EE Web Profile TCK certified server. Not provide full Java EE 6 compatible server that Geronimo has been trying to do! Because it is a lightweight, its releases dates may be more aggressive than fully implemented Java EE servers.

    We will also add nice Adminitration GUI in future versions.

    I hope you understand now,

  6. What happened to Geronimo?[ Go to top ]

    Geronimo is just there and it is a great Java EE server! SIwpas has not been developed under ASF, it just uses ASF web related projects. For other concerns, please read web page of the SIwpas.

    Well, I did read the web page and found the following parts to be interesting:

    For example, currently to develop a JSF application and deploy it into the Apache Tomcat, you have to bundle JSF libraries with your application.

    Or deploy it to Geronimo, JBoss AS, Glassfish etc of course ;) (btw, I think you should deploy to Tomcat, not to the Tomcat)

    This requires you to manage all runtime Java EE web library dependencies of the project. Our main motivation is to solve this problem with SIwpas. With SIwpas, developers will not be required to bundle "Java EE Web Profile" specific libraries into their web applications instead they concentrate their business codes!

    This by itself is always a good thing of course ;)

    Nowadays, lots of developers and companies want to use lighter application servers for their web applications. They do not want to use heavyweight Java EE Servers that implements JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification fully.

    People have been over this a lot of times on this board. I have to say I don't really agree with this argument. In my understanding, the web profile is to make the task of implementing a Java EE server easier for vendors. Because of the many APIs in Java EE, the barrier to enter this market is rather high. Arcane and ancient technologies that are barely used by anyone (CORBA, EJB2) are still required for the full Java EE certification, but they benefit almost nobody. This means a LOT of extra development work and all basically for nothing. Few people are willing to commit to that, which means Java EE potentially misses out on very interesting implementations that might otherwise have been developed.

    For users however, the situation is quite different...

    As a user, I'm not bothered at all by the fact that my JBoss AS installation has an option somewhere to enable CORBA. CORBA never gets in my way anywhere. It doesn't eat any performance, doesn't cause my server to start up more slowly, etc. Basically, it's a few extra bytes on my HDD, nothing more. We're talking about a few MB at most here, on an HDD that's in the terabyte range this is complete non problem.

    In other words, I'm practically completely oblivious to the fact that JBoss AS supports CORBA and EJB2. I just don't use it. Simple as that.

    The mythical 'heavy weight application server' simply isn't there (anymore) thus your claim of selling "a lighter application server" might actually turn out to be a hard sell to your customers.

    Much as I would love to see additional implementations of the Java EE 6 Web profile, by just offering a sort-of sub-set of Geronimo I fail to see the exact added value. Why not use a conceptual --webprofile switch on Geronimo and be done with it? What does your product offer that such a hypothetical switch wouldn't be able to offer?

    If I take a look at the list on your site:

    we will start with Apache Tomcat Version 7 and we will add the following Apache Projects

    • Apache OpenWebBeans
    • Apache OpenJPA
    • Apache MyFaces
    • Apache BeanValidation
    • Apache OpenEJB
    • Enterprise Extensions
    • Your advice ....

    Isn't the main value of your project in the "Enterprise Extensions" then, and not in the "offering a lighter application server"? Can't you just offer these "Enterprise Extensions" to Geronimo's Java EE 6 Web profile?

    I also would love to hear your explanation of what exactly constitutes a 'heavy' application server, and how exactly this supposed heaviness is exposing itself to me.

     

     

  7. What happened to Geronimo?[ Go to top ]

    Heavy mean, IMHO, fully Java EE servers that implements heavy specifications/services of the Java EE Platform, please look at http://jcp.org/en/jsr/detail?id=316 for futher details.

    If you say that "OK, I am just implementing Java EE Web applications using JSF + JPA, but it is OK for me to use JBoss, , or any other Java EE servers  and nothing will be gained if I use lighter AS" then go with them :), nothing stops you!

    As indicated in SIwpas web page, our aim is not implement server from the scracth! Just create a simple web profile environment as light as possible, minumum dependent jars, minumum necessary services etc.

  8. What happened to Geronimo?[ Go to top ]

    Heavy mean, IMHO, fully Java EE servers that implements heavy specifications/services of the Java EE Platform, please look at http://jcp.org/en/jsr/detail?id=316 for futher details.

    I understand that is what you think it means, by what I would like you to explain how 'heavy' in this case actually influences the experience of developers. You now only state -that- Java EE is heavy, not what being heavy *actually* means.

    Does the fact that JBoss AS, Geronimo or Glasfish for instance supports EJB2:

    1. Cause the server to startup more slowly?
    2. Cause the server to use more memory?
    3. Wastes a lot of HDD space?
    4. Consumes more CPU cycles, making the overall product slower?
    5. Severely increases the time to download and/or install the product?

    Please enlighten me. In what way am I actually bothered with the fact that JBoss AS, Geronimo etc supports EJB2 when I'm not using it?

     

     

  9. What happened to Geronimo?[ Go to top ]

    1. Cause the server to startup more slowly?
    2. Cause the server to use more memory?
    3. Wastes a lot of HDD space?
    4. Consumes more CPU cycles, making the overall product slower?
    5. Severely increases the time to download and/or install the product?

    Lots of folks complaints about all of the above :) Those are why lots of companies use Tomcat or Jetty for their production based web applications. I am not saying that Java EE servers  are bad! Every different applications have unqiue needs and Java EE is triyng to solve all of those needs!

    Morever lots of developers and administrators want

    1. Relief from complicated configuration issues,
    2. Decrease development time, (start/stop, deploy/undeploy)
    3. Cloud deployment,
    4. Remove unused libraries

     

     

  10. What happened to Geronimo?[ Go to top ]

    1. Cause the server to startup more slowly?
    2. Cause the server to use more memory?
    3. Wastes a lot of HDD space?
    4. Consumes more CPU cycles, making the overall product slower?
    5. Severely increases the time to download and/or install the product?

    Lots of folks complaints about all of the above :)

     

    I'm sure they do, but will removing EJB2 support or CORBA support improve any of that? Glassfish V3 for example supports all of that, yet starts up in mere seconds. There also doesn't seem to be any significance difference in memory usage between having CORBA support enabled or not, at least I couldn't measure any on my workstation (with 4GB RAM and 2GB allocated to JBoss AS).

    I think I've already been through the HDD space. From the top of my head, Tomcat is somewhere around the 10MB, while Glassfish and JBoss AS are roughly 10x that size (between the 60 and 120MB or so). But does this matter to me? My workstation has a 2TB HDD. What percentage of my HDD do I save by going from Glassfish or JBoss AS to Tomcat? You do the math ;) And how much space would we save for a typical web profile implementation compared to a full implementation? Is that 25MB vs 60MB? Are we really talking about a mere 35MB of HDD space in this time and age? My 3 cents cheap wrist watch has double that memory nowadays ;)

    I'm also very curious if you perhaps think that a web profile version of Java EE executes faster, inferring that the mere presence of EJB2 support somehow eats away processor cycles even when not being used. We have done extensive profiling for our app (high volume transaction processing) and I have found absolutely no evidence that EJB2 is somewhere there being alive and secretly consuming our CPU. If you have some evidence that this is happening in say JBoss AS, I would absolutely love to see that evidence.

    The final point on my list is basically the same kind of argument as the HDD space one. Does downloading 25MB compared to say 65MB make a real significant difference? With our modern 1MB/s broadband lines this amounts to an approximately 35 second longer wait. How often do you download a new AS? Once a week? Once a month?

    The Web profile is a real and significant addition to Java EE 6, but I'm not really sure it was created to alleviate any of the things in my list of suggested items. If we look at your additional items:

  11. Relief from complicated configuration issues,
    In what way does the web profile help here? If I don't wish to use EJB2 or CORBA, there is absolutely nothing I need to configure for them. That's pretty much the idea of 'not using it'.
  12. Decrease development time, (start/stop, deploy/undeploy)
    As I've explained before, Glassfish V3 has support for the full Java EE stack, yet it starts up in mere seconds. Clearly an application server can start up very fast even though it supports things outside the web profile.
  13. Cloud deployment,
    I'm not sure if we're still talking about the same things here. If I'm not mistaken we're talking about what benefits a web profile implementation brings to the user compared to a full implementation right? Apart from the fact that just throwing around the buzzword "cloud deployment" is a little awkward, you seem to forget that with a full implementation I can still code against the web profile standard. A full implementation, by definition, supports the web profile fully
  14. Now if your argument is that a cloud implementation of Java EE might support the web profile sooner than it supports a full Java EE implementation (if ever), then this might be true. But this advantage is for people (vendors) building such a cloud implementation. It's a general advantage of the existence of a web profile and NOT an advantage of using a specific web profile implementation that is actually a subset of an existing full implementation.

    Do you understand this? This is really, again, the point I made earlier. The web profile makes it easier for people (vendors) to implement a specific kind of Java EE compliant server, so someone can actually go ahead a build a 'cloud version of Java EE' without the immense bulk of work that a full 'cloud version of Java EE' would require. It's an advantage for people BUILDING Java EE implementations, not necessarily for people USING Java EE implementations.

  15. Remove unused libraries
  16. This by itself is, I'm sorry to say, a non-argument. It's the same as saying Java EE is heavy, and then explaining it's heavy because it's heavy. The question again is, WHY would users like to remove unused libraries? Is this because they eat away their HDD space? Because they consume CPU cycles? It's the same argument as just saying that Java EE is heavy. Unused libraries typically don't do any of that. They just sit there... being unused... doing nothing...

    Have you ever taken a look at how much 'unused libraries' your typical Linux distribution installs? (or Windows, it that's your poison) There are FAR, FAR, FAR more of them and together they weigh in at FAR more MB or even GB than is the difference between your "web profile" implementation and a full implementation of Java EE.

    If people were so concerned about "unused libraries", then tell me, why doesn't anyone trim the server on which their Java EE AS runs? This will yield far more disk space (easily in the hundreds of MB range, with a little determination even in the lower GB range for some distributions). And does anyone do that? Does anyone really bother with it? (apart from the really obvious things like not installing desktop stuff like X and Open Office on a server of course)

    Best of all, if you're really worried about this stuff, then at least JBoss AS and Glassfish let you remove unused stuff already. Just for the fun of it, I did so in the past, but my applications did not run any faster ;)

    If all you are really planning to do is to deliver a subset of Geronimo anyway, why not do exactly that and just offer an already pruned down to Java EE web profile version of Geronimo? Although I would be surprised if it would bring any of the benefits you seem to think it brings (faster startup, faster execution, less memory, easier configuration), I'm sure there would be some market for it. Join the Geronimo team and have this as a download on the regular Geronimo download page.

    Finally, I want to make clear I'm not some sort of anti-web profile evangelist or so ;) I greatly applaud efforts like Resin 4 that supports the Web Profile and can now be an official Java EE 6 product, where otherwise (without the existence of the web profile) it probably wouldn't have been.

    I'm just skeptical about creating a new product, solely build out of parts from an existing Java EE implementation, especially when such implementation itself will most likely also simply support the web profile itself.

     

  • What happened to Geronimo?[ Go to top ]

    As indicated in SIwpas web page, our aim is not implement server from the scracth! Just create a simple web profile environment as light as possible, minumum dependent jars, minumum necessary services etc.

    p.s. I mentioned this before, but wanted to mention it here again specifically. This by itself seems like a great goal, but why not join the Gernonimo team directly and release this as "Geronimo Web Profile" with a description like "Special trimmed down version of Gernonimo that is fully Java EE 6 Web Profile compliant yet [insert your description here]"?

    I'm really sorry if sound too negative in my previous posts, I'm just a little skeptical ;)

  • What happened to Geronimo?[ Go to top ]

    Augustientje?,

    Your points are exactly correct. The runtime memory, HDD, download size, bootstrap, etc issues are not that big a deal for most people in practical terms (unless of course we are talking about certain commercial implementations that add a lot of "bells and whistles" beyond just Java EE). The Web Profile is really mostly about making it easier to write solid, lightweight Java EE 6 servers without a lot of the API bloat that's built-up over the years. Because there are fewer APIs and a smaller code base for the implementation, it is easier to optimize/keep administration/management as easy as possible.

    Hope it helps,

    Reza

  • What happened to Geronimo?[ Go to top ]

    As indicated in SIwpas web page, our aim is not implement server from the scracth! Just create a simple web profile environment as light as possible, minumum dependent jars, minumum necessary services etc.

    p.s. I mentioned this before, but wanted to mention it here again specifically. This by itself seems like a great goal, but why not join the Gernonimo team directly and release this as "Geronimo Web Profile" with a description like "Special trimmed down version of Gernonimo that is fully Java EE 6 Web Profile compliant yet insert your description here"?

    I'm really sorry if sound too negative in my previous posts, I'm just a little skeptical ;)

     

    Totally agree.

     

  • What happened to Geronimo?[ Go to top ]

    As indicated in SIwpas web page, our aim is not implement server from the scracth! Just create a simple web profile environment as light as possible, minumum dependent jars, minumum necessary services etc.

    p.s. I mentioned this before, but wanted to mention it here again specifically. This by itself seems like a great goal, but why not join the Gernonimo team directly and release this as "Geronimo Web Profile" with a description like "Special trimmed down version of Gernonimo that is fully Java EE 6 Web Profile compliant yet insert your description here"?

    I'm really sorry if sound too negative in my previous posts, I'm just a little skeptical ;)

    what do you think that why there are lots of Linux Distros? Why not one of them gets other and adds new modules and "insert your description here" :)   Answer is countless....

  • Gurkan,

    Great work! I hope you guys can make this an ASF project at some point as well as allow the use of EJB annotations outside of EJBs in plain CDI managed beans just as Resin does.

    Cheers,

    Reza

  • Wow, what a huge comment. Feel guilty for becoming a part of SIwpas :)

    - I am totally  disagree that using Tomcat and any Java EE servers are the same taste.

    - Lots of projects use ASF projects for their implementations, for example JBoss, Glassfish etc. Why do different application servers come on to the market?  Did you ever think that why not all of those guys join together and create a super-bomb application server?

    - You may not be concerned with HDD, unused modules, cloud etc. But lots of customer think about them. Lots of customer would like to run their Java Web applictions on cloud environments where resources are shared. Most of the customers would not like to get full blown application server, and disable of  their some services, modules. They want what they need! Persoanlly, if I do not want to ever use EJB 2, CORBA, JMS, JAX-RPC etc, I do not want that those modules are contained in application server! 

    - For becoming part of Geronimo:

    We have been already helping Geronimo Community. I am  founder of  Apache OpenWebBeans project, helping to integrate it into Apache OpenEJB, Apache Tomcat etc. But, as I said before Geronimo aim is  to become a full  blown Java EE project and it contains lots of modules. Its not just easy to implement Java EE Web Profile server without touching so much internal details.

    I wonder if you have looked at JBoss source code, Geronimo source code and SIwpas source code? Maintaining such a code base is very huge effort. Therefore, creating SIwpas is not just related with "lightweight/trimmed down" of Apache projects. We think as "Web Profile" from the beginning, and include just necessary piece, nothing more or less. In SIwpas, we do not require to implement J2EE Management spec, and event do not want to think about how Web Profile implementation affects other parts of the server etc. But, Java EE servers must think about them.

    Reza,

    Thanks a lot for  your comments. Yes, it is reasonable to create a new TLP under ASF. I believe that Java EE Web Profile Server deserves its own project.

  • Gurkan,

    No problems, I appreciate the work you guys are doing. Rightly or wrongly, being an Apache project will probably give you greater credibility, even if the only differentiator is in goals, integration, administration, time-line, etc.

    Just my two cents...

    Cheers,

    Reza

  • Balance[ Go to top ]

    I don't think anyone likes to see a single super-bomb application server. But JBoss AS, Glassfish, and others only take *some* parts from Apache. If your new AS uses exactly the same Apache projects that Geronimo does AND you also release it as an Apache project, then this only confuses people. If you want to do those things, just join Geronimo ;-) If you want to build your own independent AS, that only uses some parts from Apache/Geronimo, then it makes sense to go your own way. Btw, what about a project name that's easier to pronounce? ;-)

  • Hi Gurkan,

    This is pretty much a fork of OpenEJB's Tomcat integration code which we are still working on and hoping to certify.  OpenEJB has always been embeddable and supported a very unique Tomcat integration.  With the Embedded EJB Container API and Web Profile now in the specs, we are extremely excited to be able to have those be standard and certified.

    With your help, we could probably get there even sooner.  It's cool if you want to take the code and go your own way, but it would be great to work together.  The OpenWebBeans/OpenEJB collaboration is going really well, there's no reason that can't extend to the OpenEJB/Tomcat integration as well.

    All the best!

    -David