Jaxb xjc compiler problem

I have downloaded JAXB from java.sun.com through FTP and HTTP. When i tried to extract the zip file, i found the xjc compiler is existing as a file instead of an .exe file.Becoz of which i couldn't able to work with it.Pls help me out asap.
regards
Meena

Extract the following Jar files from jaxb-1.0-ea\lib to dircetroy where you want to keep your xml and generated java classes.
jxb-rt-1.0-ea
jaxb-xjc-1.0-ea
and then use the following commnad to run it:
java com.sun.tools.xjc.Main abc.dtd dcf.xjc
iam able generate the Java class with this commanad.

Similar Messages

Problems running xjc compiler for JAXB

I'm new to the web services pack and I am trying to run the xjc script to launch the binding compiler, but nothing is launched. I checked the env-vars and they look correct but maybe I am missing something. Below is the echoed output when I launch the script and pause it. There is an output regarding 'C:Programs' which I don't understand. Any ideas? Thanks
C:\Sun\jwsdp-1.6\jaxb\bin>rem Make sure that JAXB_HOME and JAVA_HOME are set
C:\Sun\jwsdp-1.6\jaxb\bin>rem
C:\Sun\jwsdp-1.6\jaxb\bin>if not "C:\Sun\jwsdp-1.6\jaxb" == "" goto CHECKJAVAHOM
E
C:\Sun\jwsdp-1.6\jaxb\bin>if not "C:\Program Files\Java\jdk1.5.0_05" == "" goto
USE_JAVA_HOME
C:\Sun\jwsdp-1.6\jaxb\bin>set JAVA=C:\Program Files\Java\jdk1.5.0_05\bin\java
C:\Sun\jwsdp-1.6\jaxb\bin>goto LAUNCHXJC
C:\Sun\jwsdp-1.6\jaxb\bin>set JAXP_HOME=C:\Sun\jwsdp-1.6\jaxb\..\jaxp
C:\Sun\jwsdp-1.6\jaxb\bin>C:\Program Files\Java\jdk1.5.0_05\bin\java -Djava.end
orsed.dirs=C:\Sun\jwsdp-1.6\jaxb\..\jaxp\lib;C:\Sun\jwsdp-1.6\jaxb\..\jaxp\lib\e
ndorsed -jar C:\Sun\jwsdp-1.6\jaxb\lib\jaxb-xjc.jar
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
C:\Sun\jwsdp-1.6\jaxb\bin>C:\WINNT\system32\cmd.exe /C exit 9009
C:\Sun\jwsdp-1.6\jaxb\bin>pause
Press any key to continue . . .

I don't know whether this is the answer to your question. If all other things are right, please make sure that you don't have spaces in between the environment variables set.

JAXB (XJC) problem with Java 1.4.2_02

Hi,
I am trying to migrate our system to Java version 1.4.2_02 (currently using 1.4.1_02). We use XJC from JAXB to compile XML schema files into java classes. JAXB is packaged in JWSDP (we are using version 1.3). I am currently experiencing a problem whereby if I use java version 1.4.2_02 and run XJC on the xml schema file its not generating any of the inner classes. All classes including inner are generated properly if I am pointing 1.4.1_02.
Just wondering if you came across this problem before and would know of a possible solution.
thanks for your help
Manish

I was having this problem as well. I extracted the MSI from the InstallShield and found that it's looking for a property called "SystemFilesLocked" to equal 1. If you pass it as a parameter and give it a value of 0, this error message doesn't appear. I've installed now to 15 W2K desktops without any issues.
The 'silent installation' documentation for this product is sorely lacking. The install string I'm using is below:
j2re-1_4_2_03-windows-i586-p.exe /S /v/qn"ADDLOCAL=jrecore SYSTEMFILESLOCKED=0 CONTROLPANELLOCKED=1 SKDSILENT=1 IEXPLORER=0 SYSTRAY=0 REBOOT=Suppress JAVAUPDATE=0 JAVAJAVAWLOCKED=0 WEBSTARTICON=0 /L C:\TEMP\LogFiles\JRE_JWS_142_03.log"
Hope this helps...

JAXB: XJC src-resolve error when importing other schemes

Hi!
I keep getting a src-resolve error from the JAXB binding compiler whenever I try to import other XML schemes into my own.
For example:
I want to use a SignatureType element as defined in the official XML signature schema.
So I imported it into my own schema and use it as follows:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<xsd:complexType name="PayloadType">
<xsd:sequence>
<xsd:element name="signature" type="ds:SignatureType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>However if I run XJC to compile my schema I get this error:
[xjc] [ERROR] src-resolve: Cannot resolve the name 'ds:SignatureType' to a(n) 'type definition' component.I am using JAXB 2.0 EA from the JWSDP 2.0 and XJC is called from an Ant task.
I am pretty new to JAXB and XML schemes, so any help on this topic would be greatly appreciated.

I got the the answer from another forum; it was a proxy problem. Just to inform succeeding readers, here is what I did:
To receive a better error output, I modified my ant buildfile to use the "nv" parameter:
<xjc schema="${path}/.../mySchema.xsd" package="mySchemaPackage" destdir="${path}/.../src">
<arg value="-nv" />
<produces dir="${path}/.../src/mySchemaPackage" includes="**/*.java" />
</xjc>Result:
The XJC compiler gives me a different (better) error message:
[xjc] [ERROR] java.net.ConnectException: Connection timed out: connectSo I looked in my Ant buildfile again to check the proxy settings. I merely used property-tags to define my proxy settings (<property name="http.proxyHost" value="nnn.nnn.nnn.nnn" /> and <property name="http.proxyPort" value="nnnn" /> ) which apparently do not work.
Instead this here does the trick:
<setproxy proxyhost="nnn.nnn.nnn.nnn" proxyport="nnnn"/>Good to now that "nv" might give you a better error report.

