When I deploy Solr 3.1 to Jboss application server (version 6.0 final) I got the following exception message:
Failed to create Resource solr.war - cause: java.lang.Exception:Failed to start deployment [vfs:///D:/jboss-6.0.0.Final/server/default/deploy/solr.war] during deployment of 'solr.war' - cause: java.lang.RuntimeException:org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): * DEPLOYMENTS IN ERROR: Name -> Error vfs:///D:/jboss-6.0.0.Final/server/default/deploy/solr.war -> org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfs:///D:/jboss-6.0.0.Final/server/default/deploy/solr.war DEPLOYMENTS IN ERROR: Deployment "vfs:///D:/jboss-6.0.0.Final/server/default/deploy/solr.war" is in error due to the following reason(s): org.xml.sax.SAXException: Element type "tlibversion" must be declared. # vfs:///D:/jboss-6.0.0.Final/server/default/deploy/solr.war/WEB-INF/lib/velocity-tools-2.0-beta3.jar/META-INF/velocity-view.tld[22,16] ->
I wonder why this error occurred.
I tried to deploy both Solr version 1.4 and 4.0 to the same server and no error was found.
(My deploy method: Use JBoss AS 6 Admin Console and Add "solr.war" as a new resource for standalone web application)
Thank you for attention and any help is regarded.
me again :) .... good news I fixed it I just edited this file: solr.war\WEB-INF\lib\velocity-tools-2.0-beta3.jar\META-INF\velocity-view.tld
to this (you copy and paste it as is):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN" "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<taglib>
<tlib-version>1.0</tlib-version>
<jsp-version>1.2</jsp-version>
<short-name>velocity</short-name>
<uri>http://velocity.apache.org/velocity-view</uri>
<display-name>VelocityView Tag</display-name>
<description><![CDATA[Support for using Velocity and VelocityTools within JSP files and tags.
This makes it trivial to render VTL (Velocity Template Language)
or process a Velocity template from within JSP using the current
context. This also provides the typical VelocityView support
for accessing and configuring both custom and provided
VelocityTools.]]></description>
<tag>
<name>view</name>
<tag-class>org.apache.velocity.tools.view.jsp.VelocityViewTag</tag-class>
<body-content>tagdependent</body-content>
<attribute>
<name>id</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<description><![CDATA[A id unique to this usage of the VelocityViewTag. This id is used to uniquely identify this tag in log messages and hopefully at some point serve as a key under which any body for this tag may be cached as an already-parsed template for improved performance. If no id is specified, then a unique is automatically generated, though that will understandably be less useful in log messages.]]></description>
</attribute>
<attribute>
<name>var</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<description><![CDATA[A variable name whose value should be set to the rendered result of this tag.]]></description>
</attribute>
<attribute>
<name>scope</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<description><![CDATA[This property is meaningless unless a 'var' attribute is also set. When it is, this determines the scope into which the resulting variable is set.]]></description>
</attribute>
<attribute>
<name>template</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<description><![CDATA[The name of a template to be requested from the configured Velocity resource loaders and rendered into the page (or variable if the 'var' attribute is set) using the current context. If this tag also has body content, then the body will be rendered first and placed into the context used to render the template as '$bodyContent'; this approximates the "two-pass render" used by the VelocityLayoutServlet.]]></description>
</attribute>
<attribute>
<name>bodyContentKey</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<description><![CDATA[This property is meaningless unless a 'template' attribute is set and the tag has body content in it. When it is, this changes the key under which the rendered result of the body content is placed into the context for use by the specified template. The default value is "bodyContent" and should be sufficient for nearly all users.]]></description>
</attribute>
</tag>
</taglib>
Related
I am getting the following warning message while I tried to import XML file in Informatica repository.
Warning: Unexpected condition at: Wcursor.cpp: 305
Contact Informatica technical support for assistance
Continuing may result in damage to your repository.
The XML file is around 70mb and has got around 4500 objects in it. I am migrating an entire application from one server to another.
Not sure why this issue happens. I tried several times and from other client system as well, but no luck.
For importing the XML via command line using "pmrep" command, we need control file. But I dont have any control file for this XML. So cant go with that option.
It would be great if somebody can help me sort out this issue.
Details:
Infa version 9.1
Mounted on Unix environment.
Had the same problem back some time ago. XML parsing takes a lot of memory and / or GUI can't handle it. My solution was to use pmrep command line tool. Worked for me - my workflow was composed of around 3600 objects afair.
If you don't have a control file - create one! Here's a very simple template:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IMPORTPARAMS SYSTEM "impcntl.dtd">
<!--IMPORTPARAMS This inputs the options and inputs required for import operation -->
<!--CHECKIN_AFTER_IMPORT Check in objects on successful import operation -->
<!--CHECKIN_COMMENTS Check in comments -->
<!--APPLY_LABEL_NAME Apply the given label name on imported objects -->
<!--RETAIN_GENERATED_VALUE Retain existing sequence generator, normalizer and XML DSQ current values in the destination -->
<!--COPY_SAP_PROGRAM Copy SAP program information into the target repository -->
<!--APPLY_DEFAULT_CONNECTION Apply the default connection when a connection used by a session does not exist in the target repository -->
<IMPORTPARAMS CHECKIN_AFTER_IMPORT="YES" CHECKIN_COMMENTS="PMREP_IMPORT_TEST" RETAIN_GENERATED_VALUE="NO" COPY_SAP_PROGRAM="NO" APPLY_DEFAULT_CONNECTION="NO">
<!--FOLDERMAP matches the folders in the imported file with the folders in the target repository -->
<FOLDERMAP SOURCEFOLDERNAME="YOUR FIRST SOURCE FOLDER NAME" SOURCEREPOSITORYNAME="REP_DEV" TARGETFOLDERNAME="YOUR FIRST SOURCE FOLDER NAME" TARGETREPOSITORYNAME="REP_TEST"/>
<FOLDERMAP SOURCEFOLDERNAME="YOUR SECOND TARGET FOLDER NAME" SOURCEREPOSITORYNAME="REP_DEV" TARGETFOLDERNAME="YOUR SECOND TARGET FOLDER NAME" TARGETREPOSITORYNAME="REP_TEST"/>
<!--Import will only import the objects in the selected types in TYPEFILTER node -->
<!--TYPENAME type name to import. This should comforming to the element name in powermart.dtd, e.g. SOURCE, TARGET and etc.-->
<!--RESOLVECONFLICT allows to specify resolution for conflicting objects during import. The combination of specified child nodes can be supplied -->
<RESOLVECONFLICT>
<!--TYPEOBJECT allows objects of certain type to apply replace/reuse upon conflict-->
<!--TYPEOBJECT = ALL conflict resolution for ALL types of objects -->
<TYPEOBJECT OBJECTTYPENAME="ALL" RESOLUTION="REPLACE"/>
<!--SPECIFICOBJECT allows a particular object(name, typename etc.) to apply replace/reuse upon conflict -->
<!--NAME Object name-->
<!--EXTRANAME Source DBD name - required for source object to identify uniquely-->
<!--OBJECTTYPENAME Object type name-->
<!--FOLDERNAME Folder which the object belongs to-->
<!--REPOSITORYNAME Repository name that this object belongs to-->
<!--RESOLUTION Resolution to apply for the object in case of conflict-->
<!--SPECIFICOBJECT NAME="your_object" OBJECTTYPENAME="your_object_type" FOLDERNAME="your_source_folder" REPOSITORYNAME="your_source_repo" RESOLUTION="REPLACE"/-->
</RESOLVECONFLICT>
</IMPORTPARAMS>
I am stuck. I have spent nearly a day to solve but to no avail.
PROBLEM: Connecting to production database using entity framework.
I connect fine on development.
<add name="DefaultConnectionString" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=MONDO;Integrated Security=True" providerName="System.Data.SqlClient" />
<add name="MONDOEntities" connectionString="metadata=res://*;provider=System.Data.SqlClient;provider connection string="Data Source=.\SQLEXPRESS;Initial Catalog=MONDO;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
Moving to production, I used (from the production web.config file) the existing "DefaultConnectionString" parameters (ID and Password) to edit the MONDOEntities connectionString. (can I do this?) Also, I expanded the metadata in MONDOEntities to include .csdl, .ssdl, .msl and I prefixed it with (guessing, again, can I do this?) MONDO. Bold parts are changes from dev web.config to production web.config. *Note, the connectionStrings below were not created by Visual Studio, I just changed some info myself to try and make it work on the production side.
<add connectionString="Data Source=MPOC\SQLEXPRESS;Database=Mondo;User ID=xxx;Password=xxxxx;" name="DefaultConnectionString" />
<add name="MONDOEntities" connectionString="metadata=res://*/MONDO.csdl|res://*/MONDO.ssdl|res://*/MONDO.msl;provider=System.Data.SqlClient;provider connection string="Data Source=MPOC\SQLEXPRESS;persist security info=True;Database=Mondo;User ID=xxx;Password=xxxxx;MultipleActiveResultSets=Tru e;App=EntityFramework"" providerName="System.Data.EntityClient" />
The error message I get is:
Unable to load the specified metadata resource.
Line 62: /// Initializes a new MONDOEntities object using the connection string found in the 'MONDOEntities' section of the application configuration file.
Line 63: /// </summary>
Line 64: public MONDOEntities() :
QUESTION: Can I simply modify the connectionStrings manually or does it need to run through a compilation process? It is a website project so it compiles, on the fly, the first time after I upload to production. It does not get precompiled on my local dev computer. I guess, bottom line, how do I set up a proper connectionString for an entity connection for a database in production?
I'm on a project where I need to learn an existing website. I'm making my first bug fix and having learned ado.net, I created an entity data model and made some code changes. Everything works smooth in development.
I move the files to production and then I get this error:
"The specified default EntityContainer name 'MONDOEntities' could not be found in the mapping and metadata information.
Parameter name: defaultContainerName"
I googled this error message and based on some findings, I expanded my "metadata" shown below. This was more of a shot in dark for me:
ORIGINAL (auto generated in web.config when I created the entity data model):
connectionString="metadata=res://*
NEW (I edited/added this):
connectionString="metadata=res://*/MONDO.csdl|res://*/MONDO.ssdl|res://*/MONDO.msl;
This seemed to get past the first error and I get to a new error message (as posted in OP):
Unable to load the specified metadata resource.
Line 62: /// Initializes a new MONDOEntities object using the connection string found in the 'MONDOEntities' section of the application configuration file.
Line 63: /// </summary>
Line 64: public MONDOEntities() :
I think that there is a problem with my metadata information. However, given that the original, auto generated connectString only contains "metadata=res://*", I really don't know how to go about correcting this. Actually, I'm not even super sure that this is the root of the problem.
Bottom line, my entity model works smooth in dev but isn't connecting in production. Any thoughts are appreciated ... thanks.
The connection string has nothing to do with compilation, as long as you didn't define some transformation to be performed on it or you have some custom hooks that operate on it.
So yeah, you can modify it by hand.
You probably got those metadata wrong, try and play with them (EG removing the prefix).
Also are you absolutely sure that, in your production environment, the right connectionString is being loaded and used by the MONDOEntities?
I am getting the following warning in my code:
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php/./views/helpers/Doctype.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
or
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php//var/www/virtual/example.com/htdocs/rockhopper-v2/application/modules/default/views/helpers/Layout.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
what is the problem and will it cause problems in deployment and production stage of my application?
Thank you
This message appears because since Zend FW 1.10.1 the autoloader creates the path to those files differently. You can find some more information here: Zend FW Bug Report
To get rid of this message you can edit the file index.php and change the set_include_path to this:
set_include_path(
APPLICATION_PATH.'/../library'.PATH_SEPARATOR.
APPLICATION_PATH.'/../library/Zend'
);
open_basedir is set php is running in safe mode. It restricts you to the folders specified in the list. This might help: http://blog.php-security.org/archives/72-Open_basedir-confusion.html
And yes, you will need to change it on any server if you want to access files outside the default folder.
I hant to be able to call DatabaseFactory.CreateDatabase(), i.e. with no parameter to indicate which connection string to pull from my config file. I only have one connection string in my config file. The only help I have found on the internet is instructions to indicate the default connection string using the Enterprise Library Configuration tool (by right-clicking on my config file in Visual Studio). But from there, I see no way to "select" a connection string or mark it to be the default.
YOu should define the dataConfiguration section in your config
<configuration>
<configSections>
<section name="dataConfiguration" ...
And then set the value
<dataConfiguration defaultDatabase="ConnectionStringName" />
Our application provides a SOAP API. Our wsdl starting lines are something like
<wsdl:definitions name='ControlDServices' ... xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' ...
This usually works OK, but a customer complained that when they try to use our SOAP API in NetBeans with the wsdl we provide they got this error:
Web Service can not be created by JAXWS:wsimport utility.
Reason: invalid extension element: "soap:body" (in namespace "http://schemas.xmlsoap.org/wsdl/soap/")
This can be easily recreated by running:
wsimport -d . -extension -Xnocompile -keep -s . -verbose <our wsdl file>
wihch yield the error:
[ERROR] invalid extension element: "soap:body" (in namespace "http://schemas.xmlsoap.org/wsdl/soap/")
unknown location
Our support discovered that changing the xmlns:soap definition to use http://www.w3.org/2001/12/soap-envelope/ solves the problem, but this requires a change in our product, and also contradict most of the places I see on the web where a wsdl:definitions file is defined. Besides, that URI seems to belong to soap-envelop and not to wsdl, and is also for a specific date, and not a general URI.
Is there a way to solve the NetBeans / wsimport problem without changing our wsdl, e.g. by changing parameters? If no, and a change is needed, is it wise to change it to http://www.w3.org/2001/12/soap-envelope/, or should we use something else?
Thanks
splintor
It looks like they don't support SOAP 1.1, only SOAP 1.2.