Re: [PR] JCLOUDS-1629: Upgrade to Guice 7.0.0 [jclouds]

2024-02-23 Thread via GitHub 


gaul commented on code in PR #197:
URL: https://github.com/apache/jclouds/pull/197#discussion_r1501345917


##
project/pom.xml:
##
@@ -223,7 +223,7 @@
 
 2.10.1
 32.0.0-jre
-5.1.0
+7.0.0

Review Comment:
   You are welcome to investigate the failures with 6.0.0 but I don't have the 
time or the interest:
   
   ```
jclouds-compute: Compilation failure
   [ERROR] 
/home/gaul/work/jclouds/compute/src/main/java/org/jclouds/compute/config/BaseComputeServiceContextModule.java:[9
   2,71] no suitable method found for 
toProvider(java.lang.Class)
   [ERROR] method 
com.google.inject.binder.LinkedBindingBuilder.toProvider(com.google.inject.Provider) is not applicable
   [ERROR]   (argument mismatch; 
java.lang.Class cannot be converted to com.google.inject.Provider)
   [ERROR] method 
com.google.inject.binder.LinkedBindingBuilder.toProvider(javax.inject.Provider) is not applicable
   [ERROR]   (argument mismatch; 
java.lang.Class
 cannot be converted to javax.inject.Provider)
   [ERROR] method 
com.google.inject.binder.LinkedBindingBuilder.toProvider(java.lang.Class>) 
is not applicable
   [ERROR]   (argument mismatch; 
java.lang.Class
 cannot be converted to java.lang.Class>)
   [ERROR] method 
com.google.inject.binder.LinkedBindingBuilder.toProvider(com.google.inject.TypeLiteral>) 
is not applicable
   [ERROR]   (argument mismatch; 
java.lang.Class
 cannot be converted to com.google.inject.TypeLiteral>)
   [ERROR] method 
com.google.inject.binder.LinkedBindingBuilder.toProvider(com.google.inject.Key>) 
is not applicable
   [ERROR]   (argument mismatch; 
java.lang.Class
 cannot be converted to com.google.inject.Key>)
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@jclouds.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (JCLOUDS-1629) Upgrade to Guice 7

2024-02-23 Thread Basil Crow (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820255#comment-17820255
 ] 

Basil Crow commented on JCLOUDS-1629:
-

bq. When changing these to Jakarta I could get Guice 7 working but not 6.

I don't have any ideas offhand. If Guice 7 is working but not Guice 6, then 
maybe it would make sense to file a Guice ticket about this.

> Upgrade to Guice 7
> --
>
> Key: JCLOUDS-1629
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1629
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.5.0
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
>  Labels: guice
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [~basil] JCLOUDS-1627 upgrading some of the packages to jakarta but not the 
> important annotations one for Guice.  When changing these to Jakarta I could 
> get Guice 7 working but not 6.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCLOUDS-1371) LocalBlobStore.list enumerates entire container

2024-02-23 Thread Basil Crow (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820254#comment-17820254
 ] 

Basil Crow commented on JCLOUDS-1371:
-

Our usage is at 
https://github.com/jenkinsci/artifact-manager-s3-plugin/blob/1239f6b0f5820075ebf8f37096f86e198f22adf6/src/test/java/io/jenkins/plugins/artifact_manager_jclouds/MockApiMetadata.java#L193-L202.
 I am not the original author of the code, so I cannot comment on why it was 
done this way.

> LocalBlobStore.list enumerates entire container
> ---
>
> Key: JCLOUDS-1371
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1371
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-blobstore
>Affects Versions: 2.0.3
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
>  Labels: filesystem
> Fix For: 2.5.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {{LocalBlobStore.list}} with the filesystem blobstore enumerates the entire 
> container even when prefix and delimiter set.  The File API does not provide 
> a way to list a subset of files except for those within a specific directory 
> and the underlying filesystem makes no guarantees about enumeration order.  
> We can still optimize the case where prefix is set and delimiter is /.  
> Reference:
> https://lists.apache.org/thread.html/72e8a101d8a8f99b6f728336633db2cecae1dc443e4c5b195eee8f0d@%3Cuser.jclouds.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] JCLOUDS-1629: Upgrade to Guice 7.0.0 [jclouds]

2024-02-23 Thread via GitHub 


basil commented on code in PR #197:
URL: https://github.com/apache/jclouds/pull/197#discussion_r1501311432


##
project/pom.xml:
##
@@ -223,7 +223,7 @@
 
 2.10.1
 32.0.0-jre
-5.1.0
+7.0.0

Review Comment:
   ```suggestion
   6.0.0
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@jclouds.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (JCLOUDS-1629) Upgrade to Guice 7