Odd xjc compilation issues

I realized recently that my complex type issues might be due to the fact that I was using version 1.6 of JAXB so I switched over to 2.0. I downloaded version 1.5 of the jdsk/jre as well since the documentation seemed to imply version 1.4.2 wont work with JAXB 2.0. I ran the xjc compiler and it didnt raise any errors. However, the resulting packages look very bizarre and every single one of them are flagged in error. In almost every case each package has an import statement that is trying to import itself. And I have all these Syntax error on tokens error message revolving around some @XmlEnumValue function (at least i think its a function).
Am I missing something?

Can be very hard to impossible to track down auto sleep issues. Just get PleaseSleep.
http://www.dragonone.com/products/macosx/pleasesleep/

An XJC compilation error - Could not load class (..) for type cvsversion

I've got a strange compilation error using NetBeans 4.0 (I'd guess the version does not matter here) and Ant 1.6.2. When the following task is executed,
<target name="compile_ofx_schema">
<antcall target="clean-ofx"/>
<delete dir="${ofx-jaxb-src.dir}"/>
<mkdir dir="${ofx-jaxb-src.dir}" />
<xjc schema="${schema.dir}/ofx102.xsd" package="com.xxx.ofx102" target="${ofx-jaxb-src.dir}">
<arg value="-nv" />
<arg value="-extension" />
</xjc>
</target>
I get the error from NetBeans console,
Class org.xml.sax.SAXException loaded from parent loader (parentFirst)
Class java.io.IOException loaded from parent loader (parentFirst)
D:\appserver\build.xml:797: unable to parse the schema. Error messages should have been provided
at com.sun.tools.xjc.XJCTask._doXJC(XJCTask.java:334)
at com.sun.tools.xjc.XJCTask.doXJC(XJCTask.java:283)
at com.sun.tools.xjc.XJCTask.execute(XJCTask.java:227)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
at org.apache.tools.ant.Project.executeTargets(Project.java:1062)
at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:217)
at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:236)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
BUILD FAILED (total time: 4 seconds)
Could not load class (org.apache.tools.ant.tasksdefs.cvslib.CvsVersion) for type cvsversion
Could not load class (org.apache.tools.ant.tasksdefs.cvslib.CvsVersion) for type cvsversion
And when I run the Ant task from the command line, I don't get the error at all.
Any help is greatly appreciated.

That was a great finding from you. Thank you.
I followed your alternative approach and updated the ant.jar file. The "Could not load class..." error went away but the stack trace still remains. Now I am clueless again since I have ant on the debug mode and can't find any more useful info.
Class com.sun.tools.xjc.reader.internalizer.LocatorTable loaded from ant loader (parentFirst)
Class java.util.HashSet loaded from parent loader (parentFirst)
Class javax.xml.parsers.DocumentBuilderFactory loaded from parent loader (parentFirst)
Couldn't load Resource org/netbeans/core/xml/DOMFactoryImpl.class
Couldn't load ResourceStream for META-INF/services/javax.xml.parsers.DocumentBuilderFactory
Class org.apache.crimson.jaxp.DocumentBuilderFactoryImpl loaded from parent loader (parentFirst)
Class javax.xml.parsers.SAXParserFactory loaded from parent loader (parentFirst)
Couldn't load Resource org/netbeans/core/xml/SAXFactoryImpl.class
Couldn't load ResourceStream for META-INF/services/javax.xml.parsers.SAXParserFactory
Class org.apache.crimson.jaxp.SAXParserFactoryImpl loaded from parent loader (parentFirst)
Class javax.xml.parsers.DocumentBuilder loaded from parent loader (parentFirst)
Class java.util.Map loaded from parent loader (parentFirst)
Class javax.xml.parsers.SAXParser loaded from parent loader (parentFirst)
Finding class com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder
Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/xmlschema/parser/XMLSchemaInternalizationLogic$ReferenceFinder.class
Finding class com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl
Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/internalizer/AbstractReferenceFinderImpl.class
Class org.xml.sax.helpers.XMLFilterImpl loaded from parent loader (parentFirst)
Class com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl loaded from ant loader (parentFirst)
Class com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder loaded from ant loader (parentFirst)
Class org.xml.sax.XMLFilter loaded from parent loader (parentFirst)
Finding class com.sun.tools.xjc.reader.internalizer.VersionChecker
Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/internalizer/VersionChecker.class
Class com.sun.tools.xjc.reader.internalizer.VersionChecker loaded from ant loader (parentFirst)
Finding class com.sun.tools.xjc.reader.internalizer.DOMBuilder
Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-xjc.jar com/sun/tools/xjc/reader/internalizer/DOMBuilder.class
Finding class com.sun.xml.bind.marshaller.SAX2DOMEx
Loaded from D:\bbw\build\Common_3.6\Packaged\appserver\lib\jaxb\jaxb-impl.jar com/sun/xml/bind/marshaller/SAX2DOMEx.class
Class org.xml.sax.ContentHandler loaded from parent loader (parentFirst)
Class com.sun.xml.bind.marshaller.SAX2DOMEx loaded from ant loader (parentFirst)
Class com.sun.tools.xjc.reader.internalizer.DOMBuilder loaded from ant loader (parentFirst)
Class java.util.Stack loaded from parent loader (parentFirst)
Class org.w3c.dom.Document loaded from parent loader (parentFirst)
Class org.xml.sax.XMLReader loaded from parent loader (parentFirst)
Class org.w3c.dom.Node loaded from parent loader (parentFirst)
Class org.w3c.dom.Element loaded from parent loader (parentFirst)
Class javax.xml.parsers.ParserConfigurationException loaded from parent loader (parentFirst)
Class org.xml.sax.SAXException loaded from parent loader (parentFirst)
Class java.io.IOException loaded from parent loader (parentFirst)
D:\bbw\build\Common_3.6\Packaged\appserver\build.xml:799: unable to parse the schema. Error messages should have been provided
at com.sun.tools.xjc.XJCTask._doXJC(XJCTask.java:334)
at com.sun.tools.xjc.XJCTask.doXJC(XJCTask.java:283)
at com.sun.tools.xjc.XJCTask.execute(XJCTask.java:227)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
at org.apache.tools.ant.Project.executeTargets(Project.java:1062)
at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:217)
at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:236)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
BUILD FAILED (total time: 1 second)
Any suggestions? BTW, I did not upgrade NetBeans to v5.5 due that my code is still JDK1.4 based.

