Maybe what is going on here has something to to with the interaction
between Netbeans_8.0.1/Maven_3.2.3/GlassFish_4.1
I had a little bit of time yesterday so I tried to revisit the remote
deploy issue.
I pointed my project via NetBeans at my remote Glassfish and again got the
java.io.IOException: java.util.concurrent.TimeoutException -- OK no change
there.
However, I went to the Admin console and deployed -- no errors where thrown
but after clicking on my application none of the modules were visible. I
tired deploying several times this same way and got the same results. EAR
deployed but with not modules (as if the WAR and EJB/JAR were not present)
Just for the heck of it I dropped by EAR in the autodeploy directory and
the application deployed completely correct. All modules were found and the
context root was correct.
So, I took a step back and created a new/empty maven EAR project. Tried a
remote deploy via Netbeans and threw no errors. However, in the address bar
of the browser rather than the root context it displayed the full name of
the WAR file "MyProject-web-1.0-SNAPSHOT" Going into the admin console and
clicking on the application to launch that way the options did show the
correct context root.
I tried to remote deploy the empty EAR a couple more times via Netbeans.
Sometimes it was successsful. Sometimes it failed with
"java.io.IOException: java.util.concurrent.TimeoutException" and sometimes
it failed with "java.io.EOFException"
I tired adding the following to the "maven-ear-plugin" section of my
pom.xml of my EAR:
<modules>
<webModule>
<groupId>com.mycompany</groupId>
<artifactId>MyProject-web</artifactId>
<contextRoot>/MyProject-web</contextRoot>
</webModule>
<ejbModule>
<groupId>com.mycompany</groupId>
<artifactId>MyProject-ejb</artifactId>
</ejbModule>
</modules>
But the behavior remained the same. I'm new to Maven. So, the above is just
my poking about but maybe it will give someone with a better understanding
of the interrelationship of these three tools a hint that is useful.
I really would like to stick with maven as I like how it handles
dependencies and keeps my repository clean but if it just gets in the way
of seamless remote deploys I can drop back to standard project templates,
too.
Any advice or more information I can collect?
-drg
On Mon, Sep 29, 2014 at 9:02 AM, Dennis Gesker <dennis_at_gesker.com> wrote:
> Good Morning:
>
> Just thought I'd ping/bump on this one to see if anyone is having any
> luck.
>
> Or, if there is anything you would recommend I try so that I might add
> something useful to
> https://java.net/jira/browse/GLASSFISH-21196 or
> https://java.net/jira/browse/GLASSFISH-21180
>
> Dennis
>
> On Tue, Sep 23, 2014 at 8:20 AM, Dennis Gesker <dennis_at_gesker.com> wrote:
>
>> I just pulled down a copy of glassfish-4.0 and tried to deploy to my
>> remote glassfish-4.1 via the command line and got the same java.util
>> .concurrent.TimeoutException
>> so I guess I'm a little bit off from what Phillip is experiencing.
>>
>> Any other ideas or other things that would be useful to try?
>>
>> Dennis
>>
>>
>> On Sun, Sep 21, 2014 at 8:32 AM, Reza Rahman <Reza.Rahman_at_oracle.com>
>> wrote:
>>
>>> Great - I appreciate your sticking with it and not giving up.
>>>
>>>
>>> On 9/21/2014 1:01 AM, Phillip Ross wrote:
>>>
>>>> Well, interestingly, in IDEA, there is a checkbox in the deployment
>>>> configuration labeled "Upload with GlassFish" which may be intended to
>>>> toggle the --upload option on and off when deploying. Whether the
>>>> checkbox is selected or not, the same problem occurs for me. The lack
>>>> of visibility into exactly what IDEA is doing is a little
>>>> frustrating... the JEE bits of IDEA are not opensource. I have my
>>>> workaround for now, and was planning to contact Jetbrains and
>>>> officially document the problem I'm having. I was assuming that they
>>>> would simply say that 4.1 is not officially supported yet. It's quite
>>>> possible that the deployment from IDEA problem is not the same problem
>>>> as the deployment with --upload problem... but the similarity in the
>>>> error messages makes me think that they might be related.
>>>>
>>>> Maybe I should file a bug in Jira against glassfish 4.1 release with
>>>> explicit instructions and a deployable file to show that --upload does
>>>> not work?
>>>>
>>>> Then file a separate issue with Jetbrains for the deployment problem
>>>> from within the IDE?
>>>>
>>>> Thanks for all the help!
>>>> - Phillip
>>>>
>>>> On Sat, Sep 20, 2014 at 10:46 PM, Reza Rahman <Reza.Rahman_at_oracle.com>
>>>> wrote:
>>>>
>>>>> OK. No promises, but let me see if one of our engineers can take a
>>>>> look at
>>>>> this. In the meanwhile, does it make sense to get the intellij guys to
>>>>> change their plugin as well? Is --upload really necessary in this case
>>>>> (noting that most of the time you can safely omit it)?
>>>>>
>>>>> On 9/20/2014 10:35 PM, Phillip Ross wrote:
>>>>>
>>>>>> Sorry, I might have confused things as I was in a hurry when I wrote
>>>>>> the previous response.
>>>>>>
>>>>>> My installion of 4.0 works fine... I can do remote deployed to the 4.0
>>>>>> server with the asadmin included in the 4.0 installation. Intellij is
>>>>>> configured to use this 4.0 installation and is able to deploy to the
>>>>>> 4.0 server perfectly. It works very well.
>>>>>>
>>>>>> I tested 4.0.1 promoted builds, and 4.1 promoted builds, and now the
>>>>>> 4.1 final release... and these have the same problem that was reported
>>>>>> in the two issues. I was not able to deploy to a 4.1 server with the
>>>>>> asadmin included in the 4.1 installation. It exhibited the same
>>>>>> behaviors as are documented in the jira issues. I was able to find
>>>>>> some "workarounds" though. I found that I was able to do a deployment
>>>>>> with the asadmin in the 4.1 installation to the 4.1 server by NOT
>>>>>> using the --upload param w/ asadmin which I've been using for a long
>>>>>> time with prior versions of glassfish. Unfortunately, intellij IDEA
>>>>>> is still not able to do this. What I am able to do in IDEA, however,
>>>>>> is to point IDEA at a 4.0 installation and then point it at a 4.1
>>>>>> server. Doing this allows me to deploy the application in IDEA to a
>>>>>> 4.1 server... but I believe that it's using the 4.0 installation to
>>>>>> accomplish this. And when I say 4.0 installation... I don't mean a
>>>>>> 4.0 server is running... just that the software is installed and IDEA
>>>>>> is configured to use it as it's configured glassfish installation.
>>>>>>
>>>>>> Hopefully this makes things a little more clear. (hopefully) ;)
>>>>>>
>>>>>> Thanks!
>>>>>> - Phillip
>>>>>>
>>>>>> On Sat, Sep 20, 2014 at 8:50 PM, Reza Rahman <Reza.Rahman_at_oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Not sure I entirely follow but I mean when the deployment target is
>>>>>>> the
>>>>>>> GlassFish 4.0 release version.
>>>>>>>
>>>>>>> On 9/20/2014 8:14 PM, Martin Gainty wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>> Date: Sat, 20 Sep 2014 19:31:40 -0400
>>>>>>> From: Reza.Rahman_at_oracle.com
>>>>>>> To: users_at_glassfish.java.net
>>>>>>> Subject: [gf-users] Re: Remote Deploy Problems
>>>>>>>
>>>>>>> Sorry if this is a dumb question - does this occur with the 4.0
>>>>>>> release?
>>>>>>> I
>>>>>>> makes a difference in terms of tracing this down to root cause and
>>>>>>> prioritizing properly.
>>>>>>> MG>you mean use the 4.0 installation to upload to a 4.0 server?
>>>>>>>
>>>>>>> On 9/18/2014 4:06 PM, Dennis Gesker wrote:
>>>>>>>
>>>>>>> Reza, Phillip:
>>>>>>>
>>>>>>> I am having the same failure to deploy using the command line.
>>>>>>> Identical error messages as I described when trying to remote deploy
>>>>>>> from
>>>>>>> within NetBeans.
>>>>>>>
>>>>>>> Dennis
>>>>>>>
>>>>>>> On Wed, Sep 17, 2014 at 7:22 PM, Phillip Ross
>>>>>>> <phillip.w.g.ross_at_gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I was having the same issue as well with promoted builds of 4.0.1
>>>>>>> that
>>>>>>> i was testing... and was disappointed to see that the issue remained
>>>>>>> in 4.1 clear up to final release.
>>>>>>>
>>>>>>> For me, the asadmin utility fails if the --upload param is used, but
>>>>>>> if --upload is not used, then the deployment works. Also... Intellij
>>>>>>> IDEA has the same problem. My workaround is to use a 4.0
>>>>>>> installation
>>>>>>> to upload to a 4.1 server It's not optimal but it appears to work
>>>>>>> for
>>>>>>> the time being.
>>>>>>>
>>>>>>> On Wed, Sep 17, 2014 at 4:57 PM, Reza Rahman <Reza.Rahman_at_oracle.com
>>>>>>> >
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Have you tried a remote deploy via asadmin (I know the other person
>>>>>>>> tried
>>>>>>>> this)? If that works this might be a NetBeans issue. Also, is this a
>>>>>>>> fresh
>>>>>>>> deploy or a redeploy? If it's a redeploy, it might be worthwhile to
>>>>>>>> try
>>>>>>>> to
>>>>>>>> do an undeploy first?
>>>>>>>>
>>>>>>>> On 9/17/2014 4:50 PM, Dennis Gesker wrote:
>>>>>>>>
>>>>>>>>> Remote deploy seems to be an issue. I got a "me too" on the nbusers
>>>>>>>>> list
>>>>>>>>> but no suggestions on a work around.
>>>>>>>>>
>>>>>>>>> My Entry is:
>>>>>>>>> https://java.net/jira/browse/GLASSFISH-21196
>>>>>>>>>
>>>>>>>>> bhicks01 pointed out it seems similar to:
>>>>>>>>> https://java.net/jira/browse/GLASSFISH-21180
>>>>>>>>>
>>>>>>>>> Could anyone offer a suggestion or perhaps a work around? I would
>>>>>>>>> be
>>>>>>>>> truly
>>>>>>>>> grateful.
>>>>>>>>>
>>>>>>>>> --drg
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>