Hi Bengt,
I ran the test and find the OsgiClassResolver is using the bundle of you
camel application to load the class. So you need to add the import
package of "org.apache.camel.component.file.strategy" into your camel
application bundle.
Willem
Bengt Rodehav wrote:
Willem,
I've tried to modify spring-osgi to make it possible to import
the org.apache.camel.component.file.strategy package from camel-core but I
haven't succeeded. I've used explicit import as well as dynamic. When I use
explicit import I can see (via the webconsole) that spring-osgi does indeed
import the org.apache.camel.component.file.strategy package from camel-core.
But it still cannot resolve
the org.apache.camel.component.file.strategy.GenericFileProcessStrategyFactory
class.
Running out of ideas....
/Bengt
2010/6/11 Bengt Rodehav <be...@rodehav.com>
Willem,
I've done some more digging in order to understand what is happening.
Apparently spring-osgi embeds the OsgiClassResolver class (it is specified
as a Private-Package). The class that the resolver is trying to resolve is:
org.apache.camel.component.file.strategy.GenericFileProcessStrategyFactory
The package org.apache.camel.component.file.strategy is exported from
camel-core but it is not imported into spring-osgi which must be the reason
why it cannot be resolved.
If the resolver resides in spring-osgi (which it does) then it must import
all packages that it can potentially be requested to resolve. I guess one
way of doing that would be via Dynamic-Import.
Will you take a look at this?
/Bengt
2010/6/11 Bengt Rodehav <be...@rodehav.com>
Hello again Willem!
Maybe we should switch thread since this presently has nothing to do with
ftps...
Anyway, it's going to be pretty hard for me to extract a small test case.
Not sure I will be enable to do it. Just out of curiosity, did you also try
a "ftps:" endpoint?
Also, I've been doing some System.out debugging. I've found out the
following:
The resolver that is being used is an instance of
the org.apache.camel.core.osgi.OsgiClassResolver class. When I search
through the Camel source code I only find this class in one place - in the
camel-core-osgi component. To my knowledge I don't use that component and I
have no idea how that class can be instantiated in run-time.
Any thoughts on this? Is this the correct resolver to use? How is
camel-core supposed to find that class? How does it work?
/Bengt
2010/6/10 Willem Jiang <willem.ji...@gmail.com>
Hi Bengt,
I just tried to use some file endpoint inside our camel OSGi test
platform, the route is started without any issue.
Can you create a small test case which is based on you application and
submit it into a JIRA ?
In this way I can keep on digging the issue :)
Willem
Bengt Rodehav wrote:
I now get the following exception:
java.lang.TypeNotPresentException: Type
org.apache.camel.component.file.strategy.GenericFileProcessStrategyFactory
class not found not present
at
org.apache.camel.component.file.GenericFileEndpoint.createGenericFileStrategy(GenericFileEndpoint.java:145)
at
org.apache.camel.component.file.GenericFileEndpoint.getGenericFileProcessStrategy(GenericFileEndpoint.java:118)
at
org.apache.camel.component.file.GenericFileConsumer.doStart(GenericFileConsumer.java:397)
at
org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:56)
at
org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:53)
at
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1015)
...
This is incredibly strange to me. It seems like the caller (line 145 in
class GenericFileEndpoint) cannot find the class
GenericFileProcessStrategyFactory. They both reside in camel-core so
there
can be no problem in finding the class. However it is not exactly trying
to
find it but to "resolve" it. The following call throws the exception:
factory =
this.getCamelContext().getClassResolver().resolveClass(DEFAULT_STRATEGYFACTORY_CLASS);
Any ideas?
/Bengt
2010/6/10 Bengt Rodehav <be...@rodehav.com>
Willem,
I'm just now building a new trunk version of Camel and need to verify
with
you that I'm using Camel properly in an OSGi environment:
- I only install the features "camel" (includes camel-core and
camel-spring
bundles) + camel-ftp (that I wish to test)
Do I need camel-spring if I'm not using Spring directly? I create all
my
routes in Java DSL.
- I noticed that there is a component called camel-core-osgi. Should I
use
it in any way? How?
Just out of curiosity. What was the typo you mentioned?
/Bengt
2010/6/10 Willem Jiang <willem.ji...@gmail.com>
Hi Bengt,
It's a typo, I just fixed it with an OSGi unit test.
Please check out the last camel trunk code to keep on riding with
Camel :)
Willem
Bengt Rodehav wrote:
Thanks Willem - what a relief...
I eagerly await the results from your digging,
/Bengt
2010/6/10 Willem Jiang <willem.ji...@gmail.com>
I can reproduce the error that you met, there must be something
wrong
with
current OSGi refactoring,
I will keep digging to see if I can fix this issue soon.
Willem
Bengt Rodehav wrote:
Thanks for your reply Willem,
I've tried various combinations of camel features. Right now I use
the
"camel" feature (plus camel-ftp since that's what I'm trying to
test).
In
runtime I can see the camel-core, camel-spring and the camel-ftp
bundles
installed and active. I manage to create an OsgiDefaultCamelContext
the
following way:
mCamelContextFactory = new CamelContextFactory();
mCamelContextFactory.setBundleContext(theBundleContext);
mCamelContext = mCamelContextFactory.createContext();
However, when I try to start the camel context I get the exception
I
mentioned above:
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed
to
resolve endpoint:
file://data/connect/test/sample/file2ftps?delay=1000&move=archive%2F%24%
7Bdate%3Anow%3AyyyyMMdd%7D%2F%24%7Bfile%3Aname%7D&moveFailed=failed%2F%24%7Bfile%3Aname.noext%7D-%24%7Bdate%3Anow%3AyyyyMMddHHmmssSSS%7D.%24%7Bfile%3Aext%7D
due to: No language could be found for: file
at
org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:377)
To me it sounds like the languages has not been registered
properly.
Looking
through the code it looks like the OSGi "registration" part of
camel
has
moved from camel-osgi to camel-core. Which I guess means that I
should
not
be using camel-osgi anymore (just camel-core in combination with
camel-spring). This is what I'm doing, but I still get the above
exception.
Could it be a problem with iPojo? I use iPOJO to create my OSGi
services
from configurations handled by file install. I noticed that the
BundleContext I'm using is really an instance
of org.apache.felix.ipojo.IPojoContext.
Any clues?
/Bengt
2010/6/10 Willem Jiang <willem.ji...@gmail.com>
Hi Bengt,
Did you use the apache camel feature of the Camel 2.4-SNAPSHOT ?
If so, you just need to install the feature of camel, it includes
the
camel-core feature and camel-spring feature.
And you can still use org.apache.camel.osgi.CamelContextFactory to
create
the camel context :)
Willem
Bengt Rodehav wrote:
Claus,
I have now managed to build Camel version 2.4-SNAPSHOT. However,
I
can't
get
my application to work on that version. I'm using Karaf 1.6.0 for
deployment
and something has definitely changed in Camel regarding OSGi. I
haven't
figured out how to use Camel 2.4-SNAPSHOT in Karaf yet. Maybe you
(or
someone else reading this) can help out?
When using Camel 2.3, I create my camel context using
the org.apache.camel.osgi.CamelContextFactory class. In runtime,
this
class
is imported from the camel-spring-osgi bundle. The activator for
this
bundle
(org.apache.camel.osgi.Activator) seems to reside in the
camel-osgi
bundle
but that bundle also seems to be embedded in camel-spring-osgi.
Have
to
admit that this solution is far from pretty but it seems to work.
The
activator keeps track of installed bundles and their camel
resources
(such
as components and languages).
When I switch to Camel 2.4-SNAPSHOT I get the following
exception:
...
Caused by: org.apache.camel.ResolveEndpointFailedException:
Failed to
resolve en
dpoint:
file://data/connect/sample/file2ftps?delay=1000&move=archive%2F%24%7Bdat
e%3Anow%3AyyyyMMdd%7D%2F%24%7Bfile%3Aname%7D&moveFailed=failed%2F%24%7Bfile%3Ana
me.noext%7D-%24%7Bdate%3Anow%3AyyyyMMddHHmmssSSS%7D.%24%7Bfile%3Aext%7D
due
to:
No language could be found for: file
at
org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelCon
text.java:377)
...
It seems like Camel cannot find the "file" language (which is
supposed
to
be
mapped to the org.apache.camel.language.simple.SimpleLanguage
class).
I
then
tried to find the proper activator to find out why the language
doesn't
seem
to be registered.
First, the camel-spring-osgi bundle does not seem to exist in
camel
anymore.
Instead, the CamelContextFactory is now imported from the
camel-spring
bundle. camel-spring's activator
(org.apache.camel.osgi.Activator) is
now
part of the camel-spring component but when I look at it I can't
see
that
it
keeps track of anything but it's own BundleContext and Bundle
instance.
Then
who keeps track of the registered components, type converters,
languages
and
so forth?
I must be missing something here. Can someone please explain to
me
how
to
use Camel 2.4 in OSGi? I must say I've had a lot of problems with
the
combination of camel and OSGi before as well but I was hoping for
Camel's
OSGi support to get better - right now I'm a bit disillusioned
:-(
I noticed that camel-osgi still exists in Camel 2.4 but it
doesn't
look
like
a bundle anymore. Maybe there is a secret here that I haven't
fully
understood.
/Bengt
2010/6/7 Claus Ibsen <claus.ib...@gmail.com>
On Mon, Jun 7, 2010 at 4:30 PM, Bengt Rodehav <
be...@rodehav.com>
wrote:
Claus,
I have now tested my version using both passive and active
(which
requires a
certificate) mode. I've tested against a free ftp server -
Filezilla -
and a
commercial ftp server (that we often use) - Serv-u. It works
fine.
I haven't tested your version yet because it requires me to
build
my
application against Camel version 2.4-SNAPSHOT instead of Camel
version
2.3.0. To get this to work I need to get all the 2-4-SNAPSHOT
artifacts
into
my local Maven repository. I tried to do this by building
Camel
locally
but
I never seem to get it to build. Right now, I'm stuck with
the
following
Maven error message (I'm usng Maven 2.0.11):
You can just cd into camel-ftp and build that jar. And then
you
grab
the camel-core jar as well.
And if you use spring then camel-spring .jar as well. Then you
got
what you need for 2.4-SNAPSHOTs.
Yeah Maven can be strange. Sometimes you need to nuke you local
m2
repo
cache.
And I use maven 2.0.9.
[INFO] Writing OBR metadata
[INFO]
------------------------------------------------------------------------
[INFO] Building Camel :: Jetty
[INFO] task-segment: [clean, install]
[INFO]
------------------------------------------------------------------------
[INFO] [clean:clean]
Downloading:
https://repository.apache.org/content/repositories/releases//com/su
n/mail/all/1.4.3/all-1.4.3.pom
[INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3' in
repository
apache
.releases (
https://repository.apache.org/content/repositories/releases/
)
Downloading:
http://svn.apache.org/repos/asf/servicemix/m2-repo/com/sun/mail/all
/1.4.3/all-1.4.3.pom
[INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3' in
repository
servic
emix (http://svn.apache.org/repos/asf/servicemix/m2-repo)
Downloading:
http://jansi.fusesource.org/repo/release/com/sun/mail/all/1.4.3/all
-1.4.3.pom
[INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3' in
repository
jansi.
release.m2 (http://jansi.fusesource.org/repo/release)
Downloading:
http://repository.ops4j.org/maven2/com/sun/mail/all/1.4.3/all-1.4.3
.pom
[INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3' in
repository
ops4j
(http://repository.ops4j.org/maven2)
Downloading:
http://repo1.maven.org/maven2/com/sun/mail/all/1.4.3/all-1.4.3.pom
[INFO] Unable to find resource 'com.sun.mail:all:pom:1.4.3' in
repository
centra
l (http://repo1.maven.org/maven2)
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: javax.mail:mail:jar:null
Reason: Cannot find parent: com.sun.mail:all for project:
javax.mail:mail:jar:nu
ll for project javax.mail:mail:jar:null
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 4 minutes 26 seconds
[INFO] Finished at: Mon Jun 07 12:59:05 CEST 2010
[INFO] Final Memory: 231M/483M
[INFO]
------------------------------------------------------------------------
/Bengt
2010/6/5 Bengt Rodehav <be...@rodehav.com>
God you're fast. I made my own attempts and attached diff
files to
the
JIRA
issue you created. I also added a couple of
comments/suggestions to
the
issue.
In short I believe that it is probably easier for the
user/developer
if
it
is enough to specify whether a secure data channel should be
used
or
not
(the default should be true). Adding more detailed options,
like
you
did, is
of course just a benefit as long as it is possible to also
configure
it
the
easy way (like I described).
I haven't tested your changes yet - will do. I have done some
limited
testing with my own version, but only in passive mode. If you
use
a
secure
data channel in active mode one must first create a
public/private
key
pair
for the ftps client to use and I haven't gotten around to
testing
that
yet.
/Bengt
2010/6/4 Claus Ibsen <claus.ib...@gmail.com>
Hi
On Fri, Jun 4, 2010 at 3:42 PM, Bengt Rodehav <
be...@rodehav.com
wrote:
OK, will try to do that sometime this weekend.
Will be in touch,
I was one step ahead of you. I created the ticket and took a
stab
at
resolving it.
https://issues.apache.org/activemq/browse/CAMEL-2790
Can you try with the latest source code? And maybe if there
is
still
some issue then work on a patch from there.
Would be lovely with an unit test, but the test ftp server we
use
cannot understand the secure data transfer.
Anyway would be awesome if you could test it on your real
systems.
/Bengt
2010/6/4 Claus Ibsen <claus.ib...@gmail.com>
Hi
Well spotted. Do you mind creating a JIRA ticket and link
to
this
post
using nabble etc.
And you may even want to contribute a patch :)
On Fri, Jun 4, 2010 at 11:34 AM, Bengt Rodehav <
be...@rodehav.com
wrote:
I'm using camel-ftp for secure ftps communication. I need
to be
able
to
connect to a wide range of ftps servers in both explicit and
implicit
mode.
I have encountered problems using camel-ftp for ftps
communication
in
implicit mode.
Some ftps servers require that the file transfer is
encrypted
(not
just
the
commands). This is of course very natural and is the reason
why
ftps
is
chosen in the first place. However, commons-net (which
camel-ftp
uses)
does
(for some reason) not by default setup a secure channel for
file
transfers.
It has to be requested by code similar to the following:
ftpsClient.execPBSZ(0);
ftpsClient.execPROT("P");
I suggest to add an option to camel-ftp, regarding ftps,
to
make
it
possible
to specify whether the data channel will be encrypted or
not.
Encrypted
should be default.
When looking at the code in camel-ftp it seems like there
is no
special
handling during connect for ftps compared to ftp. Thus
there is
no
natural
place to put the above code. One way is to add something
like
the
following
at the end of the method "connect" in the class
"FtpOperations":
if(client instanceof FTPSClient) {
FTPSClient ftpsClient = (FTPSClient)client;
try {
if (useSecureDataChannel) { // useSecureDataChannel
should
be
initialized from the configuration somehow
ftpsClient.execPBSZ(0);
ftpsClient.execPROT("P");
}
} catch (SSLException e) {
throw new
GenericFileOperationFailedException(client.getReplyCode(),
client.getReplyString(), e.getMessage(), e);
} catch (IOException e) {
throw new
GenericFileOperationFailedException(client.getReplyCode(),
client.getReplyString(), e.getMessage(), e);
}
}
Am I the only one having problems with this? Maybe there
is a
workaround
that I haven't figured out.
/Bengt
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
