Home » Archived » SeMantic Information Logistics Architecture (SMILA) » New SMILA tryout
New SMILA tryout [message #660478] |
Fri, 18 March 2011 15:11 |
Martin Röbert Messages: 16 Registered: December 2010 Location: Leipzig, Germany |
Junior Member |
|
|
Hi there,
I just wanted to try out the all new SMILA from trunk.
I ran into several problems:
- SMILA is not able to find javax.servlet and javax.servlet.http
- If I run it though, I get a java.lang.ExceptionInInitializerError caused by commons logging (stacktrace below)
Anybody a hint on that?
Cheers,
Martin
java.lang.ExceptionInInitializerError
at org.eclipse.smila.management.jmx.client.cmd.task.impl.OperationTask.execute(OperationTask.java:70)
at org.eclipse.smila.management.jmx.client.cmd.task.impl.OperationTask.execute(OperationTask.java:1)
at org.eclipse.smila.management.jmx.client.cmd.CmdConsoleImpl.execute(CmdConsoleImpl.java:89)
at org.eclipse.smila.management.jmx.client.cmd.CmdConsoleImpl.execute(CmdConsoleImpl.java:71)
at org.eclipse.smila.management.jmx.client.osgi.SMILACommandProvider._smila(SMILACommandProvider.java:100)
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:597)
at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:156)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.runConsole(FrameworkConsole.java:141)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:105)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable.
at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:874)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:310)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
at org.apache.commons.beanutils.ConvertUtilsBean.<init>(ConvertUtilsBean.java:157)
at org.apache.commons.beanutils.BeanUtilsBean.<init>(BeanUtilsBean.java:117)
at org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68)
at org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153)
at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80)
at org.apache.commons.beanutils.ConvertUtilsBean.getInstance(ConvertUtilsBean.java:142)
at org.apache.commons.beanutils.ConvertUtils.register(ConvertUtils.java:356)
at org.eclipse.smila.management.jmx.client.helpers.ConversionHelper.<clinit>(ConversionHelper.java:21)
... 14 more
Nested Exception:
org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable.
at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:874)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:310)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
at org.apache.commons.beanutils.ConvertUtilsBean.<init>(ConvertUtilsBean.java:157)
at org.apache.commons.beanutils.BeanUtilsBean.<init>(BeanUtilsBean.java:117)
at org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68)
at org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153)
at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80)
at org.apache.commons.beanutils.ConvertUtilsBean.getInstance(ConvertUtilsBean.java:142)
at org.apache.commons.beanutils.ConvertUtils.register(ConvertUtils.java:356)
at org.eclipse.smila.management.jmx.client.helpers.ConversionHelper.<clinit>(ConversionHelper.java:21)
at org.eclipse.smila.management.jmx.client.cmd.task.impl.OperationTask.execute(OperationTask.java:70)
at org.eclipse.smila.management.jmx.client.cmd.task.impl.OperationTask.execute(OperationTask.java:1)
at org.eclipse.smila.management.jmx.client.cmd.CmdConsoleImpl.execute(CmdConsoleImpl.java:89)
at org.eclipse.smila.management.jmx.client.cmd.CmdConsoleImpl.execute(CmdConsoleImpl.java:71)
at org.eclipse.smila.management.jmx.client.osgi.SMILACommandProvider._smila(SMILACommandProvider.java:100)
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:597)
at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:156)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.runConsole(FrameworkConsole.java:141)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:105)
at java.lang.Thread.run(Thread.java:662)
Nested Exception:
org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable.
at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:874)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:310)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
at org.apache.commons.beanutils.ConvertUtilsBean.<init>(ConvertUtilsBean.java:157)
at org.apache.commons.beanutils.BeanUtilsBean.<init>(BeanUtilsBean.java:117)
at org.apache.commons.beanutils.BeanUtilsBean$1.initialValue(BeanUtilsBean.java:68)
at org.apache.commons.beanutils.ContextClassLoaderLocal.get(ContextClassLoaderLocal.java:153)
at org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:80)
at org.apache.commons.beanutils.ConvertUtilsBean.getInstance(ConvertUtilsBean.java:142)
at org.apache.commons.beanutils.ConvertUtils.register(ConvertUtils.java:356)
at org.eclipse.smila.management.jmx.client.helpers.ConversionHelper.<clinit>(ConversionHelper.java:21)
at org.eclipse.smila.management.jmx.client.cmd.task.impl.OperationTask.execute(OperationTask.java:70)
at org.eclipse.smila.management.jmx.client.cmd.task.impl.OperationTask.execute(OperationTask.java:1)
at org.eclipse.smila.management.jmx.client.cmd.CmdConsoleImpl.execute(CmdConsoleImpl.java:89)
at org.eclipse.smila.management.jmx.client.cmd.CmdConsoleImpl.execute(CmdConsoleImpl.java:71)
at org.eclipse.smila.management.jmx.client.osgi.SMILACommandProvider._smila(SMILACommandProvider.java:100)
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:597)
at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:156)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.runConsole(FrameworkConsole.java:141)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:105)
at java.lang.Thread.run(Thread.java:662)
[Updated on: Fri, 18 March 2011 21:23] Report message to a moderator
|
|
| | |
Re: New SMILA tryout [message #660692 is a reply to message #660529] |
Mon, 21 March 2011 08:29 |
Eclipse User |
|
|
|
Originally posted by: juergen.schumacher.attensity.com
Hi Martin,
Am 18.03.2011, 22:34 Uhr, schrieb Martin R=C3=B6bert <martin.roebert@gmx=
..de>:
> Hi Igor, first of all, I used rev 1016 from trunk for testing.
>
> I've done all standard steps as we do when creating a new =
> SMILA-workspace (and as described on the SMILA website - dont know the=
=
> exact name right now):
>
>
> check out from eclipse SVN
> add a new Target Platform with path to the SMILA bundles and to eclip=
se =
> itself
> launched the SMILA.launch file, stopped it immediately and edited all=
=
> conflicts in the launch configuration pane
>
> Hope this helps for clearance :)
> Martin
Not really, this should work (:
The javax.servlet packages should be part of the Eclipse and it has been=
at least since Eclipse 3.5.
One idea: I often have problems, when I use the IDE-Eclipse itself as th=
e
base for the target platform, because depending on the edition and the =
plugins
installed additionally it contains often bundles that produe conflicts. =
So =
I
always use a plain Eclipse SDK installation like the one used for the =
SMILA build
(see =
http://wiki.eclipse.org/SMILA/Development_Guidelines/Howto_b uild_a_SMILA=
-Distribution#Build_Requirements)
as the base for the target platform. I don't use this Eclipse for anythi=
ng =
else,
never start it, do not put additional stuff in (apart from the Delta Pac=
k).
From my experience this works better. Can you try this?
One other thing: If the JUnit tests don't run inside Eclipse, you often =
=
have to deactivate
org.junit (version 4....) bundles in the target platform.
Cheers,
J=C3=BCrgen.
|
|
| | | |
Re: New SMILA tryout [message #660875 is a reply to message #660478] |
Tue, 22 March 2011 08:30 |
Martin Röbert Messages: 16 Registered: December 2010 Location: Leipzig, Germany |
Junior Member |
|
|
Hi,
I'll try this.
But is it possible to ship javax.servlet in SMILA.application as done with other javax stuff? Or in other words: why are some javax-packages included in SMILA and the servlet-API isn't?
And as I checked another workspace: I guess the servlet-api was once bundled with SMILA (checked rev. 659)?
Cheers,
Martin
[Updated on: Tue, 22 March 2011 08:33] Report message to a moderator
|
|
|
Re: New SMILA tryout [message #660901 is a reply to message #660875] |
Tue, 22 March 2011 09:46 |
Eclipse User |
|
|
|
Originally posted by: juergen.schumacher.attensity.com
Am 22.03.2011, 09:30 Uhr, schrieb Martin R=C3=B6bert <martin.roebert@gmx=
..de>:
> Hi,
>
> I'll try this.
>
> But is it possible to ship javax.servlet in SMILA.application as done =
=
> with other javax stuff? Or in other words: why are some javax-packages=
=
> included in SMILA and the servlet-API isn't?
>
> Cheers,
> Martin
It's not shipped because it's supposed to be part of the recommended =
Eclipse
target platform. We also don't ship Equinox or the Declarative Services =
=
runtime,
for example. We might run into version conflicts, if bundles from the =
target
platform are duplicated in SMILA.
I think I'll change the documentation later to not use the IDE itself as=
=
the
base for the target platform. It works better anyway.
Cheers,
J=C3=BCrgen.
|
|
|
Re: New SMILA tryout [message #661166 is a reply to message #660901] |
Wed, 23 March 2011 11:59 |
thomas menzel Messages: 81 Registered: July 2009 |
Member |
|
|
hi martin,
to elaborate on the given replies:
- the eclipse 3.5 SDK + delta is the normative target platform for smila
as written on our wiki.
- other eclipse versions might work, but this is not granted/supported
- in the meantime we also provide a .target @
/SMILA.releng/devenv/SMILA.target. Open that and set it as your target
platform (but click that link on the page only *after* it finished the
background task of "resolving the target platform", i.e. downloading the
bundles from eclips's p2 repo ).
note:
when we build smila based on that target platform, then only those
bundles that are actually needed for smila to run on its own are copied
into smila's bundles folder by the PDE build.
hence,
a) we only add those bundles to the smila.extensions that are not part
of the eclipse sdk 3.5.
b) the built smila doesnt contain bundles not used, such as all the jdt
stuff contained in eclipse 3.5. it even doesn't contain those bundles
that are needed to run the test during the build.
theoretically we could have assembled a target platform from scratch.
that would have been quite a bit of work, which we didnt want to spent
our weekends on ;)
On 22.03.2011 10:46, Jürgen Schumacher wrote:
> Am 22.03.2011, 09:30 Uhr, schrieb Martin Röbert <martin.roebert@gmx.de>:
>
>> Hi,
>>
>> I'll try this.
>>
>> But is it possible to ship javax.servlet in SMILA.application as done
>> with other javax stuff? Or in other words: why are some javax-packages
>> included in SMILA and the servlet-API isn't?
>>
>> Cheers,
>> Martin
>
> It's not shipped because it's supposed to be part of the recommended
> Eclipse
> target platform. We also don't ship Equinox or the Declarative Services
> runtime,
> for example. We might run into version conflicts, if bundles from the
> target
> platform are duplicated in SMILA.
>
> I think I'll change the documentation later to not use the IDE itself as
> the
> base for the target platform. It works better anyway.
>
> Cheers,
> Jürgen.
--
thomas menzel aka tom
thomas menzel aka tom
|
|
|
Goto Forum:
Current Time: Mon Sep 23 15:48:45 GMT 2024
Powered by FUDForum. Page generated in 0.06005 seconds
|