2024-02-23 Thread Andrew Gaul (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820242#comment-17820242
 ] 

Andrew Gaul commented on JCLOUDS-1629:
--

Could use some help here: https://github.com/apache/jclouds/pull/197

> Upgrade to Guice 7
> --
>
> Key: JCLOUDS-1629
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1629
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.5.0
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
>  Labels: guice
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> [~basil] JCLOUDS-1627 upgrading some of the packages to jakarta but not the 
> important annotations one for Guice.  When changing these to Jakarta I could 
> get Guice 7 working but not 6.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PR] JCLOUDS-1629: Upgrade to Guice 7.0.0 [jclouds]

2024-02-23 Thread via GitHub 


gaul opened a new pull request, #197:
URL: https://github.com/apache/jclouds/pull/197

   This also changes from javax to jakarta annotations.  @basil


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@jclouds.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (JCLOUDS-1629) Upgrade to Guice 7

2024-02-23 Thread Andrew Gaul (Jira) 
Andrew Gaul created JCLOUDS-1629:


 Summary: Upgrade to Guice 7
 Key: JCLOUDS-1629
 URL: https://issues.apache.org/jira/browse/JCLOUDS-1629
 Project: jclouds
  Issue Type: Improvement
  Components: jclouds-core
Affects Versions: 2.5.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul


[~basil] JCLOUDS-1627 upgrading some of the packages to jakarta but not the 
important annotations one for Guice.  When changing these to Jakarta I could 
get Guice 7 working but not 6.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCLOUDS-1371) LocalBlobStore.list enumerates entire container

2024-02-23 Thread Andrew Gaul (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820237#comment-17820237
 ] 

Andrew Gaul commented on JCLOUDS-1371:
--

If you'd like you can submit a PR but I don't consider this part of the public 
API.  Why are you implementing LocalStorageStrategy?  The in-memory transient 
implementation should suffice for tests.

> LocalBlobStore.list enumerates entire container
> ---
>
> Key: JCLOUDS-1371
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1371
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-blobstore
>Affects Versions: 2.0.3
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
>  Labels: filesystem
> Fix For: 2.5.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {{LocalBlobStore.list}} with the filesystem blobstore enumerates the entire 
> container even when prefix and delimiter set.  The File API does not provide 
> a way to list a subset of files except for those within a specific directory 
> and the underlying filesystem makes no guarantees about enumeration order.  
> We can still optimize the case where prefix is set and delimiter is /.  
> Reference:
> https://lists.apache.org/thread.html/72e8a101d8a8f99b6f728336633db2cecae1dc443e4c5b195eee8f0d@%3Cuser.jclouds.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCLOUDS-1371) LocalBlobStore.list enumerates entire container

2024-02-23 Thread Basil Crow (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820150#comment-17820150
 ] 

Basil Crow commented on JCLOUDS-1371:
-

The addition of the {{delimiter}} argument in the last commit broke API 
compatibility and required me to add the new parameter to my mock 
implementation of {{LocalStorageStrategy}} in order for my project to compile 
again. Should this API change be documented before the next release?

> LocalBlobStore.list enumerates entire container
> ---
>
> Key: JCLOUDS-1371
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1371
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-blobstore
>Affects Versions: 2.0.3
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
>  Labels: filesystem
> Fix For: 2.5.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {{LocalBlobStore.list}} with the filesystem blobstore enumerates the entire 
> container even when prefix and delimiter set.  The File API does not provide 
> a way to list a subset of files except for those within a specific directory 
> and the underlying filesystem makes no guarantees about enumeration order.  
> We can still optimize the case where prefix is set and delimiter is /.  
> Reference:
> https://lists.apache.org/thread.html/72e8a101d8a8f99b6f728336633db2cecae1dc443e4c5b195eee8f0d@%3Cuser.jclouds.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCLOUDS-1627) Java Jakarta Support