Getting error while using jaxb/xjc

hello every one,
i have a xsd and i want automated classes from it for which i am using jaxb and xjc compiler but when i am running it then i am getting error
parsing a schema...
compiling a schema...
Exception in thread "main" java.lang.IllegalArgumentException: Expected
class ja
vax.xml.bind.annotation.XmlAccessType but found class
javax.xml.bind.annotation.
my xsd is
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="clients"
type="ClientsDef"/>
<xs:complexType name=" ClientsDef ">
<xs:sequence>
<xs:element name="pers" type="Person"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Person">
<xs:sequence>
<xs:element name="name"
type="xs:string"/>
<xs:element name="date_of_birth"
type="xs:date"/>
<xs:element name="cnp"
type="xs:string"/>
<xs:element name="adress"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
any one please help me out...

Hi,
XSD is well formed but for JAXB, it needs to have the complexType declaration inner the root element:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="clients">
    <xs:complexType>
        <xs:sequence>
            <xs:element name="pers" type="Person" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>
</xs:element>
<xs:complexType name="Person">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="date_of_birth" type="xs:date"/>
<xs:element name="cnp" type="xs:string"/>
<xs:element name="adress" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>Tested this works with this Main using jaxb-bindings in Netbeans (defining XSD compilation under clients package, Main in default package):
import clients.Clients;
import clients.ObjectFactory;
import clients.Person;
import java.io.ByteArrayOutputStream;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
public class Main
    public static void main(String args[]) throws Exception
        ObjectFactory of = new ObjectFactory();
        Clients cd = of.createClients();
        Person p = of.createPerson();
        p.setAdress("address");
        p.setCnp("cnp");
        p.setName("name");
        cd.getPers().add(p);
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        try
            JAXBContext ctx;
            ctx = JAXBContext.newInstance(Clients.class);
            Marshaller marshaller = ctx.createMarshaller();
            marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, new Boolean(true));
            marshaller.marshal(cd, bos);
            System.out.println(bos.toString());
        finally
            bos.close();
}Generates:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<clients>
<pers>
<name>name</name>
<cnp>cnp</cnp>
<adress>address</adress>
</pers>
</clients>

Can't use JAXB schema compiler output!!

when i try to compile large .xsd file with JAXB schema compiler, it generates java source just fine.
but when i try to compile the source into classes, javac runs out of memory! the files are to big! anyone can i make them smaller please?
thanks in the advance!

Does anyone know how to do this? I just need to make the files smaller. The classes have all been statically nested by the code generator. How can I simply make them be statically instantiated, but declared in seperate, smaller, compileable files?
Doesn't anyone else have this problems? It seems like anyone else trying to compile large schema files with JAXB would run into this issue??
Thanks

Preventing JAXB xjc from re-generating java code of import ed schemas...

Hi, I am using XJC to generate java code from xsd.
However the xsd I run it on often has imports to another xsd that will be in a jar along with its java classes already existing.
This jar is on the calsspath too.
XJC however not only generates java code for existing xsd, but also for every import it has.
And also for every import each of those imported xsd's might have.
So if it were a long import chain A->B->C->D it generates code for all.
How can i get it to generate code for only A and assume all the remaing code can be found on the jars in the classpath.
The A.xsd also has a catalog file associated with it that has every namespace reference pointing to the correct xsd locations within jars.
So it even has B->C mapping and C->D mapping. This was needed or else XJC didnt even generate anything at all and complained it could not reach C from B and so on.
Catalog file solved that problem but not the fact that it keeps regnerating code.
Thanks
Edited by: Priyajeet on Dec 9, 2008 1:36 PM

Problem solved.
The xjc compiler reads file name in a case-sensitive fashion, even on windows.
So, common.xsd and Common.xsd are seen as two distinct files.
This was the cause of the compilation errors, since feature1 imported the schema using the filename Common.xsd, whereas the other schemas imported common using common.xsd
I hope this could help.
Salvatore

WS7/Comms Express Compilation problem

