You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aditya Gore <ad...@sun.com> on 2003/08/15 11:51:15 UTC
JDBC
How do we plan to implement JDBC support in the appserver? Will
it be a separate module or would it be closely associated with
the core/kernel both packaging and logic wise?
thanks,
:aditya
Re: JDBC
Posted by Bodo Wippermann <bo...@bodow.de>.
i don't really the pros and cons , but i think JDBC support should be a
separate module and not supported via JCA.
i have no real arguments for this proposal except that jsr77 spec also
handles them separately.
but thats only the mamnagement view of the J2EE Server, i doesn't force
us to implement is this way.
Bodo
David Jencks schrieb:
> IMNSHO jdbc support should be through the JCA (connector) support and
> jca-jdbc wrappers.
>
> I think jca should be a separate module ("connector")
>
> AFAIK the only specific communication with the ejb subsystem needed can
> be provided by an interceptor that makes sure connection handles get
> re-associated under the correct security context.
>
> thanks
> david jencks
>
> On Friday, August 15, 2003, at 05:51 AM, Aditya Gore wrote:
>
>> How do we plan to implement JDBC support in the appserver? Will
>> it be a separate module or would it be closely associated with
>> the core/kernel both packaging and logic wise?
>>
>> thanks,
>> :aditya
>>
>
>
[PATCH] spec/j2ee API 100% compliant
Posted by Maas van den Berg <em...@dds.nl>.
Thanks to the apiComparator plugin for IDEA.
- correct parameter names (important for javadoc / ide / etc?)
- Timer* use java.util.Date not java.sql.Date
- removed superclass exceptions from 'throws' list
- added missing @deprecated tags
Maas
wrote:
> What's the advantage to supporting JDBC through JCA? Is it that
> JCA requires logic to deal with associating with transactions and
> security, and if JDBC works through that we don't have to implement the
> same features twice? Or are there other considerations?
>
> Aaron
>
> On Fri, 15 Aug 2003, David Jencks wrote:
> > IMNSHO jdbc support should be through the JCA (connector) support and
> > jca-jdbc wrappers.
> >
> > I think jca should be a separate module ("connector")
> >
> > AFAIK the only specific communication with the ejb subsystem needed can
> > be provided by an interceptor that makes sure connection handles get
> > re-associated under the correct security context.
>
Re: ** PLEASE TRIM QUOTES **
Posted by toby cabot <to...@caboteria.org>.
(previous message elided at Noel's request)
<voice type="church lady">
As long as we're channelling Emily Postnews, please don't start new
threads by replying to messages in existing threads. It may take a
little longer to type the ML address in the "to" box, but the absence
of a spurious "in reply to" header makes the discussion easier to
follow since you can use the thread-level features of your mailer
without worrying about missing threads hidden in other threads.
</voice>
Starting with the next message ;)
Re: JDBC
Posted by Bruce Snyder <fe...@frii.com>.
This one time, at band camp, Maas van den Berg said:
MvdB>On Fri, 2003-08-15 at 23:30, Bruce Snyder wrote:
MvdB>> This one time, at band camp, Maas van den Berg said:
MvdB>>
MvdB>> MvdB>Just wanted to let you know that I've continued my braindead activities
MvdB>> MvdB>and just finished typing in the JCA apis. Don't know if we need them but
MvdB>> MvdB>they are here. I'll write some unittests and post the
MvdB>> MvdB>stuff in a bit.
MvdB>> MvdB>
MvdB>> MvdB>Maas
MvdB>> MvdB>
MvdB>> MvdB>On Fri, 2003-08-15 at 23:34, Aaron Mulder wrote:
MvdB>> MvdB>> What's the advantage to supporting JDBC through JCA? Is it that
MvdB>> MvdB>> JCA requires logic to deal with associating with transactions and
MvdB>> MvdB>> security, and if JDBC works through that we don't have to implement the
MvdB>> MvdB>> same features twice? Or are there other considerations?
MvdB>> MvdB>>
MvdB>> MvdB>> Aaron
MvdB>> MvdB>>
MvdB>> MvdB>> On Fri, 15 Aug 2003, David Jencks wrote:
MvdB>> MvdB>> > IMNSHO jdbc support should be through the JCA (connector) support and
MvdB>> MvdB>> > jca-jdbc wrappers.
MvdB>> MvdB>> >
MvdB>> MvdB>> > I think jca should be a separate module ("connector")
MvdB>> MvdB>> >
MvdB>> MvdB>> > AFAIK the only specific communication with the ejb subsystem needed can
MvdB>> MvdB>> > be provided by an interceptor that makes sure connection handles get
MvdB>> MvdB>> > re-associated under the correct security context.
MvdB>>
MvdB>> Great, when you're finished, please send them to me and I'll get them
MvdB>> checked in. Also, please make sure that you use the following version
MvdB>> taglet in the class level Javadoc for all classes:
MvdB>>
MvdB>> @version $Revision$ $Date$
MvdB>>
MvdB>> Bruce
MvdB>
MvdB>I'll will.
MvdB>I should use the LICENSE with the tailing line comments stating 'hands
MvdB>off etc...', instead of the version where these remarks are included
MvdB>within ASF license block comment, right ?
Take a look at the other classes and you'll see that they're including
the full ASF license v 1.1 in the head of each .java file.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
Re: JDBC
Posted by Maas van den Berg <em...@dds.nl>.
On Fri, 2003-08-15 at 23:30, Bruce Snyder wrote:
> This one time, at band camp, Maas van den Berg said:
>
> MvdB>Just wanted to let you know that I've continued my braindead activities
> MvdB>and just finished typing in the JCA apis. Don't know if we need them but
> MvdB>they are here. I'll write some unittests and post the
> MvdB>stuff in a bit.
> MvdB>
> MvdB>Maas
> MvdB>
> MvdB>On Fri, 2003-08-15 at 23:34, Aaron Mulder wrote:
> MvdB>> What's the advantage to supporting JDBC through JCA? Is it that
> MvdB>> JCA requires logic to deal with associating with transactions and
> MvdB>> security, and if JDBC works through that we don't have to implement the
> MvdB>> same features twice? Or are there other considerations?
> MvdB>>
> MvdB>> Aaron
> MvdB>>
> MvdB>> On Fri, 15 Aug 2003, David Jencks wrote:
> MvdB>> > IMNSHO jdbc support should be through the JCA (connector) support and
> MvdB>> > jca-jdbc wrappers.
> MvdB>> >
> MvdB>> > I think jca should be a separate module ("connector")
> MvdB>> >
> MvdB>> > AFAIK the only specific communication with the ejb subsystem needed can
> MvdB>> > be provided by an interceptor that makes sure connection handles get
> MvdB>> > re-associated under the correct security context.
>
> Great, when you're finished, please send them to me and I'll get them
> checked in. Also, please make sure that you use the following version
> taglet in the class level Javadoc for all classes:
>
> @version $Revision$ $Date$
>
> Bruce
I'll will.
I should use the LICENSE with the tailing line comments stating 'hands
off etc...', instead of the version where these remarks are included
within ASF license block comment, right ?
Maas
Re: JDBC
Posted by Bruce Snyder <fe...@frii.com>.
This one time, at band camp, Maas van den Berg said:
MvdB>Just wanted to let you know that I've continued my braindead activities
MvdB>and just finished typing in the JCA apis. Don't know if we need them but
MvdB>they are here. I'll write some unittests and post the
MvdB>stuff in a bit.
MvdB>
MvdB>Maas
MvdB>
MvdB>On Fri, 2003-08-15 at 23:34, Aaron Mulder wrote:
MvdB>> What's the advantage to supporting JDBC through JCA? Is it that
MvdB>> JCA requires logic to deal with associating with transactions and
MvdB>> security, and if JDBC works through that we don't have to implement the
MvdB>> same features twice? Or are there other considerations?
MvdB>>
MvdB>> Aaron
MvdB>>
MvdB>> On Fri, 15 Aug 2003, David Jencks wrote:
MvdB>> > IMNSHO jdbc support should be through the JCA (connector) support and
MvdB>> > jca-jdbc wrappers.
MvdB>> >
MvdB>> > I think jca should be a separate module ("connector")
MvdB>> >
MvdB>> > AFAIK the only specific communication with the ejb subsystem needed can
MvdB>> > be provided by an interceptor that makes sure connection handles get
MvdB>> > re-associated under the correct security context.
Great, when you're finished, please send them to me and I'll get them
checked in. Also, please make sure that you use the following version
taglet in the class level Javadoc for all classes:
@version $Revision$ $Date$
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
** PLEASE TRIM QUOTES **
Posted by "Noel J. Bergman" <no...@devtech.com>.
Guys,
We have a whole nice archiving system. Please trim quotes. I can't tell
you how many pages I've read through today to get to a few sentences of
content.
Archives:
http://nagoya.apache.org/eyebrowse/SummarizeList?listName=geronimo-dev@incub
ator.apache.org
--- Noel
Re: JDBC
Posted by David Jencks <da...@snappydsl.net>.
On Friday, August 15, 2003, at 05:23 PM, Maas van den Berg wrote:
> Hi all,
>
> Just wanted to let you know that I've continued my braindead activities
> and just finished typing in the JCA apis. Don't know if we need them
> but
> they are here. I'll write some unittests and post the
> stuff in a bit.
We do need them and many thanks. I'm starting to think about writing a
set of ConnectionManagers based on an interceptor stack, hopefully this
will provide a cleaner and easier to understand implementation than
what I wrote for JBoss.
>
> Maas
>
> On Fri, 2003-08-15 at 23:34, Aaron Mulder wrote:
>> What's the advantage to supporting JDBC through JCA? Is it that
>> JCA requires logic to deal with associating with transactions and
>> security, and if JDBC works through that we don't have to implement
>> the
>> same features twice? Or are there other considerations?
AFAIK it is to only implement the features once.
thanks
david jencks
>>
>> Aaron
>>
>> On Fri, 15 Aug 2003, David Jencks wrote:
>>> IMNSHO jdbc support should be through the JCA (connector) support and
>>> jca-jdbc wrappers.
>>>
>>> I think jca should be a separate module ("connector")
>>>
>>> AFAIK the only specific communication with the ejb subsystem needed
>>> can
>>> be provided by an interceptor that makes sure connection handles get
>>> re-associated under the correct security context.
>>
>
Re: JDBC
Posted by Maas van den Berg <em...@dds.nl>.
Hi all,
Just wanted to let you know that I've continued my braindead activities
and just finished typing in the JCA apis. Don't know if we need them but
they are here. I'll write some unittests and post the
stuff in a bit.
Maas
On Fri, 2003-08-15 at 23:34, Aaron Mulder wrote:
> What's the advantage to supporting JDBC through JCA? Is it that
> JCA requires logic to deal with associating with transactions and
> security, and if JDBC works through that we don't have to implement the
> same features twice? Or are there other considerations?
>
> Aaron
>
> On Fri, 15 Aug 2003, David Jencks wrote:
> > IMNSHO jdbc support should be through the JCA (connector) support and
> > jca-jdbc wrappers.
> >
> > I think jca should be a separate module ("connector")
> >
> > AFAIK the only specific communication with the ejb subsystem needed can
> > be provided by an interceptor that makes sure connection handles get
> > re-associated under the correct security context.
>
Re: JDBC
Posted by David Jencks <da...@snappydsl.net>.
On Saturday, August 16, 2003, at 01:05 AM, Aditya Gore wrote:
>
>> What's the advantage to supporting JDBC through JCA? Is it that JCA
>> requires logic to deal with associating with transactions and
>> security, and if JDBC works through that we don't have to implement
>> the same features twice? Or are there other considerations?
>
> That's correct.
>
> However there are some cons while using this too, the biggest by
> far being that the speed of JDBC access is hit.
In the absence of an implementation, what evidence do you have for this
claim?
thanks
david jencks
>
> :aditya
>
>
>> Aaron
>> On Fri, 15 Aug 2003, David Jencks wrote:
>>> IMNSHO jdbc support should be through the JCA (connector) support
>>> and jca-jdbc wrappers.
>>>
>>> I think jca should be a separate module ("connector")
>>>
>>> AFAIK the only specific communication with the ejb subsystem needed
>>> can be provided by an interceptor that makes sure connection handles
>>> get re-associated under the correct security context.
>>>
>
>
Re: JDBC
Posted by Aditya Gore <ad...@sun.com>.
> What's the advantage to supporting JDBC through JCA? Is it that
> JCA requires logic to deal with associating with transactions and
> security, and if JDBC works through that we don't have to implement the
> same features twice? Or are there other considerations?
That's correct.
However there are some cons while using this too, the biggest by
far being that the speed of JDBC access is hit.
:aditya
>
> Aaron
>
> On Fri, 15 Aug 2003, David Jencks wrote:
>
>>IMNSHO jdbc support should be through the JCA (connector) support and
>>jca-jdbc wrappers.
>>
>>I think jca should be a separate module ("connector")
>>
>>AFAIK the only specific communication with the ejb subsystem needed can
>>be provided by an interceptor that makes sure connection handles get
>>re-associated under the correct security context.
>>
>
Re: JDBC
Posted by Bruce Snyder <fe...@frii.com>.
This one time, at band camp, Aaron Mulder said:
AM> What's the advantage to supporting JDBC through JCA? Is it that
AM>JCA requires logic to deal with associating with transactions and
AM>security, and if JDBC works through that we don't have to implement the
AM>same features twice? Or are there other considerations?
AM>
AM>Aaron
AM>
AM>On Fri, 15 Aug 2003, David Jencks wrote:
AM>> IMNSHO jdbc support should be through the JCA (connector) support and
AM>> jca-jdbc wrappers.
AM>>
AM>> I think jca should be a separate module ("connector")
AM>>
AM>> AFAIK the only specific communication with the ejb subsystem needed can
AM>> be provided by an interceptor that makes sure connection handles get
AM>> re-associated under the correct security context.
I agree completely with David on this one. JCA will provide Geronimo
with many benefits at the connector level of the resoure adapter
such as pooling, transactions and security.
JCA 1.5 introduces the concept of inbound connectors which introduce
some new and extremely powerful contracts. There are four new contracts
including message inflow, transaction inflow, lifecycle management and
work management.
- The message inflow contract supports the asynchronous delivery of
messages without concern for the messaging protocol. This means no
more restriction to JMS messaging only.
- The transaction inflow contract supports the propagation of an imported
transaction from outside the app server.
- The lifecycle management contract introduces the start and stop of a
resource adapter.
- The work management contract provides optional support for thread management
by the app server.
IMNSHO, these service are absolutely necessary when developing
Geronimo. It means that many core services can become JCA connectors
and reap the benefits of the JCA contracts.
OK, I'll step off of my soapbox now ;-).
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
Re: JDBC
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
What's the advantage to supporting JDBC through JCA? Is it that
JCA requires logic to deal with associating with transactions and
security, and if JDBC works through that we don't have to implement the
same features twice? Or are there other considerations?
Aaron
On Fri, 15 Aug 2003, David Jencks wrote:
> IMNSHO jdbc support should be through the JCA (connector) support and
> jca-jdbc wrappers.
>
> I think jca should be a separate module ("connector")
>
> AFAIK the only specific communication with the ejb subsystem needed can
> be provided by an interceptor that makes sure connection handles get
> re-associated under the correct security context.
Re: JDBC
Posted by David Jencks <da...@snappydsl.net>.
IMNSHO jdbc support should be through the JCA (connector) support and
jca-jdbc wrappers.
I think jca should be a separate module ("connector")
AFAIK the only specific communication with the ejb subsystem needed can
be provided by an interceptor that makes sure connection handles get
re-associated under the correct security context.
thanks
david jencks
On Friday, August 15, 2003, at 05:51 AM, Aditya Gore wrote:
> How do we plan to implement JDBC support in the appserver? Will
> it be a separate module or would it be closely associated with
> the core/kernel both packaging and logic wise?
>
> thanks,
> :aditya
>