When I upgrade from ACS 5.2 to ACS 7.1, I got error message:
ERROR [web.context.ContextLoader] [main] Context initialization failed
org.alfresco.service.namespace.NamespaceException: Namespace prefix 'dc' is already in use for URI 'http://purl.org/dc/elements/1.1/' so cannot be registered for URI 'http://alfresco.parliament.ge/share'
I have used "dc" prefix for my namespace http://alfresco.parliament.ge/share in ACS 5.2 data
Please, can You help me
Thank You very much in advance
Best Regards
David Adamia
Ouch - you have a prefix name conflict with Alfresco's own namespace for dublin core, which is defined in iptcModel.
I'm afraid you won't be able to avoid refactoring your namespace.
It would be great if Alfresco / the community would have something like a model namespace prefix registry to avoid such a nameclash ...
Related
BotMan Version: 2.6
PHP Version: 8.1
Symfony Version : 5.4
Cache Driver: Symfony Cache
i'm using botman for telegram bot. everything is ok with botman just the conversation is not working
The question is asked, but when I answer, I see such an error.
An exception has been thrown during the rendering of a template ("Warning: is_file(): Unable to find the wrapper "closure" - did you forget to enable it when you configured PHP?").
Can someone help?
Tried to install php 8.2. Similarly
DriverManager::loadDriver(TelegramDriver::class);
$adapter = new FilesystemAdapter();
$botman = BotManFactory::create($this->config, new SymfonyCache($adapter));
I am a java EE developer, and I was trying to compile my project (which consists on three EAR projects: Service, Business and Web.
The EJB classes were in Business container. I then tried to compile using Maven 3.3.3, I also tried other versions like 3.5.3 (jboss-as-maven-plugin)
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.1.0.Final</version>
And I got this error:
RequestSendFailedException
org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
2018-04-10 11:47:59,530 INFO [org.jboss.ejb.client] (default task-6) JBoss EJB Client version 4.0.9.Final-redhat-1
2018-04-10 11:47:59,623 INFO [stdout] (default task-6) default task-6:2018-04-10 11:47:59,608 [ERROR] [web.mbean.MentoTOBean] [System error, try again!]
2018-04-10 11:47:59,624 INFO [stdout] (default task-6) org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
2018-04-10 11:47:59,624 INFO [stdout] (default task-6) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567)
2018-04-10 11:47:59,624 INFO [stdout] (default task-6) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
2018-04-10 11:47:59,624 INFO [stdout] (default task-6) at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
I tried everything so far, and I've found that, at least, the EJB is located somehow, but the 'Bean' is null:
WebEJBInterceptor: InterpcetorParameters [ type: interface web.service.MentoService, name: MentoService, serverName: MentoNegocio-server, authResolverClass:WebAuthenticationResolver]. Bean Scope: null
My service locator is okay, as it worked before:
<?xml version="1.0" encoding="UTF-8" ?>
<tpp:serviceLocator xmlns:tpp="http://www.mento.br/ns/javaee/ejb"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mento.br/ns/javaee/ejb serviceLocator.xsd">
<tpp:server name="SDC">
<tpp:initialContextFactory>org.jboss.as.naming.InitialContextFactory</tpp:initialContextFactory>
<tpp:providerUrl>remote://localhost:4447</dtp:providerUrl>
<tpp:user>xxxxxxxxxxx</tpp:user>
<tpp:password>xxxxxxxxx</tpp:password>
</tpp:server>
<tpp:service name="MentoNegocio-server" jndiPrefix="" jndiSuffix="">
<tpp:preserveInitialContext>true</tpp:preserveInitialContext>
</tpp:service>
</tpp:serviceLocator>
I used Jboss EAP 7.1 (It worked before in EAP 6.0 but the systems now use 7.0+ due to compatibility).
I faced the same issue in recent past and after so many analysis , I am able to find the resolution.
Here are details:
In EAP 7.1 Context Factory data is changed which was modified in
Provider URL :remote+http://:
JNDI ContextFactory: org.wildfly.naming.client.WildFlyInitialContextFactory
Change these two in the EJB Client and issue will be resolved.
Is it possible, that you used an outdated jboss-client-library on the client-side which is now causing the errors?
Possibly import from your jboss-server e.g.: /app/jboss/jboss-eap-7.1.4/bin/client/jboss-client.jar into your project.
I'm migrating symfony 2.6 app to the 3.0.4, I'm in a trouble with security.secure_random service, I was using it with dependency injection. Which is representing in security.xml
but I cannot see in 3.0.x I checked changelog every pixel of the project where it does go ? That I'm missing something ?
The class deprecated in 2.8 and removed in 3.0 in favour of the random_bytes function.
Essentialy the SecureRandomInterface had one nextBytes method, which behaves exactly as the PHP7 random_bytes function.
You can install https://github.com/paragonie/random_compat for forward compatibility
After installing Yosemite and a new version of MAMP
and when I'm trying to execute
domain/app_dev.php/es/venues/3/show
This route is rendering a form containing a language type field, so it's requiring ICU.
being 'es' the locale i get errors. If I changed it to 'en' there's no problem.
The errors are:
[1/2] ResourceBundleNotFoundException: The resource bundle
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/root.php"
does not exist.
[2/2] Couldn't read the indices [Languages] from
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/es.res".
The indices also couldn't be found in the fallback locale(s)
"root.res".
My symfony version is 2.5, I'm running the MAMP PHP 5.5.10.
I updated dependencies via composer, including "symfony/intl": "*",
I have followed several webs in order to install icu and intl via pecl. But still get the error. I don't know how to check if the installations or the configs are ok. Maybe you can let me know how to test both via terminal and let you know what is the result...
This is because you are trying to get resources only for language es. But now (from the moment of importing to Symfony icu data) you need to get language resources via language and country codes es_ES.
You may not be able to just simply activate intl.so after the Yosemite update. I solved the issue installing intl.so following an excellent article by Danilo Braband http://dab.io/posts/getting-started-with-symfony-on-yosemite.html
Solved updgrading to Symfony 2.5.6
I am trying to integrate some pre-existing code that relies on the
com.sun.crypto.provider.SunJCE class into our Equinox based
application (version 3.7.1). Now I know by default the com.sun
packages are not accessible to bundles, so I made a fragment with the
idea of extending the framework to export the package. Here is its
manifest:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Extension
Bundle-SymbolicName: extension
Bundle-Version: 1.0.0.qualifier
Fragment-Host: system.bundle; extension:=framework
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: com.sun.crypto.provider
Clue 1: The PDE marks the Export-Package line and says that
com.sun.crypto.provider does not exist in this plugin.
I created a sample bundle that just instantiates the class in question
in the bundle activator. That bundle's manifest is:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Cryptotest
Bundle-SymbolicName: cryptotest
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: cryptotest.Activator
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: com.sun.crypto.provider,
org.osgi.framework;version="1.3.0"
Clue 2: The PDE marks the instantiation with an access restriction.
Despite the two errors, the project does compile and I am able to
start debugging. When starting the sample bundle, I receive a class
not found exception. However, when I do a "packages 0" in the console, it appears
Equinox is claiming to export this package:
com.sun.crypto.provider;
version="0.0.0"<org.eclipse.osgi_3.7.1.R37x_v20110808-1106 [0]>
cryptotest_1.0.0.qualifier [2] imports
Now, I have found an ugly work around that appears to work in my minimal example. It is to basically wrap Java's jce provider jar in a separate plugin and include that with my application, but that just seems wrong.
Could somebody please provide some insight into what's going on? Is
there something obvious I am missing?
This looks like a package that is present in your JVM, but only when running on a Sun one. These are not exposed by the system bundle by default, because OSGi is not built solely for Sun VMs.
You can, however, instruct the framework to expose this package. To do so, you set the org.osgi.framework.system.packages.extra property to a list of packages, which includes your com.sun.crypto.provider package. There are several ways to do this, but you could, for instance start Equinox with a system property,
-Dorg.osgi.framework.system.packages.extra=com.sun.crypto.provider
By the way, this is not Equinox-specific, but a standard OSGi-construct.