-
15. Re: PROTOTYPE - Transaction DataSource in a POJO environment
adrian.brock May 4, 2005 3:53 PM (in response to adrian.brock)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). -
16. Re: PROTOTYPE - Transaction DataSource in a POJO environment
adrian.brock May 4, 2005 6:25 PM (in response to adrian.brock)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. -
17. Re: PROTOTYPE - Transaction DataSource in a POJO environment
bill.burke May 4, 2005 6:52 PM (in response to adrian.brock)JCA is so tiny compared to everything else it doesn't really matter.
Demoes are a waste of time. If this is just a demo, I'm stopping right now...
BTW, TM, JNDI, EJB3 is 11.4 megabytes of jars so far. WHen I get JCA complete, we'll see how much else. -
18. Re: PROTOTYPE - Transaction DataSource in a POJO environment
adrian.brock May 4, 2005 7:10 PM (in response to adrian.brock)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. -
19. Re: PROTOTYPE - Transaction DataSource in a POJO environment
adrian.brock May 4, 2005 8:45 PM (in response to adrian.brock)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. -
20. Re: PROTOTYPE - Transaction DataSource in a POJO environment
tom.elrod May 6, 2005 1:12 PM (in response to adrian.brock)Is XMLKernelDeployer just a place holder? See that it is already deprecated in favor of BeanXMLDeployer.