I am just doing an implementation of the JES5 comms suite on WS7 and am getting the following error after logging in. Two questions:
1) Could someone send me a working server.xml (with the right classpath)
2) Has anyone else seen this error.
Web server Version
[24/May/2007:10:46:20] info (25597): CORE1116: Sun Java System Web Server 7.0 B12/04/2006 10:15
[24/May/2007:10:46:21] info (25598): CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.]
JVM version
/var/opt/SUNWwbsvr7/https-ce2.mail.uwo.pri/logs
[9:56am ce2]# /usr/jdk/latest/bin/javac -version
javac 1.5.0_09
Error message
Application Error
org.apache.jasper.JasperException: PWC6033: Unable to compile class for JSP
PWC6199: Generated servlet error:
/var/opt/SUNWwbsvr7/https-ce2.mail.uwo.pri/generated/ce2.mail.uwo.pri/uwc/org/apache/jsp/uwc/mailclient/mail_jsp.java:306: jspxmeth_jato_text_0(javax.servlet.jsp.tagext.JspTag,javax.servlet.jsp.PageContext) in org.apache.jsp.uwc.mailclient.mail_jsp cannot be applied to (com.iplanet.jato.taglib.UseViewBeanTag,javax.servlet.jsp.PageContext)
if (_jspx_meth_jato_text_0(_jspx_th_jato_useViewBean_0, jspxpage_context))
^
Note: /var/opt/SUNWwbsvr7/https-ce2.mail.uwo.pri/generated/ce2.mail.uwo.pri/uwc/org/apache/jsp/uwc/mailclient/mail_jsp.java uses unchecked or unsafe operations.
PWC6199: Generated servlet error:
Note: Recompile with -Xlint:unchecked for details.
1 error

I can send this to you offline if that makes it simpler.
From WS 7/JCS 5 installation on Solaris 10 Update 3 11/06
<?xml version="1.0" encoding="UTF-8"?>

<server>
<cluster>
<local-host>homer.cityofprescott.org</local-host>
<instance>
<host>homer.cityofprescott.org</host>
</instance>
</cluster>
<log>
<log-file>../logs/errors</log-file>
<log-level>info</log-level>
</log>
<temp-path>/tmp/https-homer.cityofprescott.org-2fe52e21</temp-path>
<user>webservd</user>
<jvm>
<java-home>/usr/jdk/entsys-j2se</java-home>
<server-class-path>/opt/SUNWwbsvr7/lib/webserv-rt.jar:/opt/SUNWwbsvr7/lib/pwc.jar:${java.home}/lib/tools.jar:/opt/SUNWwbsvr7/lib
/webserv-jstl.jar:/opt/SUNWwbsvr7/lib/container-auth.jar:/opt/SUNWwbsvr7/lib/jsf-impl.jar:/opt/SUNWwbsvr7/lib/jsf-api.jar:/usr/sfw/l
ib/ant/ant.jar:/usr/share/lib/ktsearch.jar:/opt/SUNWjax/share/lib/jaxws-api.jar:/opt/SUNWjax/share/lib/jaxws-rt.jar:/opt/SUNWjax/sha
re/lib/jaxws-tools.jar:/opt/SUNWjax/share/lib/jsr181-api.jar:/opt/SUNWjax/share/lib/jsr250-api.jar:/opt/SUNWjax/share/lib/jaxb-api.j
ar:/opt/SUNWjax/share/lib/jaxb-impl.jar:/opt/SUNWjax/share/lib/jaxb-xjc.jar:/opt/SUNWjax/share/lib/sjsxp.jar:/opt/SUNWjax/share/lib/
jsr173_api.jar:/opt/SUNWjax/share/lib/saaj-api.jar:/opt/SUNWjax/share/lib/saaj-impl.jar:/opt/SUNWjax/share/lib/xmldsig.jar:/opt/SUNW
jax/share/lib/xmlsec.jar:/opt/SUNWjax/share/lib/xws-security.jar:/opt/SUNWjax/share/lib/xws-security_jaxrpc.jar:/opt/SUNWjax/share/l
ib/wss-provider-update.jar:/opt/SUNWjax/share/lib/security-plugin.jar:/opt/SUNWjax/share/lib/FastInfoset.jar:/opt/SUNWjax/share/lib/
relaxngDatatype.jar:/opt/SUNWjax/share/lib/resolver.jar:/usr/share/lib/mail.jar:/usr/share/lib/activation.jar</server-class-path>
<class-path-suffix>:/opt/SUNWam/lib/xmlsec.jar:/usr/share/lib/endorsed/dom.jar:/opt/SUNWam/lib/saaj-api.jar:/opt/SUNWam/lib/jaxr
pc-api.jar:/opt/SUNWam/lib/jaxrpc-impl.jar:/opt/SUNWam/lib/jaxrpc-spi.jar:/opt/SUNWam/lib/saaj-impl.jar:/etc/opt/SUNWam/config:/opt/
SUNWam/lib:/opt/SUNWam/locale:/usr/share/lib/mps/secv1/jss4.jar:/opt/SUNWam/lib/am_sdk.jar:/usr/share/lib/ldapjdk.jar:/opt/SUNWam/li
b/am_services.jar:/opt/SUNWam/lib/am_sso_provider.jar:/opt/SUNWam/lib/swec.jar:/opt/SUNWam/lib/acmecrypt.jar:/opt/SUNWam/lib/iaik_ss
l.jar:/opt/SUNWam/lib/iaik_jce_full.jar:/opt/SUNWam/lib/mail.jar:/opt/SUNWam/lib/activation.jar:/opt/SUNWam/lib/am_logging.jar:/opt/
SUNWam/lib/jaas.jar:/opt/SUNWam/lib/jax-qname.jar:/opt/SUNWam/lib/namespace.jar:/opt/SUNWam/lib/relaxngDatatype.jar:/opt/SUNWam/lib/
xsdlib.jar:/opt/SUNWam/lib/jaxb-api.jar:/opt/SUNWam/lib/jaxb-impl.jar:/opt/SUNWam/lib/jaxb-libs.jar:/opt/SUNWam/lib/jaxb-xjc.jar:/op
t/SUNWam/lib/amclientsdk.jar:/opt/SUNWma/lib/wireless_rendering.jar:/opt/SUNWma/lib/wireless_rendering_util.jar:/opt/SUNWma/lib/mobi
le_services.jar:/opt/SUNWma/lib/ccpp-1_0.jar:/opt/SUNWma/lib/ccpp-ri-1_0.jar:/opt/SUNWma/lib/jena-1.4.0.jar:/opt/SUNWma/lib/rdffilte
r.jar:/opt/SUNWma/lib/locale:/opt/SUNWam/lib/mobile_identity.jar:/opt/SUNWmfwk/lib/mfwk_instrum_tk.jar:/opt/SUNWjdmk/5.1/lib/jdmkrt.
jar:/opt/SUNWjdmk/5.1/lib/jmxremote.jar:/opt/SUNWjdmk/5.1/lib/jmx.jar:/opt/SUNWcomm/lib/jars/commcli-client.jar:/opt/SUNWcomm/lib/ja
rs/jdapi.jar:/opt/SUNWcomm/lib/jars/commcli-callback.jar</class-path-suffix>
<debug>false</debug>
<debug-jvm-options>-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7896</debug-jvm-options>
<jvm-options>-Djava.security.auth.login.config=login.conf</jvm-options>
<jvm-options>-Xms128m -Xmx256m</jvm-options>
<jvm-options>-Djava.protocol.handler.pkgs=com.iplanet.services.comm</jvm-options>
<jvm-options>-DLOG_COMPATMODE=Off</jvm-options>
<jvm-options>-Ds1is.java.util.logging.config.class=com.sun.identity.log.s1is.LogConfigReader</jvm-options>
<jvm-options>-Dcom.iplanet.am.serverMode=true</jvm-options>
</jvm>
<thread-pool>
<max-threads>128</max-threads>
<stack-size>131072</stack-size>
</thread-pool>
<default-auth-db-name>keyfile</default-auth-db-name>
<auth-db>
<name>keyfile</name>
<url>file</url>
<property>
<name>syntax</name>
<value>keyfile</value>
</property>
<property>
<name>keyfile</name>
<value>keyfile</value>
</property>
</auth-db>
<acl-file>default.acl</acl-file>
<mime-file>mime.types</mime-file>
<access-log>
<file>../logs/access</file>
</access-log>
<http-listener>
<name>http-listener-1</name>
<port>80</port>
<server-name>homer.cityofprescott.org</server-name>
<default-virtual-server-name>homer.cityofprescott.org</default-virtual-server-name>
</http-listener>
<virtual-server>
<name>homer.cityofprescott.org</name>
<host>homer.cityofprescott.org</host>
<http-listener-name>http-listener-1</http-listener-name>
<document-root>/var/opt/SUNWwbsvr7/https-homer.cityofprescott.org/docs</document-root>
<web-app>
<uri>/amserver</uri>
<path>../web-app/homer.cityofprescott.org/amserver</path>
</web-app>
<web-app>
<uri>/ampassword</uri>
<path>../web-app/homer.cityofprescott.org/ampassword</path>
</web-app>
<web-app>
<uri>/amcommon</uri>
<path>../web-app/homer.cityofprescott.org/amcommon</path>
</web-app>
<web-app>
<uri>/amconsole</uri>
<path>../web-app/homer.cityofprescott.org/amconsole</path>
</web-app>
<web-app>
<uri>/im</uri>
<path>../web-app/homer.cityofprescott.org/im</path>
</web-app>
<web-app>
<uri>/da</uri>
<path>../web-app/homer.cityofprescott.org/da</path>
</web-app>
<web-app>
<uri>/commcli</uri>
<path>../web-app/homer.cityofprescott.org/commcli</path>
</web-app>
<web-app>
<uri>/uwc</uri>
<path>/var/opt/SUNWuwc</path>
</web-app>
</virtual-server>
</server>

