On Aug 8, 2007, at 8:51 AM, Kedar Mhaswade wrote:
>
>
> Jerome Dochez wrote:
>> On Aug 8, 2007, at 7:08 AM, glassfish_at_javadesktop.org wrote:
>>> Hmm. Not sure about the intent. Downloading client-stubs, needed
>>> to invoke the EJB's is different
>>> from the web-application itself. The former is *required* to
>>> invoke your EJB's from a standalone client.
>>>
>>> But it might be a good RFE to fix. An example would be to
>>> distribute the web-applications that are
>>> deployed to an instance of GlassFish. Generally, this is handled
>>> by your development processes.
>> and this is why there is a deployment process. downloading the
>> deployed bits with the non portable artifacts that may be unique
>> to the original deployment environment and reuse those bits
>> somewhere else is *not* a good idea.
>
> If a deployer is aware of non-portable extensions, then it's best not
> to "export" such an application. You can always misuse a facility
> offered
> by a server.
you don't understand me. the non portable extensions is not something
in control of the user. These are artifacts that GlassFish deployment
can generate during the deployment phase, therefore the user
obviously does not know if such non portable artifact was generated
or not and therefore has no clue if he is misusing the feature. As
far as users are concerned, they are often always deploying a 100%
portable war file, after deployment, that percentage is blurry,
that's why there is a deployment phase.
>
>>> But if you want an *exact* replica of the application (web-app,
>>> or any other app for that matter),
>>> GlassFish V2 does not have a way to do it today.
>>>
>> if the user's just want to have access to the original untouched
>> war file, he can push it to the http-listener docroot and make it
>> available through http download.
>
> Sure. Or put it in a maven-repository somewhere.
>
>>> Can you file an RFE at: http://glassfish.dev.java.net/servlets/
>>> ProjectIssues?
>>>
>> considering the security, portability considerations of such a
>> feature, I am not sure this would be a great feature addition.
> May I know the security consideration?
all web-app java code cannot be accessible publicly so there would
need to be enough barrier that such feature is not accessible without
an administrative password.
>
> Anyway, I took this as an administrative operation. E.g.:
> - user clicks on an application listed on admin console.
> - there is an option like: "Export".
> - the application is assembled on the server side and returned to
> the administrator as the archive.
>
and then what...
once you have the archive what do you do with it ? you certainly
don't want to deploy it somewhere else so what do you do ?
> In talking to few people, I realized that it is more often than not,
> it is a situation where administrators want to replicate an existing
> setup of application elsewhere. (Perhaps on another installation of
> GlassFish itself, where hopefully, the portability concerns are not
> worrisome). Maybe your experience suggests otherwise?
>
right, I agree but I think the right way of providing such a
desirable feature is to concentrate a the domain level where you can
have an export/import feature where you guarantee that the
configuration will remain the same, the applications will all be the
same and so on. Trying to do that at the application level is too
much difficult :
- non portable artifacts
- upgrade scenario (you exported in 9, import in 10, should it work ?)
- inter applications dependencies
- domain/lib libraries used by applications
For the application level, using portable archives and the deployment
is guaranteed (CTS) to work across application servers as well as
individual application server versions.
Jerome
> I still feel that this might be a useful feature.
>
> Kedar
>
>> Jerome
>>> Thanks,
>>> Kedar
>>> [Message sent by forum member 'km' (km)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=230023
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>