You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2006/11/14 01:03:50 UTC
DAS Container - First part ready for review....
Hi All
I have updated (Tuscany-904) with a new version of the DAS container.
This is based on the initial contribution that Amita did, with some
clean-up, refactoring and additions to try to fix a possible problem with
mutable properties that are shared among instance (pointed by Jim Marino)...
Currently, this is just the initial drop that I want to make available in
the trunk so other can start to take a look and Amita and I could
collaborate easier... unit testings, sample, etc are coming... I'd
appreciate if anyone could help get this to the trunk if there is nothing
wrong with this...
Couple Questions:
Could someone take a quick look at ComponentTypeLoader and see if it's
looking Ok ? I was not sure about what this loadFromSideFile means ? what is
the "side file"? Is this something particular to Script container ?
Also, I wasn't sure what time is the appropriate time to load the das config
file when provided ? Right now is being loaded at
DataAccessImplementationLoader, if you guys think this should go in a
different place, please let me know... also would be good to know why :)
Well, comments and feedback are welcome... Note that I'm still getting
familiar with the Container SPI, so, please let me know if I misunderstood
something on the implementation.
- Luciano Resende
Apache Tuscany
Re: DAS Container - First part ready for review....
Posted by Jim Marino <jm...@myromatours.com>.
On Nov 14, 2006, at 12:02 PM, Jeremy Boynes wrote:
> On 11/14/06, Jim Marino <jm...@myromatours.com> wrote:
>> >
>> One minor thing here. Unless the configuration values are always
>> immutable, an ObjectFactory should be injected otherwise one
>> component could accidentally modify a configuration parameter of
>> another as instances will be shared. When the component
>> implementation instance is created, the AtomicComponent will need to
>> call all of the ObjectFactory.getInstance methods to retrieve
>> configuration values that are injected. If the values are mutable,
>> the ObjectFactory will need to instantiate, copy or clone a value. If
>> the value is immutable, it can always pass the same one. In part of
>> the refactors to container.script, I introduced some code that does
>> this which can be used as an example.
>>
>
> This is really to protect against accidental (or malicious) alteration
> by a user-supplied implementation. I don't think this is necessary
> here as we should be able to trust the DAS implementation not to try
> and mutate the value.
I would strongly recommend it since code has a habit of getting
copied and in user-supplied implementations we shouldn't be so
trustworthy. An ObjectFactory is still free to make the optimization
of passing back the same immutable property instance :-)
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS Container - First part ready for review....
Posted by Jeremy Boynes <jb...@apache.org>.
On 11/14/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> One minor thing here. Unless the configuration values are always
> immutable, an ObjectFactory should be injected otherwise one
> component could accidentally modify a configuration parameter of
> another as instances will be shared. When the component
> implementation instance is created, the AtomicComponent will need to
> call all of the ObjectFactory.getInstance methods to retrieve
> configuration values that are injected. If the values are mutable,
> the ObjectFactory will need to instantiate, copy or clone a value. If
> the value is immutable, it can always pass the same one. In part of
> the refactors to container.script, I introduced some code that does
> this which can be used as an example.
>
This is really to protect against accidental (or malicious) alteration
by a user-supplied implementation. I don't think this is necessary
here as we should be able to trust the DAS implementation not to try
and mutate the value.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
I was having that due to an issue discussed and resolved here :
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10983.html
In summary, the das-container wasn't getting on the right place under
web-inf\...\extension
I have fixed this on my sandbox, and what is there + sample are loading ok
last time I tried (yesterday)...
I'm going to be offline for couple days, so I'll see what i can do to try to
help solve this... but i might be a little slow on the next couple days...
--
Luciano Resende
http://people.apache.org/~lresende
On 11/22/06, Amita Vadhavkar <am...@gmail.com> wrote:
>
> Hi Luciano,
> I followed JIRA-899 and the J2SE (my old client etc.) works fine.
> But for the war, (even the one from your sandbox, without any changes), I
> am
> getting the
> below error. This error was not there on 20th Nov :), So not sure if this
> is
> a result of
> some other JIRA/compatibility issues? I will try to get you online tonight
> IST and see
> if can get this working. Appreciate any clues/help in this. Due to this I
> am
> delaying
> on the JSP and other test cases. My sincere apologies.
> ____________________________________________________________________
> SEVERE: Exception sending context initialized event to listener instance
> of
> class org.apache.tuscany.runtime.webapp.TuscanyContextListener
> org.apache.tuscany.runtime.webapp.ServletLauncherInitException:
> org.apache.tuscany.spi.loader.UnrecognizedElementException: {
> http://tuscany.apache.org/xmlns/das/1.0}implementation.das [{
> http://tuscany.apache.org/xmlns/das/1.0}implementation.das]
> Context stack trace: [Tuscany DAS Container Sample Client
> Application][CustomersOrdersComponent]
> at org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(
> WebappRuntimeImpl.java:147)
> at
>
> org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextInitialized
> (
> TuscanyContextListener.java:74)
> at org.apache.catalina.core.StandardContext.listenerStart(
> StandardContext.java:3763)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java
> :4211)
> at org.apache.catalina.core.ContainerBase.addChildInternal(
> ContainerBase.java:759)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
> at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java
> :608)
> at org.apache.catalina.startup.HostConfig.deployDescriptors(
> HostConfig.java
> :535)
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
> at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java
> :310)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
> LifecycleSupport.java:119)
> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
> at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
> at org.apache.catalina.core.StandardService.start(StandardService.java
> :450)
> at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
> Caused by: org.apache.tuscany.spi.loader.UnrecognizedElementException: {
> http://tuscany.apache.org/xmlns/das/1.0}implementation.das [{
> http://tuscany.apache.org/xmlns/das/1.0}implementation.das]
> Context stack trace: [Tuscany DAS Container Sample Client
> Application][CustomersOrdersComponent]
> at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
> LoaderRegistryImpl.java:90)
> at org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(
> ComponentLoader.java:183)
> at org.apache.tuscany.core.loader.ComponentLoader.load(
> ComponentLoader.java
> :127)
> at org.apache.tuscany.core.loader.ComponentLoader.load(
> ComponentLoader.java
> :70)
> at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
> LoaderRegistryImpl.java:92)
> at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(
> CompositeLoader.java:81)
> at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(
> CompositeLoader.java:55)
> at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
> LoaderRegistryImpl.java:92)
> at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
> LoaderRegistryImpl.java:109)
> at
>
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile
> (CompositeComponentTypeLoader.java:65)
> at
>
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
> (CompositeComponentTypeLoader.java:57)
> at
>
> org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
> (CompositeComponentTypeLoader.java:39)
> at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(
> LoaderRegistryImpl.java:159)
> at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java
> :101)
> at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java
> :76)
> at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(
> AbstractRuntime.java:136)
> at org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(
> WebappRuntimeImpl.java:138)
> ... 25 more
> __________________________________________________________________________
> Regards,
> Amita
>
>
> On 11/20/06, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Just in case, by working with patches I mean to do something like :
> >
> > svn diff > /path/to/patchfile.patch
> >
> > This would create a patchfile.patch with only the difference from your
> > code relative to the one on the trunk (on this case sandbox) and I can
> > easily just apply the patch in my end.
> >
> > Let me know if you have questions...
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
> >
> >
> > On 11/20/06, Luciano Resende <lu...@gmail.com> wrote:
> > >
> > > Would you mind if we start working with patches from what I have on
> the
> > > sandbox ? that way i don't have to diff all files to check what you
> have
> > > modified.... also, you can be in sync with what I'm doing by calling
> svn
> > > updates....
> > >
> > > - Luciano
> > >
> > > On 11/20/06, Amita Vadhavkar <am...@gmail.com> wrote:
> > > >
> > > > Hi Luciano,
> > > > I have made the web app and the das container combination working.
> > There
> > > > were some class cast etc. problems in orginal code. Now the jsp is
> > > > showcasing
> > > > a working SELECT through getAllCompanies(). This work is attached to
> > > > JIRA-904. Please check it. I can modify it to showcase all CRUD + SP
> > > > in 1 more day. Please see if you can put it after that ( I will mail
> > you
> > > > once
> > > > work is completed and attached to JIRA). I feel, it will be better
> if
> > > > I attach any
> > > > work to JIRA and after you validate it, you can put it in your
> > sandbox.
> > > > Please
> > > > let me know if this is not convenient.
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > > > On 11/18/06, Luciano Resende < luckbr1975@gmail.com> wrote:
> > > > > I have commited some small changes and a simple web app to my
> > sandbox.
> > > > >
> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
> > > > >
> > > > > --
> > > > > Luciano Resende
> > > > > http://people.apache.org/~lresende<
> > http://people.apache.org/%7Elresende>
> > > > >
> > > > >
> > > > > On 11/17/06, Luciano Resende < luckbr1975@gmail.com> wrote:
> > > > > >
> > > > > > Jim and Kevin, thanks... I'm working on that...
> > > > > >
> > > > > > On 11/17/06, Kevin Williams <kevincbw@qwest.net > wrote:
> > > > > > >
> > > > > > > Jim Marino wrote:
> > > > > > >
> > > > > > > >> If I understood your question correctly, DAS allows a 1:1
> and
> > > > 1:N
> > > > > > > >> relationship,
> > > > > > > >> An application could have multiple components using the
> same
> > > > config
> > > > > > > >> file,
> > > > > > > >> or could split the config file based on the components
> > model...
> > > > > > > but the
> > > > > > > >> choice is really made by the app developer.
> > > > > > > >>
> > > > > > > > This sounds similar to the model JPA has with
> PersistenceUnit
> > > > and
> > > > > > > > Hibernate has with a SessionFactory. If I decide to share
> the
> > > > > > > > configuration, does DAS process the configuration once and
> put
> > > > it is
> > > > > > > > some object? For example, JPA has an EntityManagerFactory
> > which
> > > > > > > > processes a configuration. The factory is used to create an
> > > > > > > > EntityManager which is used by a JPA client.
> > > > > > > >
> > > > > > > > In the JPA integration work, the EntityManagerFactory is
> > created
> > > > and
> > > > > > > > cached as a system component in the application
> > > > composite. Something
> > > > > > > > similar could be done with DAS if this model fits.
> > > > > > > >
> > > > > > > Currently, The DAS Factory does not cache a processed config
> > > > model.
> > > > > > > Sounds like this is something we should consider.
> > > > > > >
> > > > > > > > Jim
> > > > > > > >
> > > > > > > >> - Luciano
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail:
> > tuscany-dev-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Luciano Resende
> > > > > > http://people.apache.org/~lresende
> > > > <http://people.apache.org/%7Elresende> <
> > > > http://people.apache.org/%7Elresende>
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > http://people.apache.org/~lresende <
> http://people.apache.org/%7Elresende
> > >
> > >
> >
> >
>
>
Re: DAS Container - First part ready for review....
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi Luciano,
I followed JIRA-899 and the J2SE (my old client etc.) works fine.
But for the war, (even the one from your sandbox, without any changes), I am
getting the
below error. This error was not there on 20th Nov :), So not sure if this is
a result of
some other JIRA/compatibility issues? I will try to get you online tonight
IST and see
if can get this working. Appreciate any clues/help in this. Due to this I am
delaying
on the JSP and other test cases. My sincere apologies.
____________________________________________________________________
SEVERE: Exception sending context initialized event to listener instance of
class org.apache.tuscany.runtime.webapp.TuscanyContextListener
org.apache.tuscany.runtime.webapp.ServletLauncherInitException:
org.apache.tuscany.spi.loader.UnrecognizedElementException: {
http://tuscany.apache.org/xmlns/das/1.0}implementation.das [{
http://tuscany.apache.org/xmlns/das/1.0}implementation.das]
Context stack trace: [Tuscany DAS Container Sample Client
Application][CustomersOrdersComponent]
at org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(
WebappRuntimeImpl.java:147)
at
org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextInitialized(
TuscanyContextListener.java:74)
at org.apache.catalina.core.StandardContext.listenerStart(
StandardContext.java:3763)
at org.apache.catalina.core.StandardContext.start(StandardContext.java
:4211)
at org.apache.catalina.core.ContainerBase.addChildInternal(
ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java
:608)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java
:535)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java
:310)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at org.apache.catalina.core.StandardService.start(StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Caused by: org.apache.tuscany.spi.loader.UnrecognizedElementException: {
http://tuscany.apache.org/xmlns/das/1.0}implementation.das [{
http://tuscany.apache.org/xmlns/das/1.0}implementation.das]
Context stack trace: [Tuscany DAS Container Sample Client
Application][CustomersOrdersComponent]
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:90)
at org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(
ComponentLoader.java:183)
at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java
:127)
at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java
:70)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:92)
at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(
CompositeLoader.java:81)
at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(
CompositeLoader.java:55)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:92)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(
LoaderRegistryImpl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile
(CompositeComponentTypeLoader.java:65)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:57)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:39)
at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(
LoaderRegistryImpl.java:159)
at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java
:101)
at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java
:76)
at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(
AbstractRuntime.java:136)
at org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(
WebappRuntimeImpl.java:138)
... 25 more
__________________________________________________________________________
Regards,
Amita
On 11/20/06, Luciano Resende <lu...@gmail.com> wrote:
>
> Just in case, by working with patches I mean to do something like :
>
> svn diff > /path/to/patchfile.patch
>
> This would create a patchfile.patch with only the difference from your
> code relative to the one on the trunk (on this case sandbox) and I can
> easily just apply the patch in my end.
>
> Let me know if you have questions...
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
>
>
> On 11/20/06, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Would you mind if we start working with patches from what I have on the
> > sandbox ? that way i don't have to diff all files to check what you have
> > modified.... also, you can be in sync with what I'm doing by calling svn
> > updates....
> >
> > - Luciano
> >
> > On 11/20/06, Amita Vadhavkar <am...@gmail.com> wrote:
> > >
> > > Hi Luciano,
> > > I have made the web app and the das container combination working.
> There
> > > were some class cast etc. problems in orginal code. Now the jsp is
> > > showcasing
> > > a working SELECT through getAllCompanies(). This work is attached to
> > > JIRA-904. Please check it. I can modify it to showcase all CRUD + SP
> > > in 1 more day. Please see if you can put it after that ( I will mail
> you
> > > once
> > > work is completed and attached to JIRA). I feel, it will be better if
> > > I attach any
> > > work to JIRA and after you validate it, you can put it in your
> sandbox.
> > > Please
> > > let me know if this is not convenient.
> > >
> > > Regards,
> > > Amita
> > >
> > > On 11/18/06, Luciano Resende < luckbr1975@gmail.com> wrote:
> > > > I have commited some small changes and a simple web app to my
> sandbox.
> > > > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
> > > >
> > > > --
> > > > Luciano Resende
> > > > http://people.apache.org/~lresende<
> http://people.apache.org/%7Elresende>
> > > >
> > > >
> > > > On 11/17/06, Luciano Resende < luckbr1975@gmail.com> wrote:
> > > > >
> > > > > Jim and Kevin, thanks... I'm working on that...
> > > > >
> > > > > On 11/17/06, Kevin Williams <kevincbw@qwest.net > wrote:
> > > > > >
> > > > > > Jim Marino wrote:
> > > > > >
> > > > > > >> If I understood your question correctly, DAS allows a 1:1 and
> > > 1:N
> > > > > > >> relationship,
> > > > > > >> An application could have multiple components using the same
> > > config
> > > > > > >> file,
> > > > > > >> or could split the config file based on the components
> model...
> > > > > > but the
> > > > > > >> choice is really made by the app developer.
> > > > > > >>
> > > > > > > This sounds similar to the model JPA has with PersistenceUnit
> > > and
> > > > > > > Hibernate has with a SessionFactory. If I decide to share the
> > > > > > > configuration, does DAS process the configuration once and put
> > > it is
> > > > > > > some object? For example, JPA has an EntityManagerFactory
> which
> > > > > > > processes a configuration. The factory is used to create an
> > > > > > > EntityManager which is used by a JPA client.
> > > > > > >
> > > > > > > In the JPA integration work, the EntityManagerFactory is
> created
> > > and
> > > > > > > cached as a system component in the application
> > > composite. Something
> > > > > > > similar could be done with DAS if this model fits.
> > > > > > >
> > > > > > Currently, The DAS Factory does not cache a processed config
> > > model.
> > > > > > Sounds like this is something we should consider.
> > > > > >
> > > > > > > Jim
> > > > > > >
> > > > > > >> - Luciano
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Luciano Resende
> > > > > http://people.apache.org/~lresende
> > > <http://people.apache.org/%7Elresende> <
> > > http://people.apache.org/%7Elresende>
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende
> >
> >
>
>
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
Just in case, by working with patches I mean to do something like :
svn diff > /path/to/patchfile.patch
This would create a patchfile.patch with only the difference from your
code relative to the one on the trunk (on this case sandbox) and I can
easily just apply the patch in my end.
Let me know if you have questions...
--
Luciano Resende
http://people.apache.org/~lresende
On 11/20/06, Luciano Resende <lu...@gmail.com> wrote:
>
> Would you mind if we start working with patches from what I have on the
> sandbox ? that way i don't have to diff all files to check what you have
> modified.... also, you can be in sync with what I'm doing by calling svn
> updates....
>
> - Luciano
>
> On 11/20/06, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > Hi Luciano,
> > I have made the web app and the das container combination working. There
> > were some class cast etc. problems in orginal code. Now the jsp is
> > showcasing
> > a working SELECT through getAllCompanies(). This work is attached to
> > JIRA-904. Please check it. I can modify it to showcase all CRUD + SP
> > in 1 more day. Please see if you can put it after that ( I will mail you
> > once
> > work is completed and attached to JIRA). I feel, it will be better if
> > I attach any
> > work to JIRA and after you validate it, you can put it in your sandbox.
> > Please
> > let me know if this is not convenient.
> >
> > Regards,
> > Amita
> >
> > On 11/18/06, Luciano Resende < luckbr1975@gmail.com> wrote:
> > > I have commited some small changes and a simple web app to my sandbox.
> > > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
> > >
> > > --
> > > Luciano Resende
> > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > >
> > >
> > > On 11/17/06, Luciano Resende < luckbr1975@gmail.com> wrote:
> > > >
> > > > Jim and Kevin, thanks... I'm working on that...
> > > >
> > > > On 11/17/06, Kevin Williams <kevincbw@qwest.net > wrote:
> > > > >
> > > > > Jim Marino wrote:
> > > > >
> > > > > >> If I understood your question correctly, DAS allows a 1:1 and
> > 1:N
> > > > > >> relationship,
> > > > > >> An application could have multiple components using the same
> > config
> > > > > >> file,
> > > > > >> or could split the config file based on the components model...
> > > > > but the
> > > > > >> choice is really made by the app developer.
> > > > > >>
> > > > > > This sounds similar to the model JPA has with PersistenceUnit
> > and
> > > > > > Hibernate has with a SessionFactory. If I decide to share the
> > > > > > configuration, does DAS process the configuration once and put
> > it is
> > > > > > some object? For example, JPA has an EntityManagerFactory which
> > > > > > processes a configuration. The factory is used to create an
> > > > > > EntityManager which is used by a JPA client.
> > > > > >
> > > > > > In the JPA integration work, the EntityManagerFactory is created
> > and
> > > > > > cached as a system component in the application
> > composite. Something
> > > > > > similar could be done with DAS if this model fits.
> > > > > >
> > > > > Currently, The DAS Factory does not cache a processed config
> > model.
> > > > > Sounds like this is something we should consider.
> > > > >
> > > > > > Jim
> > > > > >
> > > > > >> - Luciano
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Luciano Resende
> > > > http://people.apache.org/~lresende
> > <http://people.apache.org/%7Elresende> <
> > http://people.apache.org/%7Elresende>
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
Would you mind if we start working with patches from what I have on the
sandbox ? that way i don't have to diff all files to check what you have
modified.... also, you can be in sync with what I'm doing by calling svn
updates....
- Luciano
On 11/20/06, Amita Vadhavkar <am...@gmail.com> wrote:
>
> Hi Luciano,
> I have made the web app and the das container combination working. There
> were some class cast etc. problems in orginal code. Now the jsp is
> showcasing
> a working SELECT through getAllCompanies(). This work is attached to
> JIRA-904. Please check it. I can modify it to showcase all CRUD + SP
> in 1 more day. Please see if you can put it after that ( I will mail you
> once
> work is completed and attached to JIRA). I feel, it will be better if
> I attach any
> work to JIRA and after you validate it, you can put it in your sandbox.
> Please
> let me know if this is not convenient.
>
> Regards,
> Amita
>
> On 11/18/06, Luciano Resende <lu...@gmail.com> wrote:
> > I have commited some small changes and a simple web app to my sandbox.
> > https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> >
> >
> > On 11/17/06, Luciano Resende <lu...@gmail.com> wrote:
> > >
> > > Jim and Kevin, thanks... I'm working on that...
> > >
> > > On 11/17/06, Kevin Williams <ke...@qwest.net> wrote:
> > > >
> > > > Jim Marino wrote:
> > > >
> > > > >> If I understood your question correctly, DAS allows a 1:1 and 1:N
> > > > >> relationship,
> > > > >> An application could have multiple components using the same
> config
> > > > >> file,
> > > > >> or could split the config file based on the components model...
> > > > but the
> > > > >> choice is really made by the app developer.
> > > > >>
> > > > > This sounds similar to the model JPA has with PersistenceUnit and
> > > > > Hibernate has with a SessionFactory. If I decide to share the
> > > > > configuration, does DAS process the configuration once and put it
> is
> > > > > some object? For example, JPA has an EntityManagerFactory which
> > > > > processes a configuration. The factory is used to create an
> > > > > EntityManager which is used by a JPA client.
> > > > >
> > > > > In the JPA integration work, the EntityManagerFactory is created
> and
> > > > > cached as a system component in the application
> composite. Something
> > > > > similar could be done with DAS if this model fits.
> > > > >
> > > > Currently, The DAS Factory does not cache a processed config model.
> > > > Sounds like this is something we should consider.
> > > >
> > > > > Jim
> > > > >
> > > > >> - Luciano
> > > > >>
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > http://people.apache.org/~lresende <
> http://people.apache.org/%7Elresende>
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: DAS Container - First part ready for review....
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi Luciano,
I have made the web app and the das container combination working. There
were some class cast etc. problems in orginal code. Now the jsp is showcasing
a working SELECT through getAllCompanies(). This work is attached to
JIRA-904. Please check it. I can modify it to showcase all CRUD + SP
in 1 more day. Please see if you can put it after that ( I will mail you once
work is completed and attached to JIRA). I feel, it will be better if
I attach any
work to JIRA and after you validate it, you can put it in your sandbox. Please
let me know if this is not convenient.
Regards,
Amita
On 11/18/06, Luciano Resende <lu...@gmail.com> wrote:
> I have commited some small changes and a simple web app to my sandbox.
> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
>
> On 11/17/06, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Jim and Kevin, thanks... I'm working on that...
> >
> > On 11/17/06, Kevin Williams <ke...@qwest.net> wrote:
> > >
> > > Jim Marino wrote:
> > >
> > > >> If I understood your question correctly, DAS allows a 1:1 and 1:N
> > > >> relationship,
> > > >> An application could have multiple components using the same config
> > > >> file,
> > > >> or could split the config file based on the components model...
> > > but the
> > > >> choice is really made by the app developer.
> > > >>
> > > > This sounds similar to the model JPA has with PersistenceUnit and
> > > > Hibernate has with a SessionFactory. If I decide to share the
> > > > configuration, does DAS process the configuration once and put it is
> > > > some object? For example, JPA has an EntityManagerFactory which
> > > > processes a configuration. The factory is used to create an
> > > > EntityManager which is used by a JPA client.
> > > >
> > > > In the JPA integration work, the EntityManagerFactory is created and
> > > > cached as a system component in the application composite. Something
> > > > similar could be done with DAS if this model fits.
> > > >
> > > Currently, The DAS Factory does not cache a processed config model.
> > > Sounds like this is something we should consider.
> > >
> > > > Jim
> > > >
> > > >> - Luciano
> > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
I have commited some small changes and a simple web app to my sandbox.
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
--
Luciano Resende
http://people.apache.org/~lresende
On 11/17/06, Luciano Resende <lu...@gmail.com> wrote:
>
> Jim and Kevin, thanks... I'm working on that...
>
> On 11/17/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> > Jim Marino wrote:
> >
> > >> If I understood your question correctly, DAS allows a 1:1 and 1:N
> > >> relationship,
> > >> An application could have multiple components using the same config
> > >> file,
> > >> or could split the config file based on the components model...
> > but the
> > >> choice is really made by the app developer.
> > >>
> > > This sounds similar to the model JPA has with PersistenceUnit and
> > > Hibernate has with a SessionFactory. If I decide to share the
> > > configuration, does DAS process the configuration once and put it is
> > > some object? For example, JPA has an EntityManagerFactory which
> > > processes a configuration. The factory is used to create an
> > > EntityManager which is used by a JPA client.
> > >
> > > In the JPA integration work, the EntityManagerFactory is created and
> > > cached as a system component in the application composite. Something
> > > similar could be done with DAS if this model fits.
> > >
> > Currently, The DAS Factory does not cache a processed config model.
> > Sounds like this is something we should consider.
> >
> > > Jim
> > >
> > >> - Luciano
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
Jim and Kevin, thanks... I'm working on that...
On 11/17/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Jim Marino wrote:
>
> >> If I understood your question correctly, DAS allows a 1:1 and 1:N
> >> relationship,
> >> An application could have multiple components using the same config
> >> file,
> >> or could split the config file based on the components model...
> but the
> >> choice is really made by the app developer.
> >>
> > This sounds similar to the model JPA has with PersistenceUnit and
> > Hibernate has with a SessionFactory. If I decide to share the
> > configuration, does DAS process the configuration once and put it is
> > some object? For example, JPA has an EntityManagerFactory which
> > processes a configuration. The factory is used to create an
> > EntityManager which is used by a JPA client.
> >
> > In the JPA integration work, the EntityManagerFactory is created and
> > cached as a system component in the application composite. Something
> > similar could be done with DAS if this model fits.
> >
> Currently, The DAS Factory does not cache a processed config model.
> Sounds like this is something we should consider.
>
> > Jim
> >
> >> - Luciano
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: DAS Container - First part ready for review....
Posted by Kevin Williams <ke...@qwest.net>.
Jim Marino wrote:
>> If I understood your question correctly, DAS allows a 1:1 and 1:N
>> relationship,
>> An application could have multiple components using the same config
>> file,
>> or could split the config file based on the components model... but the
>> choice is really made by the app developer.
>>
> This sounds similar to the model JPA has with PersistenceUnit and
> Hibernate has with a SessionFactory. If I decide to share the
> configuration, does DAS process the configuration once and put it is
> some object? For example, JPA has an EntityManagerFactory which
> processes a configuration. The factory is used to create an
> EntityManager which is used by a JPA client.
>
> In the JPA integration work, the EntityManagerFactory is created and
> cached as a system component in the application composite. Something
> similar could be done with DAS if this model fits.
>
Currently, The DAS Factory does not cache a processed config model.
Sounds like this is something we should consider.
> Jim
>
>> - Luciano
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS Container - First part ready for review....
Posted by Jim Marino <jm...@myromatours.com>.
> If I understood your question correctly, DAS allows a 1:1 and 1:N
> relationship,
> An application could have multiple components using the same config
> file,
> or could split the config file based on the components model... but
> the
> choice is really made by the app developer.
>
This sounds similar to the model JPA has with PersistenceUnit and
Hibernate has with a SessionFactory. If I decide to share the
configuration, does DAS process the configuration once and put it is
some object? For example, JPA has an EntityManagerFactory which
processes a configuration. The factory is used to create an
EntityManager which is used by a JPA client.
In the JPA integration work, the EntityManagerFactory is created and
cached as a system component in the application composite. Something
similar could be done with DAS if this model fits.
Jim
> - Luciano
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
>I think this begs the question of what DAS "configuration" is. I'm
>not sure all configuration is part of a component type since the
>latter always has a 1:1 relationship with its implementation. For
>example, I believe the DAS configuration specifies mappings to
>database tables. Are these mappings potentially sharable across
>different components? JPA has the "PersistenceUnit" concept to
>express this. A PersistenceUnit defines the set of entities that can
>be managed by a particular context but must always correspond to one
>database. For example, an application may have one or more
>PersistenceUnits (I would imagine in typical cases it is one but not
>always). Related to this, configuration may define which DataSource
>to use. In DAS, is it possible that multiple <implementation.das>
>entries want to use the same mapping and DataSource configuration?
>If that is the case, you can probably do something similar to what
>Meeraj is doing with the JPA integration and have the configuration
>information parsed and cached as a special system service in the
>application composite. If so, we can drill down into more detail here.
If I understood your question correctly, DAS allows a 1:1 and 1:N
relationship,
An application could have multiple components using the same config file,
or could split the config file based on the components model... but the
choice is really made by the app developer.
- Luciano
On 11/14/06, Jim Marino <jmarino@myromatours.com > wrote:
>
>
> On Nov 14, 2006, at 8:15 AM, Venkata Krishnan wrote:
>
> > Hi,
> >
> > I have tried my best to explain... just in case something is not
> > right in
> > this could somebody pitch in please.
> >
> > Thanks.
> >
> > - Venkat
> >
> > On 11/14/06, Luciano Resende < luckbr1975@gmail.com> wrote:
> >>
> >> Hi All
> >>
> >> I have updated (Tuscany-904) with a new version of the DAS
> >> container.
> >> This is based on the initial contribution that Amita did, with some
> >> clean-up, refactoring and additions to try to fix a possible
> >> problem with
> >> mutable properties that are shared among instance (pointed by Jim
> >> Marino)...
> >> Currently, this is just the initial drop that I want to make
> >> available in
> >> the trunk so other can start to take a look and Amita and I could
> >> collaborate easier... unit testings, sample, etc are coming... I'd
> >> appreciate if anyone could help get this to the trunk if there is
> >> nothing
> >> wrong with this...
> >>
> >> Couple Questions:
> >>
> >> Could someone take a quick look at ComponentTypeLoader and see if
> >> it's
> >> looking Ok ? I was not sure about what this loadFromSideFile
> >> means ? what
> >> is
> >> the "side file"? Is this something particular to Script container ?
> >
> >
> > A sidefile is one way of exposing the configurable aspects of an
> > implementation. The other way is thro annotations. Yet another is to
> > follow some coding conventions so that this information is
> > introspectable.
> > The sidefile way of doing things is, to the best of what I
> > understand, a
> > common means across containers. i.e. you can have javascript, java,
> > ruby,
> > das (if you will) components all using the sidefile in a similar
> > manner as
> > this is prescribed by the specs.
> Yes component type is a common means but allows an implementation
> type (e.g. implementation.java, implementation.ruby) to extend the
> component type schema with specific metadata. Also, there is a 1:1
> relationship between a component type and an component implementation.
>
> > For the introspectable way you will see
> > Java and JavaScript vary in how they achieve this. The same goes for
> > annotations - right now the java container alone can leverage this
> > (as far
> > as I know).
> >
> > Also, I wasn't sure what time is the appropriate time to load the
> > das config
> >> file when provided ? Right now is being loaded at
> >> DataAccessImplementationLoader, if you guys think this should go in a
> >> different place, please let me know... also would be good to know
> >> why :)
> >
> >
> I think this begs the question of what DAS "configuration" is. I'm
> not sure all configuration is part of a component type since the
> latter always has a 1:1 relationship with its implementation. For
> example, I believe the DAS configuration specifies mappings to
> database tables. Are these mappings potentially sharable across
> different components? JPA has the "PersistenceUnit" concept to
> express this. A PersistenceUnit defines the set of entities that can
> be managed by a particular context but must always correspond to one
> database. For example, an application may have one or more
> PersistenceUnits (I would imagine in typical cases it is one but not
> always). Related to this, configuration may define which DataSource
> to use. In DAS, is it possible that multiple <implementation.das>
> entries want to use the same mapping and DataSource configuration?
>
> If that is the case, you can probably do something similar to what
> Meeraj is doing with the JPA integration and have the configuration
> information parsed and cached as a special system service in the
> application composite. If so, we can drill down into more detail here.
>
>
> > The config file could very well be read / parsed during 'load' time
> > using
> > the loader. The loading is just about picking up the component
> > definition
> > information from the scdl file and creating a java object model for
> > them.
> > The next phase is the 'build' phase where you must create the
> > necessary
> > runtime artifacts making use of the model you have defined in the
> > loading
> > phase. In your case I would imagine that you would inject the
> > config values
> > into the DAS Engine during the build time.
> >
> One minor thing here. Unless the configuration values are always
> immutable, an ObjectFactory should be injected otherwise one
> component could accidentally modify a configuration parameter of
> another as instances will be shared. When the component
> implementation instance is created, the AtomicComponent will need to
> call all of the ObjectFactory.getInstance methods to retrieve
> configuration values that are injected. If the values are mutable,
> the ObjectFactory will need to instantiate, copy or clone a value. If
> the value is immutable, it can always pass the same one. In part of
> the refactors to container.script, I introduced some code that does
> this which can be used as an example.
>
> > Well, comments and feedback are welcome... Note that I'm still getting
> >> familiar with the Container SPI, so, please let me know if I
> >> misunderstood
> >> something on the implementation.
> >
> >
> > - Luciano Resende
> >> Apache Tuscany
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: DAS Container - First part ready for review....
Posted by Jim Marino <jm...@myromatours.com>.
On Nov 14, 2006, at 8:15 AM, Venkata Krishnan wrote:
> Hi,
>
> I have tried my best to explain... just in case something is not
> right in
> this could somebody pitch in please.
>
> Thanks.
>
> - Venkat
>
> On 11/14/06, Luciano Resende <lu...@gmail.com> wrote:
>>
>> Hi All
>>
>> I have updated (Tuscany-904) with a new version of the DAS
>> container.
>> This is based on the initial contribution that Amita did, with some
>> clean-up, refactoring and additions to try to fix a possible
>> problem with
>> mutable properties that are shared among instance (pointed by Jim
>> Marino)...
>> Currently, this is just the initial drop that I want to make
>> available in
>> the trunk so other can start to take a look and Amita and I could
>> collaborate easier... unit testings, sample, etc are coming... I'd
>> appreciate if anyone could help get this to the trunk if there is
>> nothing
>> wrong with this...
>>
>> Couple Questions:
>>
>> Could someone take a quick look at ComponentTypeLoader and see if
>> it's
>> looking Ok ? I was not sure about what this loadFromSideFile
>> means ? what
>> is
>> the "side file"? Is this something particular to Script container ?
>
>
> A sidefile is one way of exposing the configurable aspects of an
> implementation. The other way is thro annotations. Yet another is to
> follow some coding conventions so that this information is
> introspectable.
> The sidefile way of doing things is, to the best of what I
> understand, a
> common means across containers. i.e. you can have javascript, java,
> ruby,
> das (if you will) components all using the sidefile in a similar
> manner as
> this is prescribed by the specs.
Yes component type is a common means but allows an implementation
type (e.g. implementation.java, implementation.ruby) to extend the
component type schema with specific metadata. Also, there is a 1:1
relationship between a component type and an component implementation.
> For the introspectable way you will see
> Java and JavaScript vary in how they achieve this. The same goes for
> annotations - right now the java container alone can leverage this
> (as far
> as I know).
>
> Also, I wasn't sure what time is the appropriate time to load the
> das config
>> file when provided ? Right now is being loaded at
>> DataAccessImplementationLoader, if you guys think this should go in a
>> different place, please let me know... also would be good to know
>> why :)
>
>
I think this begs the question of what DAS "configuration" is. I'm
not sure all configuration is part of a component type since the
latter always has a 1:1 relationship with its implementation. For
example, I believe the DAS configuration specifies mappings to
database tables. Are these mappings potentially sharable across
different components? JPA has the "PersistenceUnit" concept to
express this. A PersistenceUnit defines the set of entities that can
be managed by a particular context but must always correspond to one
database. For example, an application may have one or more
PersistenceUnits (I would imagine in typical cases it is one but not
always). Related to this, configuration may define which DataSource
to use. In DAS, is it possible that multiple <implementation.das>
entries want to use the same mapping and DataSource configuration?
If that is the case, you can probably do something similar to what
Meeraj is doing with the JPA integration and have the configuration
information parsed and cached as a special system service in the
application composite. If so, we can drill down into more detail here.
> The config file could very well be read / parsed during 'load' time
> using
> the loader. The loading is just about picking up the component
> definition
> information from the scdl file and creating a java object model for
> them.
> The next phase is the 'build' phase where you must create the
> necessary
> runtime artifacts making use of the model you have defined in the
> loading
> phase. In your case I would imagine that you would inject the
> config values
> into the DAS Engine during the build time.
>
One minor thing here. Unless the configuration values are always
immutable, an ObjectFactory should be injected otherwise one
component could accidentally modify a configuration parameter of
another as instances will be shared. When the component
implementation instance is created, the AtomicComponent will need to
call all of the ObjectFactory.getInstance methods to retrieve
configuration values that are injected. If the values are mutable,
the ObjectFactory will need to instantiate, copy or clone a value. If
the value is immutable, it can always pass the same one. In part of
the refactors to container.script, I introduced some code that does
this which can be used as an example.
> Well, comments and feedback are welcome... Note that I'm still getting
>> familiar with the Container SPI, so, please let me know if I
>> misunderstood
>> something on the implementation.
>
>
> - Luciano Resende
>> Apache Tuscany
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS Container - First part ready for review....
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
I have tried my best to explain... just in case something is not right in
this could somebody pitch in please.
Thanks.
- Venkat
On 11/14/06, Luciano Resende <lu...@gmail.com> wrote:
>
> Hi All
>
> I have updated (Tuscany-904) with a new version of the DAS container.
> This is based on the initial contribution that Amita did, with some
> clean-up, refactoring and additions to try to fix a possible problem with
> mutable properties that are shared among instance (pointed by Jim
> Marino)...
> Currently, this is just the initial drop that I want to make available in
> the trunk so other can start to take a look and Amita and I could
> collaborate easier... unit testings, sample, etc are coming... I'd
> appreciate if anyone could help get this to the trunk if there is nothing
> wrong with this...
>
> Couple Questions:
>
> Could someone take a quick look at ComponentTypeLoader and see if it's
> looking Ok ? I was not sure about what this loadFromSideFile means ? what
> is
> the "side file"? Is this something particular to Script container ?
A sidefile is one way of exposing the configurable aspects of an
implementation. The other way is thro annotations. Yet another is to
follow some coding conventions so that this information is introspectable.
The sidefile way of doing things is, to the best of what I understand, a
common means across containers. i.e. you can have javascript, java, ruby,
das (if you will) components all using the sidefile in a similar manner as
this is prescribed by the specs. For the introspectable way you will see
Java and JavaScript vary in how they achieve this. The same goes for
annotations - right now the java container alone can leverage this (as far
as I know).
Also, I wasn't sure what time is the appropriate time to load the das config
> file when provided ? Right now is being loaded at
> DataAccessImplementationLoader, if you guys think this should go in a
> different place, please let me know... also would be good to know why :)
The config file could very well be read / parsed during 'load' time using
the loader. The loading is just about picking up the component definition
information from the scdl file and creating a java object model for them.
The next phase is the 'build' phase where you must create the necessary
runtime artifacts making use of the model you have defined in the loading
phase. In your case I would imagine that you would inject the config values
into the DAS Engine during the build time.
Well, comments and feedback are welcome... Note that I'm still getting
> familiar with the Container SPI, so, please let me know if I misunderstood
> something on the implementation.
- Luciano Resende
> Apache Tuscany
>
>
Re: DAS Container - First part ready for review....
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi Luciano,
I am working on the changes of removing the database connection code by
making a web test client. Will get back to you with the completed code changes.
Regards,
Amita
On 11/16/06, Luciano Resende <lu...@gmail.com> wrote:
> Hi Amita
>
> Sorry for taking little longer, but here are some comments on your
> updates:
>
> I have incorporated your changes to DataAccessComponentTypeLoader
>
> Changes to DataAccessEngine.java are assuming that the container should
> be responsible to setup database, and I don't believe that is the right
> place to do that, the application should be responsible for creating the
> database, and either dasConfig.xml or SCDL should only have necessary
> information to connect to the database. Maybe this is being done trying to
> overcome the current DAS config.xml limitation when running in a J2SE
> environment, but then we should find the proper way to solve that.
>
> As for a drive program, I think we should make this as an unit testing,
> or a sample app... I'll try refactor the driver program you were using.
>
> I've posted my patch with some of your changes at my sandbox, we can
> start collaborating with patches from there :
> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
>
> On 11/15/06, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Thank you, I'll take a look at your changes when it's available...
> > For the J2SE code, it should be ok for now... I just don't want to have a
> > copy of the canned db bundled together...
> >
> > - Luciano
> >
> > On 11/15/06, Amita Vadhavkar <am...@gmail.com> wrote:
> > >
> > > Hi Luciano,
> > > I had done a few changes and will be attaching the working code to
> > > JIRA in next couple of hours. Just wanted to update you for same and
> > > will start looking at the
> > > test case development after that.
> > >
> > > (Please note, for the basic testing to check that the code is working,
> > > I have still
> > > kept the old J2SE code for data connection etc. After the J2EE setup
> > > can clean that part too.)
> > >
> > > Regards,
> > > Amita
> > >
> > > On 11/14/06, Luciano Resende <lu...@gmail.com> wrote:
> > > > Hi All
> > > >
> > > > I have updated (Tuscany-904) with a new version of the DAS
> > > container.
> > > > This is based on the initial contribution that Amita did, with some
> > > > clean-up, refactoring and additions to try to fix a possible problem
> > > with
> > > > mutable properties that are shared among instance (pointed by Jim
> > > Marino)...
> > > > Currently, this is just the initial drop that I want to make available
> > > in
> > > > the trunk so other can start to take a look and Amita and I could
> > > > collaborate easier... unit testings, sample, etc are coming... I'd
> > > > appreciate if anyone could help get this to the trunk if there is
> > > nothing
> > > > wrong with this...
> > > >
> > > > Couple Questions:
> > > >
> > > > Could someone take a quick look at ComponentTypeLoader and see if it's
> > > > looking Ok ? I was not sure about what this loadFromSideFile means ?
> > > what is
> > > > the "side file"? Is this something particular to Script container ?
> > > >
> > > > Also, I wasn't sure what time is the appropriate time to load the das
> > > config
> > > > file when provided ? Right now is being loaded at
> > > > DataAccessImplementationLoader, if you guys think this should go in a
> > > > different place, please let me know... also would be good to know why
> > > :)
> > > >
> > > > Well, comments and feedback are welcome... Note that I'm still getting
> > >
> > > > familiar with the Container SPI, so, please let me know if I
> > > misunderstood
> > > > something on the implementation.
> > > >
> > > > - Luciano Resende
> > > > Apache Tuscany
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
Hi Amita
Sorry for taking little longer, but here are some comments on your
updates:
I have incorporated your changes to DataAccessComponentTypeLoader
Changes to DataAccessEngine.java are assuming that the container should
be responsible to setup database, and I don't believe that is the right
place to do that, the application should be responsible for creating the
database, and either dasConfig.xml or SCDL should only have necessary
information to connect to the database. Maybe this is being done trying to
overcome the current DAS config.xml limitation when running in a J2SE
environment, but then we should find the proper way to solve that.
As for a drive program, I think we should make this as an unit testing,
or a sample app... I'll try refactor the driver program you were using.
I've posted my patch with some of your changes at my sandbox, we can
start collaborating with patches from there :
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
--
Luciano Resende
http://people.apache.org/~lresende
On 11/15/06, Luciano Resende <lu...@gmail.com> wrote:
>
> Thank you, I'll take a look at your changes when it's available...
> For the J2SE code, it should be ok for now... I just don't want to have a
> copy of the canned db bundled together...
>
> - Luciano
>
> On 11/15/06, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > Hi Luciano,
> > I had done a few changes and will be attaching the working code to
> > JIRA in next couple of hours. Just wanted to update you for same and
> > will start looking at the
> > test case development after that.
> >
> > (Please note, for the basic testing to check that the code is working,
> > I have still
> > kept the old J2SE code for data connection etc. After the J2EE setup
> > can clean that part too.)
> >
> > Regards,
> > Amita
> >
> > On 11/14/06, Luciano Resende <lu...@gmail.com> wrote:
> > > Hi All
> > >
> > > I have updated (Tuscany-904) with a new version of the DAS
> > container.
> > > This is based on the initial contribution that Amita did, with some
> > > clean-up, refactoring and additions to try to fix a possible problem
> > with
> > > mutable properties that are shared among instance (pointed by Jim
> > Marino)...
> > > Currently, this is just the initial drop that I want to make available
> > in
> > > the trunk so other can start to take a look and Amita and I could
> > > collaborate easier... unit testings, sample, etc are coming... I'd
> > > appreciate if anyone could help get this to the trunk if there is
> > nothing
> > > wrong with this...
> > >
> > > Couple Questions:
> > >
> > > Could someone take a quick look at ComponentTypeLoader and see if it's
> > > looking Ok ? I was not sure about what this loadFromSideFile means ?
> > what is
> > > the "side file"? Is this something particular to Script container ?
> > >
> > > Also, I wasn't sure what time is the appropriate time to load the das
> > config
> > > file when provided ? Right now is being loaded at
> > > DataAccessImplementationLoader, if you guys think this should go in a
> > > different place, please let me know... also would be good to know why
> > :)
> > >
> > > Well, comments and feedback are welcome... Note that I'm still getting
> >
> > > familiar with the Container SPI, so, please let me know if I
> > misunderstood
> > > something on the implementation.
> > >
> > > - Luciano Resende
> > > Apache Tuscany
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: DAS Container - First part ready for review....
Posted by Luciano Resende <lu...@gmail.com>.
Thank you, I'll take a look at your changes when it's available...
For the J2SE code, it should be ok for now... I just don't want to have a
copy of the canned db bundled together...
- Luciano
On 11/15/06, Amita Vadhavkar <am...@gmail.com> wrote:
>
> Hi Luciano,
> I had done a few changes and will be attaching the working code to
> JIRA in next couple of hours. Just wanted to update you for same and
> will start looking at the
> test case development after that.
>
> (Please note, for the basic testing to check that the code is working,
> I have still
> kept the old J2SE code for data connection etc. After the J2EE setup
> can clean that part too.)
>
> Regards,
> Amita
>
> On 11/14/06, Luciano Resende <lu...@gmail.com> wrote:
> > Hi All
> >
> > I have updated (Tuscany-904) with a new version of the DAS container.
> > This is based on the initial contribution that Amita did, with some
> > clean-up, refactoring and additions to try to fix a possible problem
> with
> > mutable properties that are shared among instance (pointed by Jim
> Marino)...
> > Currently, this is just the initial drop that I want to make available
> in
> > the trunk so other can start to take a look and Amita and I could
> > collaborate easier... unit testings, sample, etc are coming... I'd
> > appreciate if anyone could help get this to the trunk if there is
> nothing
> > wrong with this...
> >
> > Couple Questions:
> >
> > Could someone take a quick look at ComponentTypeLoader and see if it's
> > looking Ok ? I was not sure about what this loadFromSideFile means ?
> what is
> > the "side file"? Is this something particular to Script container ?
> >
> > Also, I wasn't sure what time is the appropriate time to load the das
> config
> > file when provided ? Right now is being loaded at
> > DataAccessImplementationLoader, if you guys think this should go in a
> > different place, please let me know... also would be good to know why :)
> >
> > Well, comments and feedback are welcome... Note that I'm still getting
> > familiar with the Container SPI, so, please let me know if I
> misunderstood
> > something on the implementation.
> >
> > - Luciano Resende
> > Apache Tuscany
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: DAS Container - First part ready for review....
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi Luciano,
I had done a few changes and will be attaching the working code to
JIRA in next couple of hours. Just wanted to update you for same and
will start looking at the
test case development after that.
(Please note, for the basic testing to check that the code is working,
I have still
kept the old J2SE code for data connection etc. After the J2EE setup
can clean that part too.)
Regards,
Amita
On 11/14/06, Luciano Resende <lu...@gmail.com> wrote:
> Hi All
>
> I have updated (Tuscany-904) with a new version of the DAS container.
> This is based on the initial contribution that Amita did, with some
> clean-up, refactoring and additions to try to fix a possible problem with
> mutable properties that are shared among instance (pointed by Jim Marino)...
> Currently, this is just the initial drop that I want to make available in
> the trunk so other can start to take a look and Amita and I could
> collaborate easier... unit testings, sample, etc are coming... I'd
> appreciate if anyone could help get this to the trunk if there is nothing
> wrong with this...
>
> Couple Questions:
>
> Could someone take a quick look at ComponentTypeLoader and see if it's
> looking Ok ? I was not sure about what this loadFromSideFile means ? what is
> the "side file"? Is this something particular to Script container ?
>
> Also, I wasn't sure what time is the appropriate time to load the das config
> file when provided ? Right now is being loaded at
> DataAccessImplementationLoader, if you guys think this should go in a
> different place, please let me know... also would be good to know why :)
>
> Well, comments and feedback are welcome... Note that I'm still getting
> familiar with the Container SPI, so, please let me know if I misunderstood
> something on the implementation.
>
> - Luciano Resende
> Apache Tuscany
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org