JBoss Group has gotten a number of requests for an update on the rumors swirling that JBoss and Sun are going to come to terms on J2EE Certification. JBoss Group have named Bob Bickel (former GM of HP Middleware), as the person in charge of concluding an agreement with Sun for J2EE Certification. There are issues with the certification and open source (such as license-incompatibilities, closed tests, and which releases to certify [you can't ceritify cvs HEAD]).

There are work arounds to these issues (e.g. both parties agree that major dot releases are certified), and it sounds like they will all be resolved.

Below is JBoss Groups statement:

"JBoss Group has gotten a number of requests for an update on the rumors swirling that JBoss and Sun are going to come to terms on J2EE Certification. Given the interest in our community, we wanted to provide an update.

JBoss Group would like to be clear that we are fully committed to doing this as long as it does not impact the JBoss open source community in terms of license restrictions or decrease in quality or innovation. In fact, we have committed significant resources to accommodate Sun's requests. In addition, JBoss has named a person (Bob Bickel, former GM of HP Middleware) to lead the discussions with Sun with a mission to complete a contract as soon as possible. Bob has previously negotiated J2EE Certification contracts while at Bluestone and HP with Sun.

While we can not estimate the timing of completion on this complex issue, we are hopeful of a positive resolution in the near term."

TSS is currently getting more details from JBoss and will add them to the top of this thread as soon as possible.

Floyd

Did they only release the statement to you guys? i looked at the JBoss site and didn't see anything.
I would have liked to read the full statement. It is an important matter after all.

Bringing on a seasoned pro like Bob Bickel and committing to the J2EE certification should definitely enhance JBoss Group's image and further JBoss adoption in the bigger corporate accounts.

I wonder what the proprietary J2EE licensees are saying about this? It would definitely remove one of their more frequent selling arguments against JBoss.

Does JBoss have a compliant implementation of JMS 1.0?

Maybe I should ask this question in the JBoss JMS forum

 http://www.jboss.org/forum.jsp?forum=48

I didn't see this statement on the JBoss Web site, is it official? (apparently not)

Also, their Web site pretends that their latest release supports JSR 175 but all they have is xdoclet. When you reach the release notes, all mentions of JSR 175 have mysteriously disappeared.

Besides, we haven't even reached community review with JSR 175.

Microsoft closet lover... yeah, I can definitely see some similarities :-)

--
Cedric
http://beust.com/weblog

When I was talking to Bill Burke he was surprised to hear that JSR 175 was going to be a new class construct instead of just XDoclet type Javadoc tags (which, IMHO it should have been). JBoss should really send some people to JavaOne to keep up with the latest announcements from Sun. :-)

When I was talking to Bill Burke he was surprised to hear that JSR 175 was going to be a new class construct instead of just XDoclet type Javadoc tags (which, IMHO it should have been).

Annotations in comments are just a practical but temporary hack. You need a full statically typed system if you want to use all the power that metadata has to offer. It's a lesson that Microsoft learned in 1995, I'm glad Java is finally getting there.

JSR 175 is getting close to community review and it's in good shape. It's going to require some major adaptation work from generators and consumers of annotations alike, but it will be worth it.

JBoss should really send some people to JavaOne to keep up with the latest announcements from Sun. :-)

Not really necessary, all you need it take the time to look at the world around once in a while.

--
Cedric
http://beust.com/weblog

>
> Annotations in comments are just a practical but temporary hack. You need a full statically typed system if you want to use all the power that metadata has to offer. It's a lesson that Microsoft learned in 1995, I'm glad Java is finally getting there.
>
> JSR 175 is getting close to community review and it's in good shape. It's going to require some major adaptation work from generators and consumers of annotations alike, but it will be worth it.
>
> JBoss should really send some people to JavaOne to keep up with the latest announcements from Sun. :-)
>
> Not really necessary, all you need it take the time to look at the world around once in a while.
>
> --
> Cedric
> http://beust.com/weblog