Re: [iPlanet-JATO] sp3 jsp compiler problem

Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text
substitution situations, and as a completely independent tool its use is not
restricted to migration situations (or file types for that matter).
Second, I sympathize with the unfortunate trouble you are experiencing due to
Jasper's (perhaps more strict) compilation, but in what way did the iMT
automated translation contribute to these inconsistencies that you cited?
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a
translation situation, the only way "OnClick" would have been introduced was if
it had been part of the pre-existing project's "extraHTML" (which was written
by the original customer and just passed through unchanged by the iMT) or if it
was added manually by the post-migration developer.
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be
similar to the OnClick situation described above?
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no
equivalent in the NetDynamics world, so any content tags in your code must have
been introduced by your developers manually. Its a shame that jasper is so
particular, but the iMT could not help you out here even if we wanted to. The
constants that are used by the iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can see, the
only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174144234026000079108238073194105057099246073154180137239239223019162">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
[Non-text portions of this message have been removed]

Thanks a lot Matt and Mike for your prompt replies.
I agree completely that iMT doesn't introduce the inconsistencies.
About the three cases I mentioned, the third one happens only in
manually created JSPs. So it has nothing to do with iMT. The first
two are mainly due to the existing HTML code, as you rightly pointed
out.
The reason I made the suggestion is since we know that case 1 and 2
won't pass the japser compiler in sp3, we have to do something about
it. The best place to do this, in my mind, is iMT. Of course, there
might be some twists that make it impossible or difficult to do this
kind of case manipulation or attribute discard.
Weiguo
--- In iPlanet-JATO@y..., "Mike Frisino" <Michael.Frisino@S...> wrote:
Weiguo,
First, Matt is correct, the regular expression tool is perfect for general text substitution situations, and as a completely independent
tool its use is not restricted to migration situations (or file types
for that matter).
>
Second, I sympathize with the unfortunate trouble you are experiencing due to Jasper's (perhaps more strict) compilation, but
in what way did the iMT automated translation contribute to these
inconsistencies that you cited?
>
1. Changed the case of the tag attribute to be the same as what's
defined in tld.
example: changed OnClick to onClick
The iMT does not generate any OnClick or onClick clauses per se. In a translation situation, the only way "OnClick" would have been
introduced was if it had been part of the pre-existing
project's "extraHTML" (which was written by the original customer and
just passed through unchanged by the iMT) or if it was added manually
by the post-migration developer.
>
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.Can you give soem examples? Is there a definite pattern? Again, this might be similar to the OnClick situation described above?
>
>
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
Again, the content tag would never have been generated by the iMT. There was no equivalent in the NetDynamics world, so any content tags
in your code must have been introduced by your developers manually.
Its a shame that jasper is so particular, but the iMT could not help
you out here even if we wanted to. The constants that are used by the
iMT are defined in
com.iplanet.moko.jsp.convert.JspConversionConstants. From what I can
see, the only situation of a closing tag with any space in it is
public static final String CLOSE_EMPTY_ELEMENT = " />";
But that should not cause the type of problem you are referring to.
Mike
----- Original Message -----
From: Matthew Stevens
Sent: Thursday, September 06, 2001 10:16 AM
Subject: RE: [iPlanet-JATO] sp3 jsp compiler problem
Weiguo,
Others will chime in for sure...I would highly recommend the Regex Tool from
the iMT 1.1.1 for tackling this type of problem. Mike, Todd and myself have
posted to the group (even recently) on directions and advantages of creating
your own RULES (rules file) in XML for arbitary batch processing of source.
>
matt
-----Original Message-----
From: weiguo.wang@b...
[mailto:<a href="/group/SunONE-JATO/post?protectID=125056020108194190033029175101192165174048139046">weiguo.wang@b...</a>]
Sent: Thursday, September 06, 2001 12:25 PM
Subject: [iPlanet-JATO] sp3 jsp compiler problem
Matt/Mike/Todd,
We are trying to migrate to sp3 right now, but have had a lot of
issues with the new jasper compiler.
The following workaround has been employed to solve the issues:
1. Changed the case of the tag attribute to be the same as
what's
defined in tld.
example: changed OnClick to onClick
2. Removed attributes which are not defined in tld.
example: escape attribute only defined in three tags
but in some pages, it's used although it's not defined as an
attribute
of certain tags. The jasper compiler doesn't like it.
3. In an end tag, there can't be any space.
example: </content > doesn't work. </content> works.
As I see it, we have two options to go about solving this problem:
>>
1. Write a script which will iterate through all the jsp files and
call jspc on them. Fix the errors manually when jspc fails. Jspc will
flag the line number where an error occurs.
2. Write a utility which scans the jsp files and fix the errors when
they are encountered. We should define what's an error and how to
correct it. It's best if we combine this with solution 1 since we
might miss an error condition.
Actually, there might be another option, which is seeking help from
you guys since you have better understanding of JATO and iAS. Can you
do anything to help us?
We would be happy to hear your thoughts.
At last, I would like to suggest modifying the moko tool so that
these rules are enforced and the generated JSPs work with the new
compiler. This is for the benefit of any new migration projects.
Thanks a lot.
Weiguo
[email protected]
Choose from 1000s of job listings!
[email protected]
Service.
>
>
>
[Non-text portions of this message have been removed]