2024-02-23 Thread Basil Crow (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820144#comment-17820144
 ] 

Basil Crow commented on JCLOUDS-1627:
-

[~gaul] I have tested 2.6.0-SNAPSHOT at commit b5e4e1d0fd with [Artifact 
Manager on S3|https://plugins.jenkins.io/artifact-manager-s3/] running against 
Guice 7. I still get the following exception:

{noformat}
java.lang.NoClassDefFoundError: javax/inject/Provider
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at 
java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3549)
at java.base/java.lang.Class.getDeclaredConstructors(Class.java:2727)
at 
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:299)
at 
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:121)
at 
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:737)
at 
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:982)
at 
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:902)
at 
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:302)
at 
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:225)
at 
com.google.inject.internal.InjectorImpl.createParameterInjector(InjectorImpl.java:1083)
at 
com.google.inject.internal.InjectorImpl.getParametersInjectors(InjectorImpl.java:1070)
at 
com.google.inject.internal.ProviderMethod.initialize(ProviderMethod.java:164)
at 
com.google.inject.internal.InternalProviderInstanceBindingImpl.initialize(InternalProviderInstanceBindingImpl.java:64)
at 
com.google.inject.internal.InjectorImpl.initializeBinding(InjectorImpl.java:593)
at 
com.google.inject.internal.AbstractBindingProcessor$Processor.initializeBinding(AbstractBindingProcessor.java:176)
at 
com.google.inject.internal.AbstractBindingProcessor$Processor.lambda$scheduleInitialization$0(AbstractBindingProcessor.java:163)
at 
com.google.inject.internal.ProcessedBindingData.initializeBindings(ProcessedBindingData.java:49)
at 
com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:126)
at 
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:110)
at com.google.inject.Guice.createInjector(Guice.java:87)
at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:405)
at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:328)
at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:615)
at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:595)
at 
io.jenkins.plugins.artifact_manager_jclouds.s3.S3BlobStore.getContext(S3BlobStore.java:136)
at 
io.jenkins.plugins.artifact_manager_jclouds.s3.CustomBehaviorBlobStoreProvider.getContext(CustomBehaviorBlobStoreProvider.java:68)
at 
io.jenkins.plugins.artifact_manager_jclouds.JCloudsArtifactManager.getContext(JCloudsArtifactManager.java:384)
at 
io.jenkins.plugins.artifact_manager_jclouds.JCloudsArtifactManager.archive(JCloudsArtifactManager.java:127)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:257)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:80)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:818)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:767)
at hudson.model.Build$BuildExecution.post2(Build.java:179)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:711)
at hudson.model.Run.execute(Run.java:1918)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at hudson.model.Executor.run(Executor.java:442)
{noformat}

> Java Jakarta Support
> 
>
> Key: JCLOUDS-1627
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1627
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.5.0
>Reporter: Paolo Bazzi
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.6.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Module jclouds-core (latest version 2.5.0) depends on non-jakarta version of 
> javax APIs:
> - javax.annotation » javax.annotation-api
> - javax.ws.rs » javax.ws.rs-api
>  
> Are there any plans to release a version based on new Jakarta APIs

[jira] [Commented] (JCLOUDS-1626) `FileInputStream` leak when using `filesystem` provider and performing a multipart upload

2024-02-23 Thread Andrew Gaul (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819995#comment-17819995
 ] 

Andrew Gaul commented on JCLOUDS-1626:
--

I don't quite understand this issue since it appears to be specific to S3Proxy? 
 Where in jclouds does it not close the {{{}FileInputStream{}}}?

