JBossDeveloper

We should probably also look at providing trimmed binaries
for POJO/embeddable.

e.g. There is no need to include org.jboss.resource.adapter.jdbc.remote
or the jca deployer or the inbound jca processing, etc.
In this case, JBoss/JCA could provide a jbosscx-core.jar (or
whatever naming convention we want to use).

I don't think JMS/timers/remoting and even security
belong on this list for the first demo release.
Unless you are talking about simple mock objects?

We are trying to create an embeddable EJB3 container for use in
something like a junit test.

We are not trying to reproduce what will become JBoss5 under the auspices
of an EJB3 demo.

Refactoring JBossMQ/JBossSX/etc. to be pojo based is going to take
too much time for an initial release and it isn't something that is going to
happen in JBoss4 anyway.

It is wasted effort, especially, when there is a much easier mechanism provided by the
AOP/MC JMX processing that allows the old JMX and the new MC to work together
and a more "lazy" timescale for POJOizing the other services.

The effort is about DEMOnstrating the ability to use EJB3 in a POJO environment,
e.g. unit tests/Tomcat/etc.

It is NOT an alternative to the full POJO environment solution which will come with
JBoss5 or a replacement for the core solution which is JBossAS.
It is however a step/bridge on the way that will show the direction and allow
early adoption. Call it JBoss-4.2.x if you like.

Anyway, that is just my opinion/focus.
Hence the reason why I didn't want to spend time on this task.

Just to clear in case you think I'm being arbitrary...

If you examine the use case for EJB3 standalone and these
services it fails the 5%/95% rule for the first release.

Security
junit: you aren't going to run your tests against the corporate ldap server
tomcat: you'd use their native realm abstraction
swing: it would only be useful if you are also operating in client/server mode and want single sign-on

JMS
If you want *co-located* jms and EJB3 you can use JBossAS/EJB3,
otherwise you just need the jndi config for the remote jms.

Remoting
All you need is to marshall the invocation to simulate call-by-value
and that is only so you can test remote access properly in junit.
You aren't going to expose standalone EJB3 sessions
remotely from Tomcat or Swing.

etc.