SJSAS 8.2 or 9

I am a Solaris admin/Webadmin who is desparately trying to get the developers at my site organized with a single IDE, web server and application server. I have downloaded Java EE 5 SDK, as well as Netbeans. My plan is to deploy the application server to a Solaris server, and have the developers run the IDE on their local machines. My question is related to the version I should be using. I am aware that there is a SJSAS 8.2 Standard edition, as well as the SJSAS Platform edition that comes with the Java EE 5 SDK. From a production deployment perspective which one should we go with? Would it be better to deploy just NetBeans IDE or the entire Creator 2 instance with its built in SJSAS 9 application server?

Fuzz or static on iTunes-burned audio CDs can often be corrected by burning at a lower speed, such as 2x.

Similar Messages

SJSAS 9.1 does not expose EJB 3.0 remote Interface via JNDI

I have successfully deployed a simple Stateful EJB 3.0 bean (CartBean, like the one in the Java EE 5 tutorial remote interface Cart) on SJSAS 9.1, located on machine host1.
After I deployed the CartBean, I browsed the SJSAS and noticed the existence of the following JNDI entries:
ejb/Cart
ejb/Cart__3_x_Internal_RemoteBusinessHome__
ejb/Cart#main.Cart
ejb/mgmt
ejb/myOtherEJB_2_x_bean ( +myOtherEJB_2_x_bean+ is a different 2.x bean that I have deployed as well)So, I am trying to access the remote interface of the CartBean from a remote machine, host2. The client application is a Java-standalone client.
I am using the Interoperable Naming Service syntax: corbaname:iiop:host1:3700#<JNDI name>
The problem is that the remote interface of the bean does NOT seem to be available via JNDI. I get the javax.naming.NameNotFoundException when I try to do a lookup like:
corbaname:iiop:host1:3700#ejb/Cart
On the other hand, the following lookups succeed:
corbaname:iiop:host1:3700#ejb/mgmt
corbaname:iiop:host1:3700#myOtherEJB_2_x_bean
and also the following succeeds:
corbaname:iiop:host1:3700#ejb/Cart__3_x_Internal_RemoteBusinessHome__So it seems like the Remote interface is not available via JNDI, rather only some internal SJSAS implementation (the object returned from the ejb/Cart__3_x_Internal_RemoteBusinessHome__ lookup is of type: com.sun.corba.se.impl.corba.CORBAObjectImpl
Why is this happening? I know there used to be a bug in Glassfish, but I thought it had been fixed since 2006.
Many thanks in advance, any help would be greatly appreciated.

The EJB 3.0 Remote Business references are not directly stored in CosNaming. EJB 3.0 Remote references do not have the cross-vendor interoperability requirements that the EJB 2.x Remote view had.
You can still access Remote EJB references from a different JVM as long as the client has access to SJSAS naming provider. Please see our EJB FAQ for more details :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

A problem while getting a EJB remote interface from SJSAS 9.0

I hava deployed a session bean in SJSAS 9.0
I wrote some codes to get the remote interface as follow:
Context ctx = null;
Hashtable env = new Hashtable();
env.put ("java.naming.factory.initial","com.sun.jndi.cosnaming.CNCtxFactory");
env.put("java.naming.provider.url","iiop://127.0.0.1:3700");
try {
ctx = new InitialContext(env);
} catch (NamingException ex) {
ex.printStackTrace();
try {
Object cs =ctx.lookup(ejb.MySessionBean);
} catch (NamingException ex) {
ex.printStackTrace();
A exception occured during the lookup operation.
javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:44)
at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:453)
at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:492)
at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:470)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at demo.Main.run(Main.java:46)
at demo.Main.main(Main.java:62)
Caused by: org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0
at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:72)
at org.omg.CosNaming._NamingContextExtStub.resolve(_NamingContextExtStub.java:406)
at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:440)
... 5 more
Anyone can solve this problem for me???
Thanks a lot

We don't recommend explicitly instantiating the CosNaming provider within a stand-alone java client when accessing beans within the Java EE SDK. We have a simpler approach that involves just instantiating the no-arg InitialContext. Details are in our EJB FAQ :
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
--ken

SJSAS 9 fails to deploy application