Servlet Compilation Problem !

Hi,
I am just starting to learn servlets and I got problem in compiling them. I got compilation error in
import javax.servlet.*;statement. Seems that the compiler cannot find the servlet package. I got J2EE 1.4 beta installed on my machine but there is no servlet.jar package. I am using J2SDK 1.4.1_02, J2EE 1.4 beta and Tomcat 4.1.24.
Can anyone help me with my servlet compilation problem?
Thanks in advance!
Josh

servlet.jar is here :
<tomcatdir>\common\lib
add it to your compiler classpath

Compilation problem in a JSP page

Hi all,
I'm trying to write a jsp page and some java stuff in it.
It goes something like this -
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@ page contentType="text/html;charset=windows-1255"%>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=windows-1255"/>
    <title>Michael</title>
</head>
<body>
<%
          String strError="";
%>
</body>Now the problem is that I get compilation problem about the use in java -
"String cannot be resolved to a type"
I know for sure that in other computers it's work, the question is what I'm missing?
I have Java VM installed and I've downloaded and installed the latest JDK, what else?
thanks,
Michael.

Michael4488 wrote:
BalusC wrote:
Then you should be using JSTL/EL.I don't familiar with this technology, any way - Its work on one computer so in my understanding it should work on the other as well.It is not related to the actual problem. It was just a comment on your code. Using scriptlets is considered as bad practice.
I understand that of course, but I don't use any configuration file or set any special parameters in my computer.
What exactly does the compiler need in order to recognize the Java code in the JSP page? If i manually add the JAVA_HOME environment variable it will work?
where should I refer it to? "..\Java\jre1.6.0_07\lib" will do?It must point to the root installation directory of the JDK (thus not the JRE!).

Compilation problem on solaris9 x86

