You can pass the user name and password through the deploy command. Or
you can do "asadmin login" to log in and saved the password in the
preference so you don't need to provide this for each command. The
default user name is "adminadmin" and the default password is "".
On 8/10/2010 9:54 AM, Martin, Ray wrote:
>
> I went to the command line and did as you suggested.
>
>
>
> I got an "Authorization has been refused..."
>
>
>
> I am embarrassed to admit that I do not know how to overcome this
> obstacle. I am reading to find the answer. I also did ./bin/asadmin
> deploy - to see the options -- didn't yet see the credentials option.
>
>
>
> Currently, I deploy from the admin console or netbeans -- so, I am a
> bit behind the curve here. And, yes, I must login to the console -- I
> am required to have this set.
>
>
>
> *From:* Hong Zhang [mailto:hong.hz.zhang_at_oracle.com]
> *Sent:* Tuesday, August 10, 2010 9:27 AM
> *To:* users_at_glassfish.dev.java.net
> *Subject:* Re: third party jars
>
>
>
> Hi,
> In v3, we have enforced the jar visibility more strictly based on
> the EE spec to encourage portable packaging. It's not a portable way
> to package the library jars at the root level of the ejb module (I
> assume your library jar is packaged at the ejb jar root level). The
> portable packaging way is to put the libraries that the ejb module
> needs in the ear lib directory. Ideally, the ejb module should have an
> equivalent of WEB-INF/lib directory like war file to put all the
> library jars. I have talked with Ken Saks (spec lead of EJB3.1) in the
> past about this and this is one of the areas that need to be addressed
> in the future EJB spec.
> Other than packaging the libraries inside the application, you can
> also reference any application specific libraries through the
> --libraries option during deployment. See the libraries option here
> for more details:
> http://docs.sun.com/app/docs/doc/820-7701/deploy-1?l=en&a=view
> <http://docs.sun.com/app/docs/doc/820-7701/deploy-1?l=en&a=view>.
> Above being said, we did introduce a flag called "compatibility"
> to preserve v2 compatibility for jar visibility. So try this with your
> application to see if it makes a difference:
> asadmin deploy --property compatibility=v2 <your archive file>
>
> Thanks,
>
> - Hong
>
> On 8/10/2010 7:33 AM, Martin, Ray wrote:
>
> Using netbeans 6.8
>
>
>
> Have been working in glassfish v2 -- yesterday switched to v3 -- wow.
> (big changes in the JPA.)
>
>
>
> After many hours of work, got all the errors out of the EJBModule
> project.
>
> It deploys.
>
> It starts when commanded from the SOAP interface.
>
> It crashes as soon as a third party library is called -- JSON in this
> case. Though the oracle library must have been seen because database
> connections are working. The JSON jar has other dependencies like
> commons-*.
>
>
>
> All third party jars have been packaged into the EJBModule jar.
>
>
>
> I built the project in SE using JPA and the third party jars -- runs
> great.
>
> I built a similar project as a web app where the EJBs, JPA, and third
> party jars are used -- runs great.
>
>
>
> Wow -- am I sorry that I changed to v3.
>
>
>
> I have searched and searched -- I cannot be the only guy who has this
> problem -- but, I can find no solution.
>
>
>
> Thought maybe it was netbeans' fault -- so, deployed using admin
> console -- same problem. So, I guess it is a packaging problem??? A
> manifest problem??? wow
>
>
>