Hi,
This forum isn't very relevant to my problem, but it's the most relevant one I could find. I'm trying to deploy an enterprise application packaged in an .ear file which contains an EJB jar and a web war file. It gives the error pasted below while deploying. The file I'm deploying is ZF.ear, which is the enterprise application project. I've exported it into .ear from Eclipse.
Deploying application in domain failed; Error expanding archive /home/sjsas/SUNWappserver/domains/domain1/applications/j2ee-apps/ZF/ZF-EJB.jar; please see the server log file for more information
Thanks!

Oh, and the log file contains this:
Timestamp:
Sep 26, 2006 18:38:13.857
Log Level:
SEVERE
Logger:
javax.enterprise.system.tools.deployment
Name-Value Pairs:
_ThreadID=13;_ThreadName=Thread-31;_RequestID=4b6cd8eb-371c-4160-944b-16bf75670cc4;
Record Number:
295
Message ID:
Could not expand entry null into destination /home/sjsas/SUNWappserver/domains/domain1/applications/j2ee-apps/ZF/ZF-EJB_jar java.io.IOException
Complete Message
Error expanding archive /home/sjsas/SUNWappserver/domains/domain1/applications/j2ee-apps/ZF/ZF-EJB.jar; please see the server log file for more information
     at com.sun.enterprise.deployment.backend.J2EEModuleExploder.explodeJar(J2EEModuleExploder.java:346)
     at com.sun.enterprise.deployment.backend.J2EEModuleExploder.explodeEar(J2EEModuleExploder.java:283)
     at com.sun.enterprise.deployment.backend.AppDeployer.explodeArchive(AppDeployer.java:323)
     at com.sun.enterprise.deployment.backend.AppDeployer.deploy(AppDeployer.java:182)
     at com.sun.enterprise.deployment.backend.AppDeployer.doRequestFinish(AppDeployer.java:129)
     at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:169)
     at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:95)
     at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:871)
     at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:266)
     at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:739)
     at com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:174)
     at com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:210)
Caused by: java.util.zip.ZipException: No such file or directory
     at java.util.zip.ZipFile.open(Native Method)
     at java.util.zip.ZipFile.<init>(ZipFile.java:203)
     at java.util.jar.JarFile.<init>(JarFile.java:132)
     at java.util.jar.JarFile.<init>(JarFile.java:97)
     at com.sun.enterprise.deployment.backend.J2EEModuleExploder.explodeJar(J2EEModuleExploder.java:298)
     ... 11 more

Need your Suggestion - regarding sjsas & axis

Hi,
I'm working on Sun java System Application Server8.1.. I'm now developing a document based web service client which invokes the service program generated using AXIS.... I have a doubt at this point... I'm using JAX-RPC1.1 specs.... i'm including the saaj-api.jar , xmlsecs.jar in my classpath along with the default jar files which comes with the package.... the above mentioned two packages has SOAPBodyElement.class and XMLUtility.class respectively which i'm using. But when i compile the code it gives the following compilation errors ...
symbol : method newDocument(java.io.FileInputStream)
location: class com.sun.org.apache.xml.internal.security.utils.XMLUtils
reqSOAPBodyElements[0] = new SOAPBodyElement(XMLUtils.newDocument(fis).getDocumentElement());
^
CatalogPublisherServiceClient.java:73: javax.xml.soap.SOAPBodyElement is abstract; cannot be instantiated
reqSOAPBodyElements[0] = new SOAPBodyElement(XMLUtils.newDocument(fis).getDocumentElement());
^
CatalogPublisherServiceClient.java:83: cannot find symbol
symbol : method getAsDOM()
location: interface javax.xml.soap.SOAPBodyElement
System.out.println(XMLUtils.ElementToString(resSOAPBodyElement.getAsDOM()));
But when i include axis.jar file in my classpath instead of the above mentioned jar files the code gets compiled suuccessfully.... axis.jar file contains both the above mentioned class files which i'm using... My main concern is if i use axis.jar which comes with axis, jakarta's product does it mean that i'm going out of my technological environment.. can i do that or is ther any other solution to over come this problem..
When i analyse the class files of axis package it implements javax.xml.soap which is from saaj-api.jar file.. i'm bit confused with this...
if i'm using axis.jar file in my classpath does it mean that i'm working on axis environment instead of sjsas environment...
can any body provide me a solution
thanks in advance
regards,
R Vijay