> `FileInputStream` leak when using `filesystem` provider and performing a 
> multipart upload
> -
>
> Key: JCLOUDS-1626
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1626
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Ji Xinchi
>Priority: Critical
>  Labels: filesystem
>
> I'm using gaul/s3proxy built on the latest jclouds. The provider 
> configuration is "filesystem", and basedir configuration is a directory where 
> a NFS is mounted.
>  
> When I performed a multipart upload, I found that files such as 
> ".nfs10bf0005" remained in the directory after uploading. 
> Each file corresponded to one part and the files could not be deleted. The 
> error "Device Busy" was reported. These files will disappear automatically 
> after restarting s3proxy.
>  
> I found this PR, and tried to restore following snippet and it worked. But 
> this is just a temporary fix.
> {code:java}
>  InputStream is = blob.getPayload().openStream();
>  if (is instanceof FileInputStream) {
> // except for FileInputStream since large MPU can open too many 
> fds
> is.close();
> payload = blob.getPayload();
>  } else {
> blob.resetPayload(/*release=*/ false);
> payload = new InputStreamPayload(is);
>  } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Build failed in Jenkins: JClouds » jclouds #102

2024-02-23 Thread Apache Jenkins Server 
See 


Changes:

[Andrew Gaul] JCLOUDS-1627: Upgrade to Jakarta packages


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on builds26 (ubuntu) in workspace 

The recommended git tool is: NONE
No credentials specified
 > git rev-parse --resolve-git-dir 
 >  # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://gitbox.apache.org/repos/asf/jclouds.git 
 > # timeout=10
Fetching upstream changes from https://gitbox.apache.org/repos/asf/jclouds.git
 > git --version # timeout=10
 > git --version # 'git version 2.34.1'
 > git fetch --tags --force --progress -- 
 > https://gitbox.apache.org/repos/asf/jclouds.git 
 > +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision b5e4e1d0fd466dffcbb0fb7921e52732145cc732 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b5e4e1d0fd466dffcbb0fb7921e52732145cc732 # timeout=10
Commit message: "JCLOUDS-1627: Upgrade to Jakarta packages"
 > git rev-list --no-walk 6bb738195fdfd8d3fcd4003721c1ffe3f6a920a0 # timeout=10
[EnvInject] - Executing scripts and injecting environment variables after the 
SCM step.
[EnvInject] - Injecting as environment variables the properties content 
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8

[EnvInject] - Variables injected successfully.
Parsing POMs
Modules changed, recalculating dependency graph
Established TCP socket on 39897
maven35-agent.jar already up to date
maven35-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[jclouds] $ /home/jenkins/tools/java/latest1.8/bin/java -cp 
/home/jenkins/jenkins-agent/maven35-agent.jar:/home/jenkins/tools/maven/apache-maven-3.5.4/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.5.4/conf/logging
 jenkins.maven3.agent.Maven35Main /home/jenkins/tools/maven/apache-maven-3.5.4 
/home/jenkins/jenkins-agent/agent.jar 
/home/jenkins/jenkins-agent/maven35-interceptor.jar 
/home/jenkins/jenkins-agent/maven3-interceptor-commons.jar 39897
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher has been compiled by a more recent version of the Java 
Runtime (class file version 55.0), this version of the Java Runtime only 
recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:136)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:66)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:459)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:404)
at hudson.slaves.Channels.forProcess(Channels.java:121)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:298)
at hudson.maven.ProcessCache.get(ProcessCache.java:237)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:802)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:526)
at hudson.model.Run.execute(Run.java:1841)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at hudson.model.Executor.run(Executor.java:442)

[jira] [Updated] (JCLOUDS-1626) `FileInputStream` leak when using `filesystem` provider and performing a multipart upload

2024-02-23 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul updated JCLOUDS-1626:
-
Labels: filesystem  (was: )

> `FileInputStream` leak when using `filesystem` provider and performing a 
> multipart upload
> -
>
> Key: JCLOUDS-1626
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1626
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Ji Xinchi
>Priority: Critical
>  Labels: filesystem
>
> I'm using gaul/s3proxy built on the latest jclouds. The provider 
> configuration is "filesystem", and basedir configuration is a directory where 
> a NFS is mounted.
>  
> When I performed a multipart upload, I found that files such as 
> ".nfs10bf0005" remained in the directory after uploading. 
> Each file corresponded to one part and the files could not be deleted. The 
> error "Device Busy" was reported. These files will disappear automatically 
> after restarting s3proxy.
>  
> I found this PR, and tried to restore following snippet and it worked. But 
> this is just a temporary fix.
> {code:java}
>  InputStream is = blob.getPayload().openStream();
>  if (is instanceof FileInputStream) {
> // except for FileInputStream since large MPU can open too many 
> fds
> is.close();
> payload = blob.getPayload();
>  } else {
> blob.resetPayload(/*release=*/ false);
> payload = new InputStreamPayload(is);
>  } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCLOUDS-747) Determine level of android support and how to ensure we keep it.