Yes, I went to the JavaOne BOF on JSR-175. I still am disappointed that there is no dynamic interface to add metadata at runtime. Would be nice to be able to apply metadata on the fly or change values on the fly through an API rather than by reloading the class.

BTW, we sort of simulate JSR-175 with our AOP framework through XDoclet and/or XML and some of our new AOP services rely on metatags. Can't wait for the spec to have an implementation to play with.

Also, I don't appreciate people putting words in my mouth, Mr. Carreira.

Bill

Funny. I don't seem to remember our conversation.

Bill

Not so much... I tried using it in 3.0.x where apparently temporary queues are broken and in 3.2.0 it ships with a broken implementation where you need to fix an XML file I couldn't find in order to get it to work...

I used to be a huge JBoss fan but as I'm getting deeper into it the more I see the problems and the need for J2EE compliance. JBoss allows stuff that the RI does not (and visa versa) which makes me fret over the portability of some of the things I'm working on. Furthermore the authentication mechanizem is just a nightmare! There is no easy was (that works) to authenticate manually without writing a huge mess of JBoss specific code which isn't portable to newer versions of JBoss. There are lots of things that are just impossible to do with JBoss in an intuitive way:

Right now I wish that my Swing client could communicate natively with JBoss JMS. I got something working (but the problems with temporary queues broke me), however I have no idea how to get authentication working with JMS... This seems to me far from intuitive in the current implementation, furthermore the purchased documentation doesn't help at all with the whole authentication mess within JBoss and discusses extreem cases and brings up terms most of us don't really need to go into...

Yes I know, I get what I pay for ;)

As far as I can tell, they've had JMS 1.0 compliant implementation for a long time now.

> temporary queues are broken

How are they broken?

> 3.2.0 it ships with a broken implementation where you need to fix
> an XML file I couldn't find in order to get it to work...

Seems to work just fine for me. You're not using mySQL are you?

> JBoss allows stuff that the RI does not

Yes, JBoss must be the only J2EE server on the planet that does that... What 'stuff' do you mean exactly?

> authenticate manually without writing a huge mess of JBoss specific code

You can manually authenticate using JAAS.

> isn't portable to newer versions of JBoss

JAAS is.

> I have no idea how to get authentication working with JMS...

Check the documentation on how to set up security for EJB's, the JMS implementation uses the same security manager and authentication mechanism.

/T

The word compliant is not really vague in Java as it is in W3C standards. I worked quite a bit on compliance issues with Sun and to actually pass these tests (TCK tests) is a nightmare (in a good way) since it flushes out many portions of the system and of the spec that aren't necessarily clear. So while the JBoss JMS implementation might work in the same way as other JMS message queues calling it compliant might even be illegal (IANAL). If you wish to call it compliant its fine with me (I am not a Sun employee) but knowing the benefit that you can get from passing a TCK I myself won't consider JBoss as J2EE until it actually passes these tests, its a personal opinion of mine and AFAIK its also Sun's position.
 
> > temporary queues are broken
>
> How are they broken?

They just didn't receive any events if you created them on a remote machine. This is a known bug in 3.0.6 I was told on the forums that it was fixed in 3.2.x but by the time I got that reply I just gave up on trying to use remote JMS with JBoss, it seemed like too much of a hasstle. The main problem for me was to switch to 3.2.x which I hadn't tested in production with a project that needs to ship within a couple of months.

> > 3.2.0 it ships with a broken implementation where you need to fix
> > an XML file I couldn't find in order to get it to work...
>
> Seems to work just fine for me. You're not using mySQL are you?

No, I use hypersonic in early development and usually deploy on Postgress. It was also confirmed as a bug in the (if I am not mistaken) 3.2.1 version that I downloaded at the time, maybe its fixed in the newer version or occurs with specific usage, I didn't delve into it since I was hesitant as it is about going in the 3.2.x direction. I'll probably upgrade to it after our release version is out.

> > JBoss allows stuff that the RI does not
>
> Yes, JBoss must be the only J2EE server on the planet that does that... What 'stuff' do you mean
> exactly?

Yeha that didn't come out right ;)