FICO forums
[ERP Financials|/community [original link is broken]://SAP ERP Financials;
[ERP Financials - Asset Accounting|SAP ERP Financials - Asset Accounting;
[ERP Financials - Financial Supply Chain Management|SAP ERP Financials - Financial Supply Chain Management;
[ERP Financials - Treasury Applications|SAP ERP Financials - Treasury Applications;

Facelets + tomahawk + SJSAS

Hi
I had posted this in the wrong forum. So I apologise if this looks familiar to some of you.
I am creating a JSF application using Facelets and tomahawk, deploying on SJSAS 8.1.
I have noticed some weird behavior:
1. If there is a problem with a tomahawk component, it is not registered in the log. For example, if I specify an invalid EL expression, normal HTML components will register this as an error in the log, tomahawk components do not.
2. I have an action that gets a record for the database and fills a Javabean (using OJB) or will create a new object. It will then navigate to a new page. If I add invalid information to a page, it registers the validation message in a messages component. However, if I redeploy the application and try opening a new record, I get the following error:
javax.faces.FacesException: #{promotionSelectPage.editPromotion}: javax.faces.el.EvaluationException: /promoSearch.xjsf @16,89 action="#{promotionSelectPage.editPromotion}": java.lang.IllegalStateException
com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:78)
javax.faces.component.UICommand.broadcast(UICommand.java:312)
javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:267)
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:381)
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:75)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:225)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:193)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
java.security.AccessController.doPrivileged(Native Method)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
3. Probably related to the previous issue, the tomahawk messages component (which I am using) is meant to display the label of the offending field. However, this does not work for me.
Any ideas of what could be wrong or how to debug this?
Cheers.

Apologies, wrong forum. I would remove this, if I knew how.
Message was edited by:
KamBha

SJSAS 2005Q1 JMS ConnectionFactory error

Hi all,
I am finally very close to getting a test JMS Topic connection working, but I am running into the issue with Root exceptions when trying to provide it with a INITIAL_CONTEXT_FACTORY. The SJSAS server is located on a different computer.
My question is, what values should I provide to
INITIAL_CONTEXT_FACTORY, and
PROVIDER_URL
I have tried all suggestions that were on this board, but none were specific to SJSAS and didn't work... I either got crazy messages ending with "Maybe" or a Root exception with the class.
Thanks for your help.

The solution can be found in this post:
http://forum.java.sun.com/thread.jspa?threadID=494092&tstart=0

Installing SJSAS (2005Q1) on AMD64

Hi all,
I am running into an issue installing SJSAS (filename: sjsas_pe-8_1_2005Q1-linux.bin) on AMD64 (Gentoo). I am using JDK 1.5.0.01. When I run the following:
./sjsas_pe-8_1_2005Q1-linux.bin -javahome /opt/sun-jdk-1.5.0.01 -tmpdir /tmp
And I get to
Extracting Java(TM) 2 Runtime Environment files...
and it gets stuck. I check the tmp dir, nothing is there. Any files/dirs created by the setup tool are empty. Any suggestions?
Thanks,
Max

Hi,
Thanks for your tips. I've successfully unzipped it. But, I am getting the following error when trying to exec:
Attach to native process failedWeird. I have 2 JDKs installed:
sun-jdk-1.5.0.01
blackdown-jdk-1.4.2.02
Neither worked... any more ideas?
Thanks again,
Max

Can't deploy in SJSAS 8.2

Hi, When I try to deploy an application under an x86 Solaris 10 and SJSAS 8.2 I receive this error:
[#|2007-02-27T13:45:38.059+0100|SEVERE|sun-appserver-pe8.2|javax.enterprise.system.tools.deployment|_ThreadID=18;|Exception occured in J2EEC Phase
com.sun.enterprise.deployment.backend.IASDeploymentException
        at com.sun.enterprise.deployment.archivist.Archivist.copyWithoutClose(Archivist.java:933)
        at com.sun.enterprise.deployment.archivist.Archivist.copyJarElements(Archivist.java:1059)
        at com.sun.enterprise.deployment.archivist.Archivist.copyInto(Archivist.java:1244)
        at com.sun.enterprise.deployment.archivist.Archivist.copyInto(Archivist.java:1205)
        at com.sun.enterprise.deployment.backend.J2EEModuleExploder.explode(J2EEModuleExploder.java:109)
        at com.sun.enterprise.deployment.backend.WebModuleDeployer.preDeploy(WebModuleDeployer.java:131)
        at com.sun.enterprise.deployment.backend.ModuleDeployer.doRequestFinish(ModuleDeployer.java:130)
        at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:148)
        at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:71)
        at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:639)
        at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:188)
        at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:520)
        at com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:139)
        at com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:168)Can anyone help me to find what's happens!