2024-02-23 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-747.
-
Resolution: Won't Fix

Android is out of scope.

> Determine level of android support and how to ensure we keep it.
> 
>
> Key: JCLOUDS-747
> URL: https://issues.apache.org/jira/browse/JCLOUDS-747
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Reporter: Adrian Cole
>Priority: Major
>
> One of the knock-on effects of moving on is tracking how we deal with 
> android. One way is to establish a floor android level we aim to support 
> (even if it is best efforts). That's due to the fact that android != java and 
> only a subset of features are present, on each version. Here's a handy link 
> that begins to discuss this complexity.
> http://stackoverflow.com/questions/20480090/does-android-support-jdk-6-or-7
> Modern android libraries typically use a combination of plugins and 
> integration tests to ensure android isn't accidentally broken. Some projects 
> just rely on folks to remember the rules.
> Here's an example of a signature-checking plugin
> {code}
>   
> org.codehaus.mojo
> animal-sniffer-maven-plugin
> ${animal.sniffer.version}
> 
>   
> test
> 
>   check
> 
>   
> 
> 
>   
> org.codehaus.mojo.signature
> java16
> 1.1
>   
> 
>   
> {code}
> In short, I think we should be careful and consciously decide whether certain 
> features that break some level of android support are worthwhile. We should 
> also note that entrypoints that aren't used by android callers will not 
> affect compatibility. In other words, we are most concerned with the common 
> paths.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCLOUDS-1627) Java Jakarta Support

2024-02-23 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1627.
--
Fix Version/s: 2.6.0
   Resolution: Fixed

Please wait a few hours for mirrors to propagate then test 2.6.0-SNAPSHOT to 
see if it resolves your symptoms.

> Java Jakarta Support
> 
>
> Key: JCLOUDS-1627
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1627
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.5.0
>Reporter: Paolo Bazzi
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.6.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Module jclouds-core (latest version 2.5.0) depends on non-jakarta version of 
> javax APIs:
> - javax.annotation » javax.annotation-api
> - javax.ws.rs » javax.ws.rs-api
>  
> Are there any plans to release a version based on new Jakarta APIs instead of 
> former javax modules?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCLOUDS-1627) Java Jakarta Support

2024-02-23 Thread ASF subversion and git services (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819981#comment-17819981
 ] 

ASF subversion and git services commented on JCLOUDS-1627:
--

Commit b5e4e1d0fd466dffcbb0fb7921e52732145cc732 in jclouds's branch 
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=b5e4e1d0fd ]

JCLOUDS-1627: Upgrade to Jakarta packages

This resolves an issue with newer Guice versions.


> Java Jakarta Support
> 
>
> Key: JCLOUDS-1627
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1627
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.5.0
>Reporter: Paolo Bazzi
>Assignee: Andrew Gaul
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Module jclouds-core (latest version 2.5.0) depends on non-jakarta version of 
> javax APIs:
> - javax.annotation » javax.annotation-api
> - javax.ws.rs » javax.ws.rs-api
>  
> Are there any plans to release a version based on new Jakarta APIs instead of 
> former javax modules?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] JCLOUDS-1627: Upgrade to Jakarta packages [jclouds]

2024-02-23 Thread via GitHub 


gaul merged PR #196:
URL: https://github.com/apache/jclouds/pull/196


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@jclouds.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (JCLOUDS-1131) jclouds-2.0.0 not compatible with gson-2.7

2024-02-23 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1131.
--
Fix Version/s: 2.3.0
 Assignee: Andrew Gaul
   Resolution: Fixed

