Sivakumar Thyagarajan's Blog
Connectors 1.6 technical session at JavaOne 2009
Binod and I are talking about Connectors 1.6 (JSR 322) in JavaOne 2009 about the updates to the specification and the work that has been done in the JSR
322 expert group leading to the latest proposed final draft version.
Details of the session:
ID#: TS-4733
Title: Java™ Platform, Enterprise Edition Technology-Based Connector Architecture 1.6
Date: 05-JUN-09
Time: 10:50 AM-11:50
AM
Venue: Moscone
Room: Gateway 104
Please attend this session if you want to learn more about the new features planned for the Java EE Connector Architecture 1.6 technology.
Arun Gupta recently recorded me providing a short blurb video about this talk and I have embedded it below.
Posted at 11:08AM Jun 01, 2009 by Sivakumar Thyagarajan in connectors16_jsr322 | Comments[0]
Connectors 1.6 Proposed Final Draft and the availability of Java EE SDK Preview
The JSR 322 expert group released the proposed final draft (PFD) of the Java EE Connectors 1.6 specification during mid-Febraury 2009.
We had covered the features introduced in the earlier milestones of the
specification in this blog (see entries on early draft and public review).
Some of the changes and new features introduced in the PFD draft are:
- Config property attributes: New attributes (See Section 5.3.7.6) have been introduced to configuration properties to indicate if they
- support dynamic updates: to indicate to the application server that dynamically reconfiguring the config property is supported by the resource adapter
- are confidential: to indicate that a particular configuration property is confidential, so that deployment/runtime tools could use special visual aids denoting confidentiality and not expose the values as plain text.
- The original InflowContext interfaces have been renamed to WorkContext or its equivalent, as the interfaces were not relevant only during Message Inflow but during all Work processing. (See Ch.11 and 16)
- Robust handling of error conditions during MessageEndpoint creation and Work submission: Enhanced the MessageEndpoint creation APIs to support timeouts and also enhanced the exceptions thrown by the MessageEndpointFactory and WorkManager to handle retryable scenarios. (See 13.3 and 10.3.3 for more details)
- Provide guidelines on the relationship of the Connector Architecture and other integration technologies such as Java Business Integration (JBI) and Service Component Architecture (SCA). (See Section 1.5)
- Updated the ease of development annotations and contracts, that were introduced in the Public Review draft of the specification, to address feedback received. (See the change history, Section I.1, for a list of changes and Ch. 18 for more details)
- Misc updates and clarifications to the Connection and
Transaction Management chapters (see the change history, Section I.1
for a complete list of changes).
As you might know, the reference implementation for the Connectors specifications and other components specifications in the Java EE 6 platform are developed in the GlassFish community. Now, with the release of the Java EE 6 SDK early access in JavaOne, most of the features in the PFD draft are now available for you to try out.
Jagadish, the lead of the Connectors technology reference implementation in GlassFish, has blogged recently about how a resource adapter can be built using the new metadata annotations introduced in the spec and demonstrates how the use of the EoD features could reduce the need for redundant boilerplate code and eliminate/reduce the need for XML deployment descriptors. Please also go through the Connectors 1.6 mail-connector sample that he has made available through the Java EE 6 Preview SDK to understand how these annotations could be used while developing a resource adapter.
Posted at 10:30AM Jun 01, 2009 by Sivakumar Thyagarajan in connectors16_jsr322 | Comments[1]
Connectors 1.6 Public Review available
The JSR 322
expert group has been working hard on defining new features,
addressing comments from the public and improving the early
draft. We are happy to announce that the Public Review Draft document
is now available off the JSR page in JCP. This blog introduces some of the new
and noteworthy features that are part of this draft.
Given the short
time between Public Draft and Proposed Final Draft, it would
be great if you could read the draft and send your feedback to the
expert group as soon as you can.
As mentioned above, this draft also addresses early draft related
comments that we received from the community and so we encourage you to
help us continue that effort by sending your review comments to the JSR
comments alias
jsr-322-comments@jcp.org
or in this blog.
Some of the major new features in the public review draft are:
- Ease of Development (EoD) through use of metadata annotations, optional deployment descriptor(ra.xml),better defaults, optional configuration etc.
- Integration with JSR 303: Bean Validation specification to handle validation requirements of configuration properties in various resource adapter JavaBeans.
- Support for Distributed
Work Processing and Work
processing Hints
Here is a brief overview of the new features:
- Ease of Development through metadata annotations: Java EE 5 brought in a huge change in the enterprise application programming model through the introduction of EoD enhancements such as the use of metadata annotations, better defaults, removal of boilerplate code etc. These improvements simplified component development to a great extent while still retaining the richness and the power of the technology.
The spec now defines (in Chapter 18) a simplified API for development of resource adapters. The goal of the API was to simplify the development of resource adapter implementations for programmers who are just starting with resource adapters, or developing resource adapters of small to medium complexity.Through the introduction of new metadata annotations, the specification now reduces or completely eliminates the need to deal with a deployment descriptor(ra.xml) in many cases.
The new annotations defined in the spec are:
- @Connector: specify that the JavaBean is a resource adapter JavaBean. Used to provide metadata about the capabilities provided by the resource adapter. It is optional to provide a JavaBean implementing the ResourceAdapter interface. [However, there are scenarios where a resource adapter may want to provide an implementation -- see Section 18.4.1]
- @ConfigProperty: specifies to the application server, that the decorated property is a configuration property for that JavaBean. Configuration Properties are now auto-discoverable by the application server and hence need not specified using the deployment descriptor.
- @ConnectionDefinition(s): defines a set of connection interfaces and classes pertaining to a particular connection type (identical to the role played by the connection-definition element in ra.xml).
- @Activation: designate a JavaBean as an ActivationSpec JavaBean
- @AdministeredObject:
designates a JavaBean as an administered object.
[Please note: Metadata annotations and some new usecases (Resource injection, definition of a component naming context (ENC) for resource adapters etc) are still being actively discussed in the Expert group and hence these interfaces must be considered as work-in-progress and may go through changes in the next phases of the specification. -- We would also love to hear from the community on their thoughts on the proposed annotations and EoD capabilities defined so far.]
As the reference implementation is developed, I will follow up with more samples showcasing the use of annotations while building connectors. So, stay tuned.
- JavaBean Validation: The Bean Validation (JSR 303) specification is "defining a meta-data model and API for JavaBean validation based on annotations, with overrides and extended meta-data through the use of XML validation descriptors." The Connector spec now allows its JavaBeans such as ResourceAdapter, ManagedConnectionFactory, ActivationSpec, AdministeredObject and InteractionSpec to be decorated with the Bean Validation constraint annotations. This now provides the RA developer a richer and standard way of expressing their constraints and also get the configuration of a JavaBean validated prior to use. Please see Section 5.3.7.5 in the spec for more information
- Distributed
Work Processing: In deployment runtimes which span
multiple VMs/hosts, it is useful to have Work instances that were
submitted by a resource adapter to a local WorkManager to be
distributed to a different remote WorkManager, for reasons of
scaling, performance etc. The specification defines a mechanism to
allow such distributed Work processing. See Section 10.3.11 for more
information on this
feature.
- Work
processing hints: The specification also now enables a
resource adapter to pass quality-of-service metadata to the WorkManager
during the submission of a Work instance. The WorkManager
implementation of the application server may then use the specified
hints to control the execution of the Work instance. For those who
followed the InflowContext mechanism defined in the Early Draft, the
propagation of QoS hints is defined as a standard InflowContext,
HintsInflowContxt. See Section 11.7 for more information on this.
Posted at 10:10AM Dec 05, 2008 by Sivakumar Thyagarajan in connectors16_jsr322 |
Connectors 1.6 Early Draft Specification now available!
I am very happy to announce that the Early Draft of the JavaTM
EE Connector Architecture 1.6 specification is available now.
We started to work on an update to the earlier Connectors specification
(J2EE
Connector Architecture 1.5) in the Expert Group of JSR 322
in January this year. The Expert Group has been working very hard on
the Early Draft and we are looking forward to hear your feedback.
Please send your feedback and comments to jsr-322-comments@jcp.org.
The purpose of the Java EE Connector Architecture 1.6 specification is
to address some areas in the earlier specification, where further
support has been requested by the developer/user community and the
expert group. Some of the important features that are being planned to
be addressed in this release include:
- Generic Inflow Context: a mechanism for enabling a resource adapter to provide additional contextual information while a Work gets executed by the application server's WorkManager
- Security Inflow: enabling a resource adapter to propagate security identity information during Work execution and delivery to MessageEndpoints(MDBs)
- General improvements to the specification: in the areas of handling connection failures, inbound and outbound configuration consistency, better configuration property processing (ability to specify better validation rules etc) and clarifications around the classloading of standalone resource adapters.
- Focus on
ease-of-development of resource adapters. Aligning with
common programming
model of Java EE by defining helper classes and
annotations for the Connector API wherever applicable.
). Here is a brief overview of the features that have been discussed and made it to the early draft. This is not a comprehensive list and so please see the Change History (Section I.1) for more information on all the changes made to the specification, in this early draft.
- Generic Inflow Context: Certain Enterprise Information System (EIS) integration usecases requires the propagation of contextual information from the EIS to the application server. For example, a resource adapter may want to flow-in Security context information, (or in the case of an EIS that deals with conversational messaging, correlation information that might be necessary to recreate a conversational session state in the container) from the EIS to the application server during inbound message delivery. The resource adapter may also want to run a particular Work instance in the context of the "flown-in" Security information.
- Security Inflow Context: It is critical, in EIS integration scenarios, that all interactions between an application server and resource adapter are secure.To achieve end-to-end application security, it is important that all activities that a Work instance performs, including delivering messages to a MessageEndpoint (MDB) happens in the context of an established identity.
- Other changes: In addition to the two new changes discussed above, a suite of new features/changes have also been discussed in the early draft. A few of them are:
- a definition of minimum set of requirments that must besupported by a compliant Java EE Connectors Architecture 1.6 container within an implementation of any subset of the Java EE Full Profile (like a Web Profile). Refer Section 3.5
- an ability to specify the transaction support level of a resource adapter at runtime. Refer Section 7.13
- ClassLoading requirements for standalone resources adapters. Refer Section 19.3
Posted at 08:49PM Aug 07, 2008 by Sivakumar Thyagarajan in connectors16_jsr322 | Comments[9]
Java EE Connector 1.6 overview - JavaOne BoF presentation slides
Binod and I, along with the expert group of JSR 322, have been working on an update to the Java EE Connectors technology. This update, Java EE Connector Architecture 1.6 is planned to be part of Java EE 6.
We presented an overview of the updates currently being discussed in a BoF session in this year's JavaOne. Thanks to everyone who attended the session and for the interesting discussion during and after the session.
I received a few requests for the slides that we used in BoF 5634, and so I have made them available here (pdf). We are working on producing an early draft of the specification and it should be posted in the JSR home page in a few weeks. So, please stay tuned and let us know your feedback.
Posted at 11:26PM Jun 30, 2008 by Sivakumar Thyagarajan in connectors16_jsr322 |
GlassFish presentation at Open Source India Week in Bangalore
A technical
developer track was organized in Bangalore as part of Open Source India
Week (erstwhile
LinuxAsia )
earlier this week and I presented a technical session on GlassFish.
Some members in the audience wanted
access to the slides and I have made them available here.
It was an interactive presentation followed by a Q&A session. I have tried to record the questions, posed by the members in the audience, below.
- Commercial support offerings for GlassFish.
- In-memory JSP compilation and how to keepgenerated the resulting files
- While developing in an open-source environment, how does GlassFish manage requirements and feature requests from the community and yet maintain a determinate roadmap for the future? I don't think we (along with Sahoo) could provide a convincing answer to this question.
- Discussion around various source code branching schemes in an open source product and why GlassFish chose its current approach.
- Tooling
(IDE support) options for
Metro and building interoperable web-services
Posted at 08:22PM Feb 14, 2008 by Sivakumar Thyagarajan in Sun | Comments[4]
Will code for ... freedom!
You might have seen the announcement yesterday in the media or read it via Sun blog posts.
As the contest website says: "... Sun Microsystems is happy to announce the Code For Freedom contest where students across India contribute to the technologies that are empowering the participation age. Participating in this contest will provide you with precious industry experience while still learning in college. And there is more. We in turn reward you for your valuable contribution in taking the first steps towards the open source movement."
Sun's history indicates how a university could help in fostering innovation. One of our founder's engineering skills while at university is well known too.
So if you are a student in India this is a wonderful opportunity to learn , participate and win.
GlassFish is a participating project as well and instructions on how to contribute are available here.
Posted at 11:37AM Aug 16, 2007 by Sivakumar Thyagarajan in Sun | Comments[1]
GlassFish at foss.in 2006
|
Moinak and Joe has already written about the upcoming foss.in 2006 at IISc, Bangalore and how Sun is participating in the event this year as well. foss.in, like last year, promises to be an interesting meeting place for FOSS contributors in and around Bangalore and from across the world. The GlassFish engineering team would have a presence this year too at the event, with Prasad's talk on Project GlassFish as well as having a neat GlassFish/NetBeans demo at the Sun booth area. A lot of really interesting activities has happened around GlassFish in the last few months. So, if you are interested in GlassFish and would be attending foss.in 2006, please drop by the booth area and talk to us!! |
Update 2: The GlassFish Talk, as per the foss.in latest event schedule, is on Saturday 2pm afternoon [25th Nov] in Hall A/120
Posted at 12:11AM Nov 22, 2006 by Sivakumar Thyagarajan in Sun | Comments[1]
OpenJDK !!!!
Jag, Tim Bray, Mark Reinhold, Danny Coward, Eduardo at the Aquarium about GlassFish, Peter von der ahe, Joshua Marinacci has already written about it. This is a tremendous achievement and I for one, am very happy that duke is out too :)!!
Posted at 06:51PM Nov 13, 2006 by Sivakumar Thyagarajan in Sun |
Generic RA for JMS project updates
... for those who haven't noticed, some changes to the HEAD now have message redelivery feature we had hinted earlier and we also have a new document that shows how to integrate Sonic MQ with GlassFish/Sun Java System Application Server, thanks to my colleague Ramesh Parthasarathy.
Posted at 07:51PM Jul 28, 2006 by Sivakumar Thyagarajan in Sun |
ClassLoaders in GlassFish - a FAQ
|
We have had occasional queries in the forums and mailing lists about the GlassFish classloader hierarchy and/or how to limit visibility of custom library classes to certain components in GlassFish/Sun Java System Application Server. So here is an FAQ we came up with .. Let me know if this is useful and esp if you have a question that is not answered here.
|
Beware of bugs in the above code; I have only proved it correct, not tried it
- Donald Knuth
Note: Sun Java System Application Server and GlassFish is referred to
as "application server" through-out this post. Except for some sections
where it is explicitly indicated as valid only for Standard Edition/Enterprise Edition,
the rest of the FAQ is valid for GlassFish v1/Sun Java System Application Server
Platform Edition 9.0
Where do I learn about ClassLoaders in general?
There are a lot of documents available off the web that could help you
understand about ClassLoaders.
ClassLoader JavaDoc
Understanding Network Class Loaders
Loading, Linking and Initialization of the The Java Virtual Machine Specification
Blogs by Sundar on ClassLoading: Part 1, Part 2
The definitive paper: Dynamic Class Loading in the Java Virtual Machine (1998) - well explained and yet readable!
Where could I learn more about working with ClassLoaders of GlassFish/Sun Java
System Application Server?
The ClassLoaders chapter in the application server developer's guide is a
good place to begin.
How do I use a different xml parser with my application?
The application server by default uses the XML parser that comes with
the JDK (Tiger). You could also use a different JAXP compatible
implementation for an application. An application can be configured to
use a different JAXP implementation than the one bundled with the JDK,
by using the --libraries attribute while deploying the application.
This works due to JAXP's use of the Jar Service Provider discovery
mechanism specified in the Jar File Specification to determine the
concrete class to instantiate. More on how this works in a future blog entry :)
How do I control visibility scope of my libraries? [ie how do I control my libraries/
library classes to be available
o only to an application
o only to a cluster/config
o for the whole domain
The --libraries deploy time attribute for an application [as explained
in the "Application specific Class Loading" section of the classloader
chapter] can be used to specify runtime dependencies of an
application. There are two ways to refer to a library in the
--libraries list. When a relative path is specified [ie only the jar
name], the application server attempts to find the specified library
in domain-dir/lib/applibs.
For a library to be made available to the whole domain, you could
place the jar in domain-dir/lib or domain-dir/lib/classes, as
explained in the "Using the Common ClassLoader" section of the
classloader chapter. This is usally the case for JDBC drivers and
other utility libraries that are shared by all applicatins in the
domain.
For cluster wide use, copy the jars into the domains/domain1/config/xyz-config/lib directory.
Then add the jars in classpath-suffix or classpath-prefix element of xyz-config.
This will synchronize the jars for all server instances using xyz-config.
To summarize,
* domains/domain1/lib - domain wide scope, common classloader add the jars automatically
* domains/domain1/config/cluster1-config/lib - config wide, update classpath-prefix or classpath-suffix
* domains/domain1/lib/applibs - application scope, added to application class loader automatically
* domains/domain1/config/cluster1-config/lib/ext - adds to java.ext.dirs automatically
What is the preferred way to use a library jar with an
application (bundle with application vs. instance/lib/applibs,
instance/lib, install/lib, classpath-prefix, classpath-suffix,
instance/lib/ext, instance/lib/classes)?
Application Scoping
Use --libraries [domain-dir/lib/applibs] for the following usecases
+ The dependency needs to be resolved at deploy time
+ The dependency is specific to one or more applications alone in the
domain
+ Sharing a dependency for reducing memory footprint/sharing static
state etc.
Please remember that this is non-portable and it's usage is
GlassFish/Sun application server specific
Bundling with the application is useful when the dependent library
needs to be scoped to the application and no sharing is required.
Global Sharing
Place libraries in domain-dir/lib and domain-dir/lib/classes to add
libraries to the common classloader. This is commonly used for
libraries like JDBC drivers that used by multiple applications.
Requires an AS restart.
Code Patches and bundled library overrides
Use classpath-prefix when you want your libraries to be placed ahead of
application server implementation classes in the shared chain. Again
this is ideally used for placing application server
development/diagnostic patches.
Use classpath-suffix when you want libraries to be placed after of
application server implementation classes in the shared chain.
Optional Packages
domain-dir/lib/ext is a java.ext.dirs directory and is the location
for installing optional packages.
How do I use different JDBC drivers? Where should I copy the jar(s)?
It is recommended to place JDBC drivers, that are used by all the
applications in the domain, in domain-dir/lib or
domain-dir/lib/classes. A restart of the application server instance
is required today so that the JDBC drivers are visible to applications
deployed in the domain.
How do I call an EJB in a stand alone module from another stand
alone web app?
Please refer to the section titled "Packaging the Client JAR for One
Application in Another Application" in the classloaders glassfish
documentation.
When do I need to restart the application server to use a library jar?
Adding new jars to the following directories require an application
server restart
- domain-dir/lib and domain-dir/lib/classes
- classpath-prefix, classpath-suffix elements in domain.xml
- domain-dir/lib/ext
I see an access control error message when I am trying to use my
library? Help! OR When do I need to grant permission to the library in the
server.policy file?
This usually indicates that the default permissions granted to
applications are not sufficient, and additional permissions are
required for an application. For additional information on
server.policy and granting permission to applications, please refer to
the "Changing Permissions for an Application" section under "Securing
Applications" in the AS developer guide.
How do I have my application use libraries bundled with it against an equivalent library bundled in the application server [or] How do I have delegation inversion for specific libraries
This can be done for web applications alone. You can make the Web Classloader follow the delegation inversion model in the Servlet specification by setting delegate="false" in the class-loader element of the sun-web.xml file. It's safe to do this only for a web module that does not interact with any other modules. The default value for the delegate flag is true. Look at "ClassLoader Delegation" in the "Developing Web Applications" chapter for more information.
Update: There are some bugs in the ClassLoader chapter documentation available in the GlassFish site. So until the GlassFish docs are updated, please refer the ClassLoader chapter in the Sun Java System Application Server 9.1 documentation where the bugs have been fixed and is up-to-date. Thanks Rama for pointing this.
Technorati: GlassFish, ClassLoader, JavaEE
Posted at 11:15AM Jul 28, 2006 by Sivakumar Thyagarajan in Sun | Comments[3]
Gregor Samsa is a ... software bug?
|
Just came across this "Daily WTF" entry and loved it. If Kafka was alive now, would he ever metamorphosize Gregor Samsa into a software bug? :) Have you seen any similar interesting literary reference(s) in source code elsewhere?
|
Posted at 10:25PM Jul 24, 2006 by Sivakumar Thyagarajan in Personal |
JavaOne BoF 0491 - Developing J2EE™ Connector Architecture Resource Adapters
|
As mentioned in an earlier entry Frank Kieviet and I spoke at a BoF titled "Developing J2EE™ Connector Architecture Resource Adapters" in this year's JavaOne. Though the presentations for the technical sessions are available now on the JavaOne site, slides for the BoFs are not available. Frank has made the slides [pdf] for our BoF and an (amateur) audio recording of the presentation and Q/A session available. Please let us know any comments you may have. |
Technorati: GlassFish, JavaOne, JavaEE, J2EE
Posted at 09:41PM Jun 28, 2006 by Sivakumar Thyagarajan in Sun |
On Fermat, his last theorem and a musical??
|
I had liked an earlier book of Simon Singh and love numbers (well, who doesn't) and so grabbed the Fermat's Enigma from a local library a couple of weeks ago and happened to read it last week. After all who can resist a teaser that goes "I have discovered a truly marvelous demonstration of this proposition that this margin is too narrow to contain." Well, apparently a whole world of mathematicians have been on or helped this quest for 350 odd years, when an English mathematician of Princeton ("after working in isolation for eight years") finally cracked it, or did he? A truly rivetting account of a painstaking mathematical journey. Highly recommended for a wonderful Saturday/Sunday afternoon read. Apart from Simon Singh's clear lucid summary of some of the tricky mathematics surrounding the book (such that even a layperson, like me too ahem, can understand), what is commendable about the book, atleast IMO, was that it brings forward the interesting aspects of the lives of the mathematicians involved in the quest.
|
Now, what do I need to do to understand the proof ... sigh :)
Posted at 06:20PM Jun 28, 2006 by Sivakumar Thyagarajan in Personal |
java.net community corner minitalk at JavaOne 2006
|
One of the interesting booths in the JavaOne pavilion is the java.net community corner where projects built at java.net were showcased. Last year and this year, this pavilion also hosted a series of minitalks where java.net developers could give presentations on their projects. Last year I had given an introduction to Generic RA for JMS and this year, since we had seen enough interest in the project mailing lists, we gave a presentation on the Availability features in Generic RA for JMS. Binod also has a good writeup about how Generic RA enables JMS provider pluggability in GlassFish and other J2EE application servers.
|
The slides are available here and an audio recording [this year the minitalks were podcast live from the show floor] is available here ... and thanks again to the gentleman in the audience who helped me with his USB key!!
Technorati: GlassFish, JavaOne, JavaEE, J2EE
Posted at 12:59PM Jun 18, 2006 by Sivakumar Thyagarajan in Sun |