Thanks!

Hello,
I reply myself :-)
The problem was the name of an image. Some designer call it 'Sin t�tulo.jpg' and can't delete it when deploys. (Look for the accent in '�')
regards
PD: Sorry about my english! :-P

Migrating from SJSAS/Glassfish to JDeveloper 10.1.3/AS 10.1.3

Hi,
I have recently completed release 2 of a web application developed using Netbeans, Maven, JDK 1.5, SJSAS 9.1 Ur 2, JPA 1.0, some EJB 3.0, JSF 1.2 (Trinidad) and JAXB 2.x. I have been made a part of another team in our organisation that makes use of JDeveloper 10.1.2, Oracle AS 10.1.2, Struts, ADF 10.1.2 and JSP/JTSL with some ajax, jquery etc.
The front end for this application needs to be redeveloped to cater for usability changes and a new corporate theme. As part of the move it looks like the web application is going to need to be re-done to run within the new teams standard environment. Hopeful with the standard being bumped up to 10.1.3.
Would anyone have any recommendations related to which technology stack in JDeveloper 10.1.3 should be considered? Is ADF Faces 10.1.3 a reasonable move or stick with Struts, etc.
One constraint is that the revised app needs to be released in mid August.
Thank you.

If you are going to redevelop the view layer of your project, I would definitely look into using ADF Faces and JSF instead of Struts.
The ADF Faces components will give you a much richer UI and behavior out of the box. JSF is also much more future proof then Struts.
Struts was completely redone in Struts 2.0 and JDeveloper currently doesn't support Struts 2.0.
JSF on the other hand is the standard Web framework in Java EE - and is supported in both JDev 10.1.3 and JDev 11.
You should be able to take the model project from 10.1.2 and upgrade it to 10.1.3 without changes, and then you can stick a new JSF based UI on top of it.

SJSAS 8.2 secure and unsecure methods in one web service with ws-security

Hi
I'm trying to deploy a web-service (using SJSAS 8.2) using JAXRPC using message security (at the application level).
I have one simple question:
I have an EJB that exposes 2 methods as web-services, I specified in the sun-ejb-jar.xml that one of those methods is secure (and said nothing about the other) however when i run my test client I get a "WSS0202: No wsse:Security element in the message" error for both calls (instead of only for the secure call).
Is this normal? Isn't it possible to have a normal (with no security headers) call to one method and another (with security headers and secure envelope) to another in the same webservice (from the same EJB)?.

I wasn't clear?
This is a big dev problem for a major Sun client.
No one knows or wants to answer?

Content type and SJSAS 8.1: how is it handled after all?

Hi,
I'm having a weird error while downloading certificate files from our SJSAS 8.1. For some files it sets the Content-Type, for others it does not. The GET request and its headers are always the same, but sometimes the response comes with a content type set, sometimes it sets the only the Accept-ranges header. Two examples follow:
GET /repositorio/certificadosemitidos/SerasaACP_2002.gsc HTTP/1.1
HTTP/1.1 200 OK
Server: Sun-Java-System/Application-Server
Date: Fri, 24 Mar 2006 15:18:22 GMT
Content-length: 1533
Last-modified: Tue, 27 Apr 2004 18:49:46 GMT
Etag: "5fd-408eab4a"
Accept-ranges: bytes
GET /repositorio/certificadosemitidos/78FC38A69B998586.gsc HTTP/1.1
HTTP/1.1 200 OK
Server: Sun-Java-System/Application-Server
Date: Fri, 24 Mar 2006 15:19:13 GMT
Content-length: 1818
Content-type: application/octet-stream
X-powered-by: Servlet/2.4
Etag: W/"1818-1143213520000"
Last-modified: Fri, 24 Mar 2006 15:18:40 GMT
Other thing is that the MIME types don't work. The app server ignores the types stated in the default-web.xml. Alright, but we need it to be at least deterministic when the file extensions are the same. The files I'm dealing with (these .gsc) are digital certificates in rfc printable format, but I don't think that should make a difference.
Anyone gone through anything similar?
Thanks a lot!
Jo�o.