I was talking about compliance with the spec such as having multiple findByPrimaryKey() methods in the home interface and "creative" inheritance of the home interfaces. I'm not clear on the spec's position on these issues and whether JBoss or the RI are right. However I know that our current application that runs fine on JBoss won't deploy on the RI.

> > authenticate manually without writing a huge mess of JBoss specific code
>
> You can manually authenticate using JAAS.

Not as far as I found out. You need to write a LoginModule (yes thats JAAS) but you need to use JBoss specific classes such as UsernamePasswordHandler. You need to bind the whole authentication into a SAR using a rather complex mechanizem and its a huge pain. If you got something simple going on then I'd love to hear about it but setting up my authentication was a nightmare.

In this project we need to set up the application and when it starts up place a default "administrator" that can later on add users. I have a UserBean and a RoleBean and I set up the DatabaseServerLoginModule. This sort of works. it requires you to modify the login-config.xml and you have to do it in the JBoss installation directory rather than in the ear itself. You can do a trick with a SAR file but that only works in 3.0.x and not 3.2.x/4.x. I'd rather place everything in the EAR so I won't have to ship JBoss to the clients but rather tell them to download it, this also simplifies the configuration to other team mates. I have an initialize() method in my session bean thats supposed to create the User and do some SQL setup:

1. The basic idea is to call facade.initialize() in a Servlet.init() method. This doesn't work since there is no authorized user.

2. I couldn't login() using jaas code since there was no user in the database to login to...

3. The solution suggested in the forums was to use unauthenticatedRole which won't work from the init method.

4. I opened a thread from the init() method waited then requested the servlet VIA http. This seemed to work, however now due to the authenticated role my basic security got screwed up...

This whole concept is really patchy and is highly targeted to web applications where this current application is a Swing client that doesn't need http and was designed to work over http only to work better with JBoss.

> > isn't portable to newer versions of JBoss
>
> JAAS is.

OK I know JAAS is a standard, but its implementation in JBoss leaves a lot to be desired in portability and simplicity. You see many posts in the forums complaining about implementing a simple database login which is what the majority need, this use case should be simplified and handled VIA deployment descriptors and not VIA code. Also the JAAS implementation should not require JBoss specific classes.

> > I have no idea how to get authentication working with JMS...
>
> Check the documentation on how to set up security for EJB's, the JMS implementation uses the
> same security manager and authentication mechanism.

How do you pass a role in a message you send from a remote Swing client? This just won't work and neither would "run-as".

Incorrect. This is a helper class implementing JAAS CallbackHandler interface. You can implement it directly if you wish to avoid dependency to JBoss libraries.

> a simple database login which is what the majority need, this use case
> should be simplified and handled VIA deployment descriptors and not VIA code.

You do not need to write code to do a database login. Configuring the deployment descriptors is enough.

> How do you pass a role in a message you send from a remote Swing client?

Pass the security credentials as part of the message payload and programmatically login in onMessage() on the server side.

/T

>
> Incorrect. This is a helper class implementing JAAS CallbackHandler interface.
> You can implement it directly if you wish to avoid dependency to JBoss
> libraries.

I remember reading about this being a requirement in a document, I never
actually checked whether this is true. Is it possible that it was once a
requirement but has since changed?
Anyway I will probably have to write a login manager for this project and
will find out soon enough, if you say so then I guess you know ;)

> > a simple database login which is what the majority need, this use case
> > should be simplified and handled VIA deployment descriptors and not VIA code.
>
> You do not need to write code to do a database login. Configuring the
> deployment descriptors is enough.

Didn't notice what I was writing, yes you are correct. I must have meant the
whole mess with the SAR file I had to write in the last project.

> > How do you pass a role in a message you send from a remote Swing client?
>
> Pass the security credentials as part of the message payload and
> programmatically login in onMessage() on the server side.

Within the MDB, or should I have a special listener outside of the application
server?