> jclouds-2.0.0 not compatible with gson-2.7
> --
>
> Key: JCLOUDS-1131
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1131
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 2.0.0
>Reporter: Olivier Voortman
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.3.0
>
>
> It seems jclouds is using some of gson internal classes, which is wrong.
> There is now an incompatibility in jclouds-core-2.0.0-SNAPSHOT.jar.
> The class 
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory
>  is importing com.google.gson.internal.bind.ReflectiveTypeAdapterFactory 
> which is clearly marked as internal.
> There is now a 4th parameter on the constructor since gson-2.7.
> Is it something that you can fix, maybe by cloning that 
> ReflectiveTypeAdapterFactory inside your packages ?
> Thanks.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] JCLOUDS-1627: Upgrade to Jakarta packages [jclouds]

2024-02-23 Thread via GitHub 


gaul commented on PR #196:
URL: https://github.com/apache/jclouds/pull/196#issuecomment-1960958222

   Not using the latest versions since they are not compatible with Java 8.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@jclouds.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (JCLOUDS-1101) JDK 9 compatibility

2024-02-23 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1101.
--
Fix Version/s: 2.4.0
   Resolution: Fixed

> JDK 9 compatibility
> ---
>
> Key: JCLOUDS-1101
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1101
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 2.1.0
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.4.0
>
>
> Compiling with JDK 9 build 111 yields:
> {noformat}
> [ERROR] COMPILATION ERROR : 
> [ERROR] 
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/json/internal/NamingStrategies.java:[264,36]
>  incompatible types: com.google.common.base.Predicate java.lang.Class> cannot be 
> converted to com.google.common.base.Predicate extends java.lang.annotation.Annotation>>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) 
> on project jclouds-core: Compilation failure
> [ERROR] 
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/json/internal/NamingStrategies.java:[264,36]
>  incompatible types: com.google.common.base.Predicate java.lang.Class> cannot be 
> converted to com.google.common.base.Predicate extends java.lang.annotation.Annotation>>
> {noformat}
> Apparently our code is incorrect:
> https://bugs.openjdk.java.net/browse/JDK-8075793



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCLOUDS-1402) openjdk9 - An illegal reflective access operation has occurred

2024-02-23 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1402.
--
Fix Version/s: 2.5.0
 Assignee: Andrew Gaul
   Resolution: Fixed

I believe JCLOUDS-1586 addressed this.

> openjdk9 - An illegal reflective access operation has occurred
> --
>
> Key: JCLOUDS-1402
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1402
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 2.1.0
> Environment: $ uname -r
> 4.15.14-1-ARCH
> $ archlinux-java status
> Available Java environments:
>   java-9-openjdk (default)
>Reporter: Mathieu Tortuyaux
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.5.0
>
>
> Hi ! 
> While trying to run [this 
> example|https://github.com/jclouds/jclouds-examples/blob/master/google-lb/src/main/java/org/jclouds/examples/google/lb/MainApp.java],
>  I got the following warning: 
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> com.google.inject.internal.cglib.core.$ReflectUtils$2 
> (file:/home/mathieu/Desktop/lab/jclouds-optel/test/target/cloud-scheduler-1.0-SNAPSHOT-shaded.jar)
>  to method 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of 
> com.google.inject.internal.cglib.core.$ReflectUtils$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> After a few searches, I found that this is a known issue caused by 
> Google/Guice and one one his dependency: cglib. It has been fixed in 
> Google/Guice release 4.2. But jclouds-core is using Google/Guice release 3.0
> {noformat}
> $ mvn dependency:tree | grep guice -B 2
> [INFO] |  |  \- org.apache.jclouds:jclouds-core:jar:2.1.0:compile
> [INFO] |  | +- javax.ws.rs:javax.ws.rs-api:jar:2.0.1:compile
> [INFO] |  | +- 
> com.google.inject.extensions:guice-assistedinject:jar:3.0:compile
> [INFO] |  | +- com.google.inject:guice:jar:3.0:compile
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PR] JCLOUDS-1627: Upgrade to Jakarta packages [jclouds]

2024-02-23 Thread via GitHub 


gaul opened a new pull request, #196:
URL: https://github.com/apache/jclouds/pull/196

   This resolves an issue with newer Guice versions.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@jclouds.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org