As long as you're using SJSAS to serve your port 80 traffic, default-web.xml should definitely be setting your mime type handling for the server. The only other things that will set this are custom settings in the web.xml for your individual applications, or specific mime types set by servelets you may have running in your application.
I've definitely set MIME types successfully just by editing default-web.xml and then bouncing the server.
Hope that helps somehow.
--Tad
Church of Scientology
http://www.scientology-washingtondc.org

Send JMS message from a webapp in Tomcat to JMS queue in SJSAS

Hi, everybody
I have a web application. Is is a simple JMS message sender: 2 jsp files(User Interface) and a java helper class which in charge of the sending of jms messages) . It runs well on SJSAS 9 web container.
After I have moved it to Tomcat5.5.17(bundled with Netbeans5.5.1), I have the following exception when I visit the jsp page:
type : Exception report
message :
description : The server encountered an internal error () that prevented it from fulfilling this request.
exception:
javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception
     org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     java.lang.Thread.run(Thread.java:595)
root cause :
java.lang.NoClassDefFoundError
     org.apache.jasper.servlet.JspServlet.init(JspServlet.java:106)
     org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     java.lang.Thread.run(Thread.java:595)I have imported appserv-rt.jar / appserv-ext.jar / appserv-deployment-jar / appserv-ws.jar / imqjmsra.jar / javaee.jar to my web application's library.
And i have used the argu-ed Context to do JNDI job to find the JMS resources in SJSAS.
I need your advices, thank you.

The following is the detailed info contains in Tomcat's logs file
SEVERE: StandardWrapper.Throwable
java.lang.NoClassDefFoundError: javax/servlet/jsp/JspApplicationContext
     at org.apache.jasper.compiler.JspRuntimeContext.<clinit>(JspRuntimeContext.java:84)
     at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:106)
     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
     at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
     at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917)
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:4201)
     at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
     at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
     at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
     at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:608)
     at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:493)
     at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1204)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
     at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
     at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
     at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
     at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1377)
     at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:814)
     at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:343)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
     at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:174)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     at java.lang.Thread.run(Thread.java:595)
Sep 7, 2007 1:56:10 PM org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet /zzTomcat threw load() exception
java.lang.NoClassDefFoundError: javax/servlet/jsp/JspApplicationContext
     at org.apache.jasper.compiler.JspRuntimeContext.<clinit>(JspRuntimeContext.java:84)
     at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:106)
     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
     at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
     at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917)
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:4201)
     at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
     at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
     at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
     at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:608)
     at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:493)
     at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1204)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
     at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
     at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
     at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
     at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1377)
     at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:814)
     at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:343)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
     at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:174)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     at java.lang.Thread.run(Thread.java:595)
Sep 7, 2007 1:57:14 PM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NoClassDefFoundError
     at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:106)
     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
     at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:757)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     at java.lang.Thread.run(Thread.java:595)
Sep 7, 2007 1:57:14 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Allocate exception for servlet jsp
java.lang.NoClassDefFoundError
     at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:106)
     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
     at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:757)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     at java.lang.Thread.run(Thread.java:595)
Sep 7, 2007 2:07:05 PM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NoClassDefFoundError
     at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:106)
     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
     at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:757)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     at java.lang.Thread.run(Thread.java:595)
Sep 7, 2007 2:07:05 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Allocate exception for servlet jsp
java.lang.NoClassDefFoundError
     at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:106)
     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
     at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:757)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
     at java.lang.Thread.run(Thread.java:595)

SJSAS EE 8.1_02 / Bug in jss4.jar breaks our new release

