[Tim McConnell <ti...@gmail.com>]

Hi, does anyone happen to know any specifics about the 
<suppress-default-environment> XML element in the geronimo-module-1.2.xsd schema 
?? Or possibly have any examples where it is used ?? The schema documentation 
includes this comment below, which leads me to believe that it's only used by 
application clients, but I can't find any examples where it is ever used. Thanks

"If the "suppress-default-environment" element is specified then any default 
environment build by a builder when deploying the plan will be suppressed. An 
example of where this is useful is when deploying a connector on an app client 
in a separate (standalone) module (not as part of a client plan). The connector 
builder defaultEnvironment includes some server modules that won't work on an 
app client, so you need to suppress the default environment and supply a 
complete environment including all parents for a non-app-client module you want 
to run on an app client"

-- 
Thanks,
Tim McConnell

Re:

[Tim McConnell <ti...@gmail.com>]

Hi David, I'll check in the TCK for examples and will investigate the usage of 
artifact_aliases.properties. Thanks much for the information.....

David Jencks wrote:
> 
> On Jun 2, 2008, at 12:44 PM, Tim McConnell wrote:
> 
>> Hi, does anyone happen to know any specifics about the 
>> <suppress-default-environment> XML element in the 
>> geronimo-module-1.2.xsd schema ?? Or possibly have any examples where 
>> it is used ?? The schema documentation includes this comment below, 
>> which leads me to believe that it's only used by application clients, 
>> but I can't find any examples where it is ever used. Thanks
>>
>> "If the "suppress-default-environment" element is specified then any 
>> default environment build by a builder when deploying the plan will be 
>> suppressed. An example of where this is useful is when deploying a 
>> connector on an app client in a separate (standalone) module (not as 
>> part of a client plan). The connector builder defaultEnvironment 
>> includes some server modules that won't work on an app client, so you 
>> need to suppress the default environment and supply a complete 
>> environment including all parents for a non-app-client module you want 
>> to run on an app client"
> 
> That looks to me like a good description of it.  I think there are some 
> uses in the tck tests.  Originally this was used for deploying a 
> datasource or jms connection factory for use on the app client: you 
> don't want to run the transaction plugin in the client, you need the 
> client-transaction plugin.  It might be that we aren't using this 
> element any more since you can do something more useful with the 
> artifact_aliases.properties for the container you are running: you can 
> use this to map uses of transaction to client-transaction directly.
> 
> thanks
> david jencks
> 
>>
>>
>> -- 
>> Thanks,
>> Tim McConnell
> 
> 

-- 
Thanks,
Tim McConnell

Re:

[David Jencks <da...@yahoo.com>]

On Jun 2, 2008, at 12:44 PM, Tim McConnell wrote:

> Hi, does anyone happen to know any specifics about the <suppress- 
> default-environment> XML element in the geronimo-module-1.2.xsd  
> schema ?? Or possibly have any examples where it is used ?? The  
> schema documentation includes this comment below, which leads me to  
> believe that it's only used by application clients, but I can't find  
> any examples where it is ever used. Thanks
>
> "If the "suppress-default-environment" element is specified then any  
> default environment build by a builder when deploying the plan will  
> be suppressed. An example of where this is useful is when deploying  
> a connector on an app client in a separate (standalone) module (not  
> as part of a client plan). The connector builder defaultEnvironment  
> includes some server modules that won't work on an app client, so  
> you need to suppress the default environment and supply a complete  
> environment including all parents for a non-app-client module you  
> want to run on an app client"

That looks to me like a good description of it.  I think there are  
some uses in the tck tests.  Originally this was used for deploying a  
datasource or jms connection factory for use on the app client: you  
don't want to run the transaction plugin in the client, you need the  
client-transaction plugin.  It might be that we aren't using this  
element any more since you can do something more useful with the  
artifact_aliases.properties for the container you are running: you can  
use this to map uses of transaction to client-transaction directly.

thanks
david jencks

>
>
> -- 
> Thanks,
> Tim McConnell