On Aug 8, 2007, at 10:37 AM, glassfish_at_javadesktop.org wrote:
>>
>> 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?
>
ok but this is not what Kedar understood and suggested we should
implement.
> 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?
>
I cannot agree more, hence this little email thread...
so I think if you just want to have the original war file back, is it
too complicated to make it available on the http-listener's docroot ?
I know this is a manual step but it works today.
For the future, I would be fine with such an RFE as long as we
clearly state that we return the original bits, not an exported
deployed version.
>>>
>>>>> 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?
no I did not miss that. but any administrative feature is usually
provided through the console, the CLI and as an API (AMX) so this
needs to be taken into account.
>
>>
>>>
>>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>