+[Full environment description below]+
Problem description: our application server contains several applications including one J2EE application made of several WARs and EJBs. One of these EJBs starts some internal services that use an open source library called jsch [1] to make SFTP transfers (we use jsch 0.1.31). This jsch library relies on javax.crypto and negotiates encryption with the remote SFTP server. Doing so, it selects a cryptographic cipher. This works well from our development and build environments but fails on our test server which uses Sun App Server 8.1_02. This server doesn't deploy a JavaCAPS application internally (we have a separate App. Server for it).
For some reasons (that I do not yet completely understand), our test (and production) Sun AS contains in the classpath a library (jss4.jar) and this library contains a cipher that is used for the transfer. The library may be related to Sun Application Manager or for some security setup but I am not yet sure. It may be standard with Sun AS EE.
As shown in the appendices below, this library seems to contain a bug causing the SFTP connection to fail. If the code is indeed the one that is used in jss4.jar, then the library is obviously broken. But the only Sun patch I've seen that upgrades the library was http://sunsolve.sun.com/search/document.do?assetkey=1-21-119211-14-1&searchclause=jss4.jar . Tt doesn't seem to address our problem (at least in the patch documentation).
I think that we now need some help/feedback from Sun. We have to either
* find out if we can remove this library from the classpath
* find a way to bypass the use of the cryptographic component
* or get a fix for the library itself.
Is it possible for someone at Sun to help us fix this issue ? We've to release again the application with a fix ASAP.
Cheers,
Jerome
Appendix 1 ** Environment:
SJSAS EE 8.1_02
java -versionjava version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)
uname -aSunOS ast-b2bdev 5.10 Generic_118822-27 sun4u sparc SUNW,Sun-Fire-V210
ls -la /usr/share/lib/mps/secv1/jss4.jarlrwxrwxrwx   1 root     root          11 Dec 12 2005 /usr/share/lib/mps/secv1/jss4.jar -> ../jss4.jar
ls -la /usr/share/lib/mps/jss4.jar -rw-r--r--   1 root     bin       657089 Jul 29 2005 /usr/share/lib/mps/jss4.jar
md5 /usr/share/lib/mps/jss4.jar 1c9f9b09a1d632f31458caef5cfe4812        /usr/share/lib/mps/jss4.jarAppendix 2 ** stack trace that we see while running our program
I've finally managed to get a full stack trace:
[#|2007-11-05T18:23:00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230 ;|
javax.crypto.ShortBufferException: 32 needed, 20480 supplied
        at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(JSSCipherSpi.java:338)
        at javax.crypto.Cipher.update(DashoA12275)
        at com.jcraft.jsch.jce.TripleDESCBC.update(TripleDESCBC.java:81)
        at com.jcraft.jsch.Session.encode(Session.java:800)
        at com.jcraft.jsch.Session._write(Session.java:1135)
        at com.jcraft.jsch.Session.write (Session.java:1132)
        at com.jcraft.jsch.UserAuth.start(UserAuth.java:52)
        at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:36)
        at com.jcraft.jsch.Session.connect(Session.java:350)
        at com.jcraft.jsch.Session.connect(Session.java:145)
        at org.apache.commons.vfs.provider.sftp.SftpClientFactory.createConnection(SftpClientFactory.java:210)
        at org.apache.commons.vfs.provider.sftp.SftpFileProvider.doCreateFileSystem (SftpFileProvider.java:90)
        at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:81)
        at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile (AbstractOriginatingFileProvider.java:62)
        at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:641)
        at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile (DefaultFileSystemManager.java:582)Appendix 3 ** potential matching bug in JSSCipherSpi as identified by jsch author