>
> Not as far as I found out. You need to write a LoginModule (yes thats JAAS) but you need to use JBoss specific classes such as UsernamePasswordHandler. You need to bind the whole authentication into a SAR using a rather complex mechanizem and its a huge pain. If you got something simple going on then I'd love to hear about it but setting up my authentication was a nightmare.
>
> In this project we need to set up the application and when it starts up place a default "administrator" that can later on add users. I have a UserBean and a RoleBean and I set up the DatabaseServerLoginModule. This sort of works. it requires you to modify the login-config.xml and you have to do it in the JBoss installation directory rather than in the ear itself. You can do a trick with a SAR file but that only works in 3.0.x and not 3.2.x/4.x. I'd rather place everything in the EAR so I won't have to ship JBoss to the clients but rather tell them to download it, this also simplifies the configuration to other team mates. I have an initialize() method in my session bean thats supposed to create the User and do some SQL setup:


Not true, we have been using a configuration-only dynamic security since 3.0.x up to 3.2.2RC2!

It is just a sar file containing only
Meta-inf/jboss-service.xml
Meta-inf/login-config.xml

The sar file is contained in the ear file, to get a single deploy unit.

^Torsten

> >"administrator" that can later on add users. I have a UserBean and a RoleBean and I set up the
> >DatabaseServerLoginModule. This sort of works. it requires you to modify the login-config.xml
> >and you have to do it in the JBoss installation directory rather than in the ear itself. You can do
> >a trick with a SAR file but that only works in 3.0.x and not 3.2.x/4.x. I'd rather place everything
> >in the EAR so I won't have to ship JBoss to the clients but rather tell them to download it, this
> >also simplifies the configuration to other team mates. I have an initialize() method in my
> >session bean thats supposed to create the User and do some SQL setup:
>
>
> Not true, we have been using a configuration-only dynamic security since 3.0.x up to 3.2.2RC2!
>
> It is just a sar file containing only
> Meta-inf/jboss-service.xml
> Meta-inf/login-config.xml

Can you point me at decent instructions on how to do this? I followed the instructions in the
purchased documentation which were completely incoherant and the resources on the web
don't really go into that type of details. We got this thing working with some code on JBoss 3.0.x
but now it won't deploy on 3.2.1 it might have been a problem with that release or its a problem
with the way we "guessed" things should work.

Anyway I dug quite deep into the code but there is a limit to what you can gather through all
the levels of abstraction in JBoss, where do you get that type of information? The forums seem
like the only option but they are not very useful in most of the cases I tried.

can anybody post a more detailed explanation?
thanks

> > In this project we need to set up the application and when it starts up place a default
> >"administrator" that can later on add users. I have a UserBean and a RoleBean and I set up the
> >DatabaseServerLoginModule. This sort of works. it requires you to modify the login-config.xml
> >and you have to do it in the JBoss installation directory rather than in the ear itself. You can do
> >a trick with a SAR file but that only works in 3.0.x and not 3.2.x/4.x. I'd rather place everything
> >in the EAR so I won't have to ship JBoss to the clients but rather tell them to download it, this
> >also simplifies the configuration to other team mates. I have an initialize() method in my
> >session bean thats supposed to create the User and do some SQL setup:
>
>
> Not true, we have been using a configuration-only dynamic security since 3.0.x up to 3.2.2RC2!
>
> It is just a sar file containing only
> Meta-inf/jboss-service.xml
> Meta-inf/login-config.xml

After much digging to find out how to do this, I found out the details.
I've added some pages to the jboss wiki:

http://www.jboss.org/wiki/Wiki.jsp?page=DynamicLoginConfig

Yes, JBoss is really, really trying to get the J2EE TCK (Test Compatability Kit) license agreement signed with Sun. Yes, there are lots of complications like how you do a closed source test in an open source community, and how an open souce community meets all of Sun's license requirements. However, I think we have come up with some very good ways of getting this done - including agreeing to pay a ton of money to Sun. It could take some time though given this is summer (vacations) and lawyers are involved...

By the way, I have been working with JBoss since September, and am happy to be working with them more closely now. I am continually amazed at what a great product this is, and how widely it is being used and deployed.

Bob Bickel