[DISCUSSION] DEPLOYMENT (Was: Re: something has gone wrong with deployment)

[Karan Malhi <ka...@gmail.com>]

Changing the thread

On 9/8/07, Karan Malhi <ka...@gmail.com> wrote:
> So, the undeploy command runs successfully without any errors given
> the moduleId. However, there are some issues:
>
> The jar file is stil in the apps directory, so if i run the deploy
> command again, it complains that the file already exists.
>
> The fix would be that either the checkDest() method of Deploy needs to
> be commented out (crashes my jvm if we do that) -- then we do not
> require undeploy to remove the jar from the apps. But in this case on
> server restart, the app will be deployed automatically.
> OR
> The undeploy command should remove the jar also from the apps directory
>
> On 9/8/07, Karan Malhi <ka...@gmail.com> wrote:
> > Also if there is a conflict, then a full path should be given. For example
> >
> > ~/a/b/xyz.jar
> > ~/c/d/xyz.jar
> >
> > from any directory other than ~/a/b or ~/c/d if I run
> > openejb undeploy xyz.jar
> >
> > then it should give a message to the user saying that "xyz.jar has a
> > conflict with another jar with the same name, please specify the full
> > path or run the undeploy command from the same directory where the jar
> > is located"
> >
> > On 9/8/07, Karan Malhi <ka...@gmail.com> wrote:
> > > Okay,
> > >
> > > I checkedin UnDeploy.java, made a minor change in documentation. Had
> > > to actually svn switch --relocate to https:// .... as I had checked
> > > out the code using http
> > >
> > > > That's we're we probably need some effort.  We spit it out when the
> > > > app is deployed:
> > > In my case, I had already put the jar in the apps and then started the
> > > server. So, I agree, we need to be more explicit about it in the logs
> > > as well. The more I am facing issues here, the more attactive  the
> > > .info directory idea is becoming.
> > > >Maybe a short one like
> > > > "hello-addservice.jar" or "hello-addservice"???
> > > I like hello-addservice.jar . This is because there could also be a
> > > hello-addservice.ear and an explicit extension would not lead to any
> > > conflicts . We can also deploy an ear , right? (my understanding is
> > > that the web module would be ignored from it)
> > > >
> > > > Of course we could support both the file path and a shorter
> > > > moduleId.  The file path thing is kind of nice as you can then:
> > > >
> > > >   ./openejb undeploy *.jar
> > > I like this idea too, but my feeling is that it will become cumbersome
> > > for longer paths. Here is what I am thinking:
> > >
> > > ~/a/b/ab.jar
> > > ~/c/d/cd.jar
> > >
> > > ~/a/b/openejb undeploy *.jar
> > > This will undeploy all jars from ~/a/b
> > >
> > > ~/c/d/openejb undeploy *.jar
> > > This will undeploy all jars from ~/c/d
> > >
> > > However if i just do
> > > openejb undeploy *.jar
> > > from anywhere else, that should undeploy all jars , regardless of where they are
> > >
> > > How does this sound?
> > >
> > > --
> > > Karan Singh Malhi
> > >
> >
> >
> > --
> > Karan Singh Malhi
> >
>
>
> --
> Karan Singh Malhi
>


-- 
Karan Singh Malhi

Re: [DISCUSSION] DEPLOYMENT (Was: Re: something has gone wrong with deployment)

[David Blevins <da...@visi.com>]

Already sent off a bunch of responses, but feel free to rechange the  
subject on any replies.

-David

On Sep 8, 2007, at 12:15 PM, Karan Malhi wrote:

> Changing the thread
>
> On 9/8/07, Karan Malhi <ka...@gmail.com> wrote:
>> So, the undeploy command runs successfully without any errors given
>> the moduleId. However, there are some issues:
>>
>> The jar file is stil in the apps directory, so if i run the deploy
>> command again, it complains that the file already exists.
>>
>> The fix would be that either the checkDest() method of Deploy  
>> needs to
>> be commented out (crashes my jvm if we do that) -- then we do not
>> require undeploy to remove the jar from the apps. But in this case on
>> server restart, the app will be deployed automatically.
>> OR
>> The undeploy command should remove the jar also from the apps  
>> directory
>>
>> On 9/8/07, Karan Malhi <ka...@gmail.com> wrote:
>>> Also if there is a conflict, then a full path should be given.  
>>> For example
>>>
>>> ~/a/b/xyz.jar
>>> ~/c/d/xyz.jar
>>>
>>> from any directory other than ~/a/b or ~/c/d if I run
>>> openejb undeploy xyz.jar
>>>
>>> then it should give a message to the user saying that "xyz.jar has a
>>> conflict with another jar with the same name, please specify the  
>>> full
>>> path or run the undeploy command from the same directory where  
>>> the jar
>>> is located"
>>>
>>> On 9/8/07, Karan Malhi <ka...@gmail.com> wrote:
>>>> Okay,
>>>>
>>>> I checkedin UnDeploy.java, made a minor change in documentation.  
>>>> Had
>>>> to actually svn switch --relocate to https:// .... as I had checked
>>>> out the code using http
>>>>
>>>>> That's we're we probably need some effort.  We spit it out when  
>>>>> the
>>>>> app is deployed:
>>>> In my case, I had already put the jar in the apps and then  
>>>> started the
>>>> server. So, I agree, we need to be more explicit about it in the  
>>>> logs
>>>> as well. The more I am facing issues here, the more attactive  the
>>>> .info directory idea is becoming.
>>>>> Maybe a short one like
>>>>> "hello-addservice.jar" or "hello-addservice"???
>>>> I like hello-addservice.jar . This is because there could also be a
>>>> hello-addservice.ear and an explicit extension would not lead to  
>>>> any
>>>> conflicts . We can also deploy an ear , right? (my understanding is
>>>> that the web module would be ignored from it)
>>>>>
>>>>> Of course we could support both the file path and a shorter
>>>>> moduleId.  The file path thing is kind of nice as you can then:
>>>>>
>>>>>   ./openejb undeploy *.jar
>>>> I like this idea too, but my feeling is that it will become  
>>>> cumbersome
>>>> for longer paths. Here is what I am thinking:
>>>>
>>>> ~/a/b/ab.jar
>>>> ~/c/d/cd.jar
>>>>
>>>> ~/a/b/openejb undeploy *.jar
>>>> This will undeploy all jars from ~/a/b
>>>>
>>>> ~/c/d/openejb undeploy *.jar
>>>> This will undeploy all jars from ~/c/d
>>>>
>>>> However if i just do
>>>> openejb undeploy *.jar
>>>> from anywhere else, that should undeploy all jars , regardless  
>>>> of where they are
>>>>
>>>> How does this sound?
>>>>
>>>> --
>>>> Karan Singh Malhi
>>>>
>>>
>>>
>>> --
>>> Karan Singh Malhi
>>>
>>
>>
>> --
>> Karan Singh Malhi
>>
>
>
> -- 
> Karan Singh Malhi
>