---------- Forwarded message ----------
From: Atsuhiko Yamanaka <[email protected]>
Date: Nov 6, 2007 2:12 AM
Subject: Re: [JSch-users] javax.crypto.ShortBufferException in Session with 0.1.31 ?
To: [email protected]
Cc: [email protected]
- Hide quoted text -
+-From: "Jerome Lacoste" <[email protected]> --
|_Date: Mon, 5 Nov 2007 18:39:50 +0100 _______________
|
|I've finally managed to get a full stack trace:
|[#|2007-11-05T18:23:
|00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230
|;|
|javax.crypto.ShortBufferException: 32 needed, 20480 supplied
|        at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(
|JSSCipherSpi.java:338)
|        at javax.crypto.Cipher.update (DashoA12275)
Sign, I knew.
Before writing my last message, I had found the following buggy code[1],
   public int engineUpdate(byte[] input, int inputOffset, int inputLen,
       byte[] output, int outputOffset) throws ShortBufferException
       byte[] bytes = engineUpdate(input, inputOffset, inputLen);
       if( bytes.length < output.length-outputOffset ) {
           throw new ShortBufferException(bytes.length + " needed, " +
               (output.length-outputOffset) + " supplied");
       System.arraycopy(bytes, 0, output, outputOffset, bytes.length);
       return bytes.length;
and I had strongly believed that the problem had come from it,
but it is contradict to your success with your own compiled jar.
[1] http://www.koders.com/java/fidF0D62D7385480B906B3CC88210B02AF4A84FF467.aspx

+[Full environment description below]+
Problem description: our application server contains several applications including one J2EE application made of several WARs and EJBs. One of these EJBs starts some internal services that use an open source library called jsch [1] to make SFTP transfers (we use jsch 0.1.31). This jsch library relies on javax.crypto and negotiates encryption with the remote SFTP server. Doing so, it selects a cryptographic cipher. This works well from our development and build environments but fails on our test server which uses Sun App Server 8.1_02. This server doesn't deploy a JavaCAPS application internally (we have a separate App. Server for it).
For some reasons (that I do not yet completely understand), our test (and production) Sun AS contains in the classpath a library (jss4.jar) and this library contains a cipher that is used for the transfer. The library may be related to Sun Application Manager or for some security setup but I am not yet sure. It may be standard with Sun AS EE.
As shown in the appendices below, this library seems to contain a bug causing the SFTP connection to fail. If the code is indeed the one that is used in jss4.jar, then the library is obviously broken. But the only Sun patch I've seen that upgrades the library was http://sunsolve.sun.com/search/document.do?assetkey=1-21-119211-14-1&searchclause=jss4.jar . Tt doesn't seem to address our problem (at least in the patch documentation).
I think that we now need some help/feedback from Sun. We have to either
* find out if we can remove this library from the classpath
* find a way to bypass the use of the cryptographic component
* or get a fix for the library itself.
Is it possible for someone at Sun to help us fix this issue ? We've to release again the application with a fix ASAP.
Cheers,
Jerome
Appendix 1 ** Environment:
SJSAS EE 8.1_02
java -versionjava version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)
uname -aSunOS ast-b2bdev 5.10 Generic_118822-27 sun4u sparc SUNW,Sun-Fire-V210
ls -la /usr/share/lib/mps/secv1/jss4.jarlrwxrwxrwx   1 root     root          11 Dec 12 2005 /usr/share/lib/mps/secv1/jss4.jar -> ../jss4.jar
ls -la /usr/share/lib/mps/jss4.jar -rw-r--r--   1 root     bin       657089 Jul 29 2005 /usr/share/lib/mps/jss4.jar
md5 /usr/share/lib/mps/jss4.jar 1c9f9b09a1d632f31458caef5cfe4812        /usr/share/lib/mps/jss4.jarAppendix 2 ** stack trace that we see while running our program
I've finally managed to get a full stack trace:
[#|2007-11-05T18:23:00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230 ;|
javax.crypto.ShortBufferException: 32 needed, 20480 supplied
        at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(JSSCipherSpi.java:338)
        at javax.crypto.Cipher.update(DashoA12275)
        at com.jcraft.jsch.jce.TripleDESCBC.update(TripleDESCBC.java:81)
        at com.jcraft.jsch.Session.encode(Session.java:800)
        at com.jcraft.jsch.Session._write(Session.java:1135)
        at com.jcraft.jsch.Session.write (Session.java:1132)
        at com.jcraft.jsch.UserAuth.start(UserAuth.java:52)
        at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:36)
        at com.jcraft.jsch.Session.connect(Session.java:350)
        at com.jcraft.jsch.Session.connect(Session.java:145)
        at org.apache.commons.vfs.provider.sftp.SftpClientFactory.createConnection(SftpClientFactory.java:210)
        at org.apache.commons.vfs.provider.sftp.SftpFileProvider.doCreateFileSystem (SftpFileProvider.java:90)
        at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:81)
        at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile (AbstractOriginatingFileProvider.java:62)
        at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:641)
        at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile (DefaultFileSystemManager.java:582)Appendix 3 ** potential matching bug in JSSCipherSpi as identified by jsch author
