In this post I’d like to provide a complete listing of all commands available in Resin. First, let’s enable resin:ManagerService. Open your resin.xml file and add <resin:ManagerService/> into <cluster-default> section. If you running Resin-Pro look for <resin:AdminServices/> tag and uncomment it. Remember that <cluster-default> applies settings to all configured clusters, e.g. app-tier and web-tier. (more…)
Posts Tagged ‘resin’
I just came back from a trip to the Raleigh, NC area to record a JavaLobby Tech Chat on Resin 4 (last year Emil did a Tech Chat that you might have seen). The Tech Chat went great. Mitch Pronschinske, the Editor-in-Chief of JavaLobby/DZone drove the Chat. Not to give away too much right now but we talked about:
- Past/present/future of Resin
- Defining characteristics of Resin - lightweight, standard and feature-complete
- Resin 4 Java EE 6 Web Profile certification
- Java EE Web Profile leadership
- How it stacks up against Tomcat/JBoss/GlassFish/WebLogic/WebSphere
- Small, dedicated, agile World class engineering team
- CDISource - a vendor-neutral space for all things CDI
- The CDISource Spring/CDI bridge
- Possibilities for Java EE 7/Java EE 8 (open for participation from you!)
- Early Resin WebSocket support
- Resin support for private clouds
Keep your eye on JavaLobby - the Tech Chat should be out there soon!
I chose to drive to NC to avoid the hassle of flying and because NC is quite drivable from my home office in Philly. On the way back, I did CDI demos at both the Research Triangle JUG and the NoVA/Washington, D.C. JUG. Both talks were very well attended. The interest/participation levels were fantastic. The DZone folks gave me a few nice printed copies of the CDI RefCard. Every single copy was taken and people were asking for more! They also asked me for the slide deck and code examples. I’ll send them to the JUG leads to post on the JUG websites. You can also take a look at the slide deck and code examples if you want and send me any follow-up questions. I also wanted to talk at the Maryland and Richmond JUGs but things didn’t quite work out schedule-wise this time around. Both JUGs are working on scheduling me to speak in the Fall instead.
TSSJS 2011 went extremely well for us. Our talks/events went very well and the booth attendance was great. I think the TSSJS 2011 agenda, quality of content/speakers and buzz was the best in years. The new TSS editor Cameron McKenzie did an admirable job at putting everything together.Â Some of the notable speakers included James Gosling, Steve Harris (SVP Oracle), Adam Messinger (VP Oracle), Patrick Curran (JCP chair), Rod Johnson, Bill Burke, Adam Bien and Kirk Pepperdine.
I started the conference with a 5-minute lightning round presentation on Resin 4, the Java EE 6 Web Profile, our vision, history, thought leadership, values, global footprint and growing customer base. The presentation seemed to go over well with a number of existing customers and developers reaching out to us afterwards.
The first session on the first day of the conference I did was my enterprise caching talk titled â€œEffective Caching Across Enterprise Application Tiersâ€. The talk covers the different flavors of caching in the web (HTTP), presentation, application, domain, infrastructure (persistence) and resource (database) tiers using mechanisms like proxy caching (especially as supported by Resin), JSF/CDI @ApplicationScoped, @SessionScoped, @ConversationScoped, @ViewScoped, @RequestScoped scopes, passivation, EJB pooling, EJB thread-safe singletons, extended persistence contexts, JPA first (transactional) and second (shared) level caching, database connection pools, prepared statement caching, JCache as well as distributed caching APIs like Coherence, Terracotta, GigaSpaces, Infinispan, EHCache, JCS, SwarmCache and OSCache. The talk was very well attended, the Q&A was good and I got great feedback afterwards. In the evening, I participated in the “Meet the Authors” event. TSSJS gave away two copies of EJB 3 in Action (I am currently working on the second edition) and I signed both copies for the winners. I had a few engaging conversations on topics like EJB/Spring, authoring and the JCP during the course of the evening.
I started the second and busiest day of the conference with a panel titled “The Java Community Process: What’s Broken and How to Fix It”. This was a panel with Patrick Curran, James Gosling and me, moderated by Cameron McKenzie. We discussed the need for reforming the JCP, greater transparency, the Apache Harmony licensing issues, more non-Oracle spec leadership and more participation from non-vendor affiliated independents. We all agreed that many ills in the JCP can be cured through greater interest and participation from the developer community. The panel generated a great deal of interest, attendance, participation and feedback. After lunch, I gave my “A Quick Tour of the CDI Landscape” talk. The talk is a broad overview of the vibrant CDI landscape composed of implementations, supported runtimes, portable extensions and tools. I discussed Weld, CanDI, OpenWebBeans, GlassFish, JBoss AS, Resin, Geronimo, WebLogic, WebSphere, Tomcat, OpenEJB, TomEE, JOnAS, Seam 3, Apache MyFaces CODI, the ZK Framework, Arquillian, Forge, JBoss Tools, Eclipse, NetBeans and IntelliJ. The audience was great and I had some lively discussions afterwards. Later in the afternoon, I did my Java EE testing talk titled â€œTesting Java EE 6 Applications: Tools and Techniquesâ€. The talk covers end-to-end testing along the entire Java EE stack including Servlet 3, JSF 2, EJB 3.1, JPA 2, JAX-WS and JAX-RS using existing and emerging tools like JUnit, HttpUnit, HtmlUnit, Cactus, Selenium, JSFUnit, embedded containers, embedded databases, Arquillian/ShrinkWrap, Resin JUnit integration support and soapUI. The talk was well attended and I got excellent feedback for the talk. It was only somewhat surprising that folks donâ€™t realize how robust Java EE testing is with the latest release and tools like Arquillian. In the evening, I participated in the “Ask the Experts” session which also went very well.
A number of folks asked for the slides and demo code, so the materials for the talks is posted here.
A good number of folks stopped by at the Caucho booth to talk to us. We had an excellent location this year for the booth and people saw us last (almost). I think we had the best booth traffic of any conference so far. The guitar giveaway seemed to go over very well too. We can only hope that next year is just as successful!
After a long few months of hard-work, we finally see the light at the end of the tunnel for getting Resin 4 Java EE 6 Web Profile certified!
We are now passing the Servlet 3.0, JSP 2.2,Â EL 1.2, JSTL 1.2, JSF 2.0, Bean Validation 1.0, CDI 1.0, JPA 2.0, JPA 2.0 and JMS 1.1 TCKs. Note, although JMS is not part of the Java EE 6 Web Profile, we are still implementing it since a number of our customers have asked for a lightweight messaging option in Resin.
The last TCK that we need to pass at this point in order to be Java EE 6 Web Profile compliant is EJB 3.1 Lite. As such, we do have the basic functionality for stateless session beans, stateful session beans and singleton beans including life-cycle, concurrency, registry/look-up, interceptors, security and transactions. Indeed, Adam Bien recently blogged about the usability of the current Resin 4 development release: http://www.adam-bien.com/roller/abien/entry/java_ee_6_server_resin and we have been demoing full-stack Java EE 6 applications for a while now including at JavaOne 2010 (albeit without EJBs, using EJB service annotations/aspects directly in CDI managed beans).
At this point, it is a matter of working through the cases caught by the EJB 3.1 Lite TCK. I’d say a majority of it is minor bug-fixes with singletons having the most and stateless session beans the least amount of issues.
Although technically not part of EJB 3.1 Lite, we are also implementing scheduling, asynchronous processing, remoting (Hessian based) and message driven beans because we feel these are valuable parts of the EJB specification. We will also include a JCA implementation for better resource pluggability. At this point, we have the basic functionality of timers/scheduling as well as asynchronous processing done. The remoting and the message-driven bean/JCA parts still need significant work, including creating a new messaging model around CDI events as a supplement to the older message driven bean model. My personal guess is that we will have the officially Java EE 6 Web Profile certified release of Resin 4 by the end of the year. We will then have a few releases focused purely on stability, optimization, foot-print, start-up/shut-down time and runtime performance since these have always been primary differentiators for Resin.
The final release of Resin 4 will allow us to then focus on some of the work around CDI portable extensions that we wish to do including Seam 3 modules/Arquillian integration as well as things like HTML5/WebSocket, modularity, cloud/NoSQL APIs, etc.
Obviously, Resin 4 is a very important milestone for us as a team but is very significant for the Java EE 6 ecosystem too. I would expect the JBoss guys to announce their final Java EE 6 compatible version shortly after us, probably followed by Geronimo, WebLogic, etc.Â It seems IBM has been uncharacteristically proactive with the WebSphere Java EE 6 work too.
In the meanwhile, do send us your comments and wish us luck on the final stretch of the Java EE 6 implementation marathon!
Overall, Caucho had a great JavaOne this year. Our talks went very well, the booth attendance was great and a number of people showed up at the meet-and-greet.
The first session we did was the Resin 4 Java EE 6 Web Profile talk titled “Resin: A Light-footed Java EE 6 Web Profile Platform”. This was the first time Emil and I co-presented and I thought it went very well. The attendance was moderate but we had a number of good questions and a handful of folks asked for the slides/demo code afterwards. That same evening I did a CDI BOF with Dan Allen of Red Hat/JBoss and David Blevins of Apache OpenWebBeans/OpenEJB. The BOF was titled “Implementing CDI: Goals, Milestones, and Perspectives” and was well-attended. We had lively discussion around the current state of implementations, the CDI ecosystem as well as the future of CDI/Java EE. A lot of folks gave us positive feedback on the BOF, particularly on our plans going forward for Java EE.
My first talk for the second day of the conference was the Java EE testing talk with my EJB 3 in Action co-author Debu Panda titled “Testing Java EE 6 Applications: Tools and Techniques”. It was a full house and the talk went very well although we ran out of time and could not demo JAX-WS/JAX-RS testing. The talk covered end-to-end testing along the entire Java EE stack including Servlet 3, JSF 2, EJB 3.1, JPA 2, JAX-WS and JAX-RS using existing and emerging tools like JUnit, HttpUnit, HtmlUnit, Cactus, Selenium, JSFUnit, embedded containers, embedded databases, Arquillian/ShrinkWrap, Resin JUnit integration support and soapUI. We got excellent feedback for the talk. It was only somewhat surprising that folks don’t realize how robust Java EE testing is with the latest release and tools like Arquillian. Debu was in great form for the talk as usual. In the evening I did an EJB 3.1 BOF with Linda Demichael of Sun/Oracle, Mike Keith of Sun/Oracle, David Blevins of Apache OpenWebBeans/OpenEJB as well as Andy Rubinger of JBoss/Red Hat titled “Enterprise JavaBean (EJB) Community Discussion”. The attendance was moderate but the discussion was very lively. It was very encouraging that we were more-or-less on the same page about the future direction of the EJB spec.
The last session I did for the conference was on Wednesday. It was a panel with Adam Bien, Emmanuel Bernard of JBoss/Red Hat, Krasimir Semerdzhiev of SAP, Roberto Chinnici of Sun/Oracle, David Blevins of OpenWebBeans/OpenEJB and Jim Knutson of IBM titled “Java EE 6 Panel: What Do We Do Now?”. The panel was moderated by Alexis Moussine-Pouchkine of Sun/Oracle. He blogged about the panel here. It was a full-house and we had very lively discussion. I talked with several of the panelists afterwards and it was very encouraging that folks are actively thinking about what really should be done in Java EE 7 and mirrored what we are doing in Resin/CanDI.
The material for our talks is posted here.
A good number of folks stopped by at the Caucho booth to talk to us. We had an excellent location this year for the booth and people either saw us first or last. We can only hope we are that lucky next year! The meet-and-greet was good too and met up with a handful of friends including Andrew Schaefer and Ryan de Laplante. I also of course met up with the usual suspects from JBoss, SpringSource, Apache, Sun/Oracle, etc throughout the conference.
I have mixed feelings about the conference itself. The programming and organization was great but I could not help but feel that JavaOne was demoted. I think a lot of developers have this same sentiment and I hope Sun/Oracle will do better next time.
Hello, web developers!
We’d like to get a sense of the development tools you’re using with Resin and what tools you’d like to use with Resin. If you could post your thoughts, we’d appreciate it and will try to incorporate your ideas into our upcoming development efforts. There are a few framing questions below, but please feel free to comment on any other development issues that we’ve missed:
- Do you use an IDE when developing with Resin? Which one?
- If you use Eclipse, do you use the plugin from http://caucho.com/eclipse?
- If you didn’t know about the Resin eclipse plugin, where do you expect to find it? (e.g. on our webpage, in the Eclipse update system, etc.)
- Do you use other tools such as Maven to develop with Resin?
- If you use Maven or some other command line tool, what plugins and/or features would you like to see from Resin?
- Do you deploy to Resin in production directly from an IDE or command line tool? If not, is that a desirable feature?
You can also reply to this related topic on our forums and/or take the poll there.
Much of the time for Resin 4.0 that we’re spending is in improving the underlying quality in the core Resin services. Most of these aren’t visible features, but do improve the reliability and testability of the underlying code.
Since Resin is a 12 year-old product, we need to balance the need to improve and learn from experience with the fact of a large, existing code base with a large customer base, and have found continual refactoring combined with a solid regression suite to be an effective development path.
In the case of the networking code, we’ve gone from the simple request/response of HTTP to supporting Comet/Async for the Java EE Web Profile, and prototyping WebSockets for the upcoming HTML 5.
The main networking code change was remodularization: removing all HTTP dependencies and making the networking a standalone module independent of the rest of Resin.
There are two main quality benefits of the change. By removing distractions, we can focus on exactly the networking code and nothing extraneous, making it easier to see bugs and review code. And by cleanly encapsulating the interfaces, we can verify that our testing is complete, because the quality is more dependent on the quality of our tests than the code itself.
The way that you start and stop Resin and the watchdog have changed a bit in the 4.0 branch. I realized as I was writing the Resin Refcard that there are probably a few options and concepts that many users don’t fully understand. In this post, I review the Resin watchdog architecture and show the syntax while highlighting recent changes. I’ll also describe some of the thoughts we have for the future of the watchdog and solicit your ideas and input.
We’ve been doing a lot of work on our Resin administration application over the last few releases, adding features like statistic graphs, postmortem reports, and REST. The framework we’re building for these features is also quite extensible and easy to use. One of the in-house extensions we developed combines the REST and graph features so that you can export and embed user-defined graphs. We’ve added this extension to the main application for the upcoming 4.0.4 release so it’s available without any coding. In this blog post, I’ll show you how to embed Resin statistics graphs in your own monitoring tools, how the underlying graph API works, and give some tips on how to write your own similar extensions.
Apache Chainsaw is a popular graphical logging tool for Java. Even though it’s based on Log4j and Resin’s logging uses java.util.logging, you can use Chainsaw to analyze Resin’s logs in real time. In this blog, I’ll show you how to connect Resin with Chainsaw using a technique that can be extended to other Log4j-based analysis tools.