>
> 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.
Huh?
And why would this export procedure bundle the code generated by GlassFish?
That does not make sense. Think about it like this:
- I gave you a web-app. Can you get me that back?
The exported web-app is most likely going to be deployed elsewhere (again, on another
GlassFish installation/domain). That deployment procedure creates the deployment
artifacts again. So, why bundle them?
> >
> >>> 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.
Sure. I said "admin console". Did you miss that?
>
> >
> > 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.
I think all of these can be addressed if this is deemed a requirement.
Kedar
[Message sent by forum member 'km' (km)]
http://forums.java.net/jive/thread.jspa?messageID=230083