I am working on JAVA/J2EE . Am new to solaris9 . My requirement is to compile a source distribution of MOD-JK 1.2.21 (apache 2.0 server connector)and to produce binary distribution (*.so file) in solaris9 X86 box. But i got only source distribution of solaris10 X86 platform . Even with this source i tried to compile in solaris9 box its giving some error message and i can't able to make a executable file. Below i pasted the error message .
# ./configure -with-apxs=/usr/apache2/bin/apxs
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking target system type... i386-pc-solaris2.10
checking for a BSD-compatible install... scripts/build/unix/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... no
checking for gcc... no
checking for cc... cc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
Can any body help me in this regards. Even i don't know, am proceeding in right direction to compile this file. If any body having the binary distribution for the same MOD-JK1.2.21 on solaris9 or solaris10 X86 platform for apache2.0 . please help me to compile this file .I given below the config.log file entries also.
Thanks in advance..........
karthikeyan.u
[email protected]
AIM or AOL :: karthikeyanu
CONFIG.log entries......
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ ./configure -with-apxs=/usr/apache2/bin/apxs
## Platform. ##
hostname = Solaris
uname -m = i86pc
uname -r = 5.10
uname -s = SunOS
uname -v = Generic_118844-26
/usr/bin/uname -p = i386
/bin/uname -X = System = SunOS
Node = Solaris
Release = 5.10
KernelID = Generic_118844-26
Machine = i86pc
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 1
/bin/arch = i86pc
/usr/bin/arch -k = i86pc
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/openwin/bin
PATH: /usr/ucb
## Core tests. ##
configure:1546: checking build system type
configure:1564: result: i386-pc-solaris2.10
configure:1572: checking host system type
configure:1586: result: i386-pc-solaris2.10
configure:1594: checking target system type
configure:1608: result: i386-pc-solaris2.10
configure:1640: checking for a BSD-compatible install
configure:1695: result: scripts/build/unix/install-sh -c
configure:1706: checking whether build environment is sane
configure:1749: result: yes
configure:1814: checking for gawk
configure:1843: result: no
configure:1814: checking for mawk
configure:1843: result: no
configure:1814: checking for nawk
configure:1830: found /usr/bin/nawk
configure:1840: result: nawk
configure:1850: checking whether make sets $(MAKE)
configure:1874: result: no
configure:2085: checking for gcc
configure:2114: result: no
configure:2165: checking for cc
configure:2181: found /usr/ucb/cc
configure:2191: result: cc
configure:2355: checking for C compiler version
configure:2358: cc --version </dev/null >&5
/usr/ucb/cc: language optional software package not installed
configure:2361: $? = 1
configure:2363: cc -v </dev/null >&5
/usr/ucb/cc: language optional software package not installed
configure:2366: $? = 1
configure:2368: cc -V </dev/null >&5
/usr/ucb/cc: language optional software package not installed
configure:2371: $? = 1
configure:2394: checking for C compiler default output file name
configure:2397: cc conftest.c >&5
/usr/ucb/cc: language optional software package not installed
configure:2400: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "mod_jk"
| #define VERSION "1.2.21"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2439: error: C compiler cannot create executables
See `config.log' for more details.
## Cache variables. ##
ac_cv_build=i386-pc-solaris2.10
ac_cv_build_alias=i386-pc-solaris2.10
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXCPP_set=
ac_cv_env_CXXCPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_F77_set=
ac_cv_env_F77_value=
ac_cv_env_FFLAGS_set=
ac_cv_env_FFLAGS_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=i386-pc-solaris2.10
ac_cv_host_alias=i386-pc-solaris2.10
ac_cv_prog_AWK=nawk
ac_cv_prog_ac_ct_CC=cc
ac_cv_prog_make_make_set=no
ac_cv_target=i386-pc-solaris2.10
ac_cv_target_alias=i386-pc-solaris2.10
## Output variables. ##
ACLOCAL='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run aclocal-1.9'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run tar'
APACHE20_OEXT=''
APACHE_CONFIG_VARS=''
APACHE_DIR=''
APXS=''
APXSCFLAGS=''
APXSCPPFLAGS=''
APXSLDFLAGS=''
AR=''
AUTOCONF='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run autoconf'
AUTOHEADER='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run autoheader'
AUTOMAKE='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run automake-1.9'
AWK='nawk'
CC='cc'
CCDEPMODE=''
CFLAGS=''
CP=''
CPP=''
CPPFLAGS=''
CXX=''
CXXCPP=''
CXXDEPMODE=''
CXXFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
ECHO='echo'
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
F77=''
FFLAGS=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s'
INSTALL_TYPE=''
JAVA_HOME=''
JK_JNI_WORKER=''
LDFLAGS=''
LIBOBJS=''
LIBS=''
LIBTOOL=''
LIB_JK_TYPE=''
LN_S=''
LTLIBOBJS=''
MAKEINFO='${SHELL} /export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/missing --run makeinfo'
MAKE_DYNAMIC_APACHE_FALSE=''
MAKE_DYNAMIC_APACHE_TRUE=''
MKDIR=''
OBJEXT=''
OS=''
PACKAGE='mod_jk'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
PERL=''
RANLIB=''
RM=''
SED=''
SET_MAKE='MAKE=make'
SHELL='/bin/bash'
STRIP=''
TEST=''
VERSION='1.2.21'
WEBSERVER=''
ac_ct_AR=''
ac_ct_CC='cc'
ac_ct_CXX=''
ac_ct_F77=''
ac_ct_RANLIB=''
ac_ct_STRIP=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__fastdepCXX_FALSE=''
am__fastdepCXX_TRUE=''
am__include=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
apache_include=''
bindir='${exec_prefix}/bin'
build='i386-pc-solaris2.10'
build_alias=''
build_cpu='i386'
build_os='solaris2.10'
build_vendor='pc'
datadir='${prefix}/share'
exec_prefix='NONE'
host='i386-pc-solaris2.10'
host_alias=''
host_cpu='i386'
host_os='solaris2.10'
host_vendor='pc'
includedir='${prefix}/include'
infodir='${prefix}/info'
install_sh='/export/home/dump_208/workspace_SB_563/modjk/ModJK1/modjk/jkk/tomcat-connectors-1.2.21-src/native/scripts/build/unix/install-sh'
int32_t_fmt=''
int32_value=''
int64_t_fmt=''
int64_value=''
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
mkdir_p='$(install_sh) -d'
oldincludedir='/usr/include'
prefix='NONE'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target='i386-pc-solaris2.10'
target_alias=''
target_cpu='i386'
target_os='solaris2.10'
target_vendor='pc'
uint32_t_fmt=''
uint32_t_hex_fmt=''
uint64_t_fmt=''
uint64_t_hex_fmt=''
## confdefs.h. ##
#define PACKAGE "mod_jk"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define VERSION "1.2.21"
configure: exit 77

You need to make sure the source is for the same version i.e. if you run apache 2.0.52 you need the source of 2.0.52. I successfully ran mixed installs, but I would not recommend it. You can download the required source from Apache.
As for your compiler problem, make sure you have �/usr/ccs/bin/� in the your path, if you do not have it installed you will have to add the pkg �SUNWsprot�. You do not have 'make' in yout path.
Make sure you have the following packages installed:
SUNWbtool, SUNWsprot, SUNWtoo
SUNWhea, SUNWarc, SUNWlibm, SUNWlibms
SUNWdfbh, SUNWcg6h, SUNWxwinc, SUNWolinc,
SUNWxglh,SUNWarcx, SUNWbtoox, SUNWdplx,
SUNWscpux, SUNWsprox, SUNWlmsx, SUNWlmx
SUNWlibCx, SUNWtoox, SUNWsra, SUNWsrh

Compilation problem with templates while using option -m64

Hi,
I have compilation problem with template while using option -m64.
No problem while using option -m32.
@ uname -a
SunOS snt5010 5.10 Generic_127111-11 sun4v sparc SUNW,SPARC-Enterprise-T5220
$ CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25
Here is some C++ program
############# foo5.cpp #############
template <typename T, T N, unsigned long S = sizeof(T) * 8>
struct static_number_of_ones
static const T m_value = static_number_of_ones<T, N, S - 1>::m_value >> 1;
static const unsigned long m_count = static_number_of_ones<T, N, S - 1>::m_count + (static_number_of_ones<T, N, S - 1>::m_value & 0x1);
template <typename T, T N>
struct static_number_of_ones<T, N, 0>
static const T m_value = N;
static const unsigned long m_count = 0;
template <typename T, T N>
struct static_is_power_of_2
static const bool m_result = (static_number_of_ones<T,N>::m_count == 1);
template <unsigned long N>
struct static_number_is_power_of_2
static const bool m_result = (static_number_of_ones<unsigned long, N>::m_count == 1);
int main(int argc)
int ret = 0;
if (argc > 1)
ret += static_is_power_of_2<unsigned short, 16>::m_result;
ret += static_is_power_of_2<unsigned int, 16>::m_result;
ret += static_is_power_of_2<unsigned long, 16>::m_result;
ret += static_number_is_power_of_2<16>::m_result;
else
ret += static_is_power_of_2<unsigned short, 17>::m_result;
ret += static_is_power_of_2<unsigned int, 17>::m_result;
ret += static_is_power_of_2<unsigned long, 17>::m_result;
ret += static_number_is_power_of_2<17>::m_result;
return ret;
Compiation:
@ CC -m32 foo5.cpp
// No problem
@ CC -m64 foo5.cpp
"foo5.cpp", line 20: Error: An integer constant expression is required here.
"foo5.cpp", line 36: Where: While specializing "static_is_power_of_2<unsigned long, 16>".
"foo5.cpp", line 36: Where: Specialized in non-template code.
"foo5.cpp", line 26: Error: An integer constant expression is required here.
"foo5.cpp", line 37: Where: While specializing "static_number_is_power_of_2<16>".
"foo5.cpp", line 37: Where: Specialized in non-template code.
"foo5.cpp", line 20: Error: An integer constant expression is required here.
"foo5.cpp", line 43: Where: While specializing "static_is_power_of_2<unsigned long, 17>".
"foo5.cpp", line 43: Where: Specialized in non-template code.
"foo5.cpp", line 26: Error: An integer constant expression is required here.
"foo5.cpp", line 44: Where: While specializing "static_number_is_power_of_2<17>".
"foo5.cpp", line 44: Where: Specialized in non-template code.
4 Error(s) detected.
Predefined macro:
@ CC -m32 -xdumpmacros=defs foo5.cpp | & tee log32
@ CC -m64 -xdumpmacros=defs foo5.cpp | & tee log64
@ diff log32 log64
7c7
< #define __TIME__ "09:24:58"
#define __TIME__ "09:25:38"20c20
< #define __sparcv8plus 1
#define __sparcv9 1[snipped]
=========================
What is wrong?
Thanks,
Alex Vinokur

Bug 6749491 has been filed for this problem. It will be visible at [http://bugs.sun.com] in a day or two.
If you have a service contract with Sun, you can ask to have this bug's priority raised, and get a pre-release version of a compiler patch that fixes the problem.
Otherwise, you can check for new patches from time to time at
[http://developers.sun.com/sunstudio/downloads/patches/]
and see whether this bug is listed as fixed.

Jaxb xjc compiler problem

Similar Messages

Maybe you are looking for