---------- Forwarded message ----------
From: Atsuhiko Yamanaka <[email protected]>
Date: Nov 6, 2007 2:12 AM
Subject: Re: [JSch-users] javax.crypto.ShortBufferException in Session with 0.1.31 ?
To: [email protected]
Cc: [email protected]
- Hide quoted text -
+-From: "Jerome Lacoste" <[email protected]> --
|_Date: Mon, 5 Nov 2007 18:39:50 +0100 _______________
|
|I've finally managed to get a full stack trace:
|[#|2007-11-05T18:23:
|00.980+0100|WARNING|sun-appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230
|;|
|javax.crypto.ShortBufferException: 32 needed, 20480 supplied
|        at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(
|JSSCipherSpi.java:338)
|        at javax.crypto.Cipher.update (DashoA12275)
Sign, I knew.
Before writing my last message, I had found the following buggy code[1],
   public int engineUpdate(byte[] input, int inputOffset, int inputLen,
       byte[] output, int outputOffset) throws ShortBufferException
       byte[] bytes = engineUpdate(input, inputOffset, inputLen);
       if( bytes.length < output.length-outputOffset ) {
           throw new ShortBufferException(bytes.length + " needed, " +
               (output.length-outputOffset) + " supplied");
       System.arraycopy(bytes, 0, output, outputOffset, bytes.length);
       return bytes.length;
and I had strongly believed that the problem had come from it,
but it is contradict to your success with your own compiled jar.
[1] http://www.koders.com/java/fidF0D62D7385480B906B3CC88210B02AF4A84FF467.aspx

[SJSAS 7 2004Q2 Update 2] Dynamic reloading and more...

Hi
In the context of a development environment, I'd like to know if there is a way to integrate Eclipse and SJSAS 7 in a way that as soon as Eclipse compiles a Java file (i.e. doing a save) it is inmediatly available to the app in order to test it. The same goes for HTMLs and properties files.
The reason for this question is because my dev cycle is very tedious, non-productive and time-cosuming, and coming from other project that had Eclipse with Sysdeo Tomcat Launcher plug-in, Tomcat 5.5 and a context file <app_context_name>.xml with its docBase attribute pointing to the webapp context root dir of my Eclipse project at the workspace, it was overly simple, productive and fast to develop with. Not to talk about debugging, it was as simple as toggling a breakpoint (on an already running Tomcat) and pointing your browser to hit it.
Is there something similar in SJSAS 7? Eclipse plug-in? Another IDE? SOMETHING?.
Hope I was clear enough.
Thanks in advance,
Cristian

Hi,
We didn't install the samples during the original ws7 u1 installation. It seems that this causes the u2 installer to fail, even if we do not select it to be updated/installed with the u2 installer.
Any fixes for this, other than hacking the .pl file for the installer upgrade, or installing the samples from the u1 release?

(Re)Deploying web apps under [/] on SJSAS PE8

I need some help on deploying web app under root []of the default virtual server.
The problem is when specifying "Default Web Module" for the virtual servers I guess...
How can I use asadmin or Ant task to deploy a directory under / ?
Is it possible to use asadmin to specify virtual server's "Default Web Module" without restarting it.
The optimal goal is to have ability to deploy/redeploy/undeploy a web app under / via ant task without restarting the domain itself....
How can I accomplish this under SJSAS PE8?
Any help on this topic is appreciated...

You may want to look at the responses in this thread:
http://forum.java.sun.com/thread.jsp?forum=136&thread=529445&tstart=0&trange=50
This thread may also be helpful:
http://forum.java.sun.com/thread.jsp?forum=136&thread=526094&tstart=0&trange=15
Note:
If the "redirect" that happens when you try to access the "docroot" of the admin instance is acceptable behavior, you may want to look at the differences between the 'server' and __asadmin Virtual Server.
While you can do that with any text editor, I would suggest that you use the admin console app to do this.
By deleting the docroot property and setting the default web module property you may be able to get the behavior you want.
You will have to deploy the web app, with a context-root that is NOT / and restart the app server.
You should be able to redeploy your web app "normally" after that, though....

SJSAS 8.2 or 9

Similar Messages

Maybe you are looking for