Creative Overflow LogoCreative Overflow

Creative Overflow

hamburger menu icon
search
Open right sidebar
  • HomeHome
  • CommunityCommunity
  • CollectionsCollections
  • Find JobsFind Jobs
  • TagsTags
  • Ask a questionAsk a question
Sign InSign InSign UpSign Up

Top Questions

Environment Variables are no longer decrypted after update to spring boot 3.5 with jasypt

Chevron

Why not call a fetch function eagerly when it is not even awaited

Chevron

Show where in a class implementation an interface is used?

Chevron

gdal2tiles.py hangs when run in Conda Docker environment

Chevron

Popular Tags

javascript

1

spring

1

python

1

c#

1

jasypt

1

All Questions

search icon

Show where in a class implementation an interface is used?

Given ``` public MyClass<T> where T: MyInterface ``` I want to know all places where in MyClass properties or methods from MyInterface are called. Can I somehow view this in Rider?

stars icon
c#rider
maen ababneh

maen ababneh

• asked 2 month ago• 2 month ago
upvote icon

1 Upvotes

views icon

88 Views

answer icon

1 Answers

gdal2tiles.py hangs when run in Conda Docker environment

I'm running a Python script inside a Conda-based Docker container that processes geospatial data. The script runs a two step GDAL workflow, it uses gdaldem colorrelief to create a colorized GeoTIFF, and `gdal2tiles.py` to generate map tiles from that result. Gdaldem completes successfully every time. However, the script hangs indefinitely as soon as it calls `gdal2tiles.py`... It produces no error output, and surprisingly, even the timeout argument in `subprocess.run` does not trigger an exception, the whole process just freezes with these log: ``` 2025-08-02 09:53:22,602 - INFO - Successfully created GeoTIFF: /app/geotiffs/skjav/reflectivity/reflectivity_20250802T094500Z.tif 2025-08-02 09:53:22,636 - INFO - Step 1: Colorizing /app/geotiffs/skjav/reflectivity/reflectivity_20250802T094500Z.tif with gdaldem. 2025-08-02 09:53:22,672 - INFO - Successfully colorized GeoTIFF to /app/static/tiles/skjav/reflectivity/20250802T094500Z/colorized.tif 2025-08-02 09:53:22,672 - INFO - Step 2: Generating tiles from /app/static/tiles/skjav/reflectivity/20250802T094500Z/colorized.tif with gdal2tiles.py. <-- HANGS HERE --> ``` The code snippet in question: ``` try: logging.info(f"coloring with with gdaldem.") color_map_content = create_color_map_file(product_config['cmap'], product_config['vmin'], product_config['vmax']) with open(color_file_path, 'w') as f: f.write(color_map_content) cmd_colorize = ['gdaldem', 'color-relief', geotiff_path, color_file_path, colorized_tiff_path, '-alpha'] subprocess.run(cmd_colorize, check=True, capture_output=True, text=True, timeout=60) logging.info(f"colored geotiff to {colorized_tiff_path}") logging.info(f"generating tiles {colorized_tiff_path} with gdal2tiles.py.") cmd_gdal2tiles = [ 'gdal2tiles.py', '--profile=raster', '--zoom=5-12', '--webp-quality=90', colorized_tiff_path, output_tile_dir ] subprocess.run(cmd_gdal2tiles, check=True, capture_output=True, text=True, timeout=180) logging.info(f"success - {output_tile_dir}") return output_tile_dir ``` What could cause `gdal2tiles.py` to hang so completely that it ignores the timeout from Python's subprocess module? Is there a known issue with running `gdal2tiles.py` non interactively from a Python script inside a Docker container that could lead to this kind of deadlock? Ruled out Environment Path Issues: I added a diagnostic log (`shutil.which('gdal2tiles.py')`) which confirmed the script is correctly finding the modern version of `gdal2tiles.py` inside the conda environment (`/opt/conda/envs/radar-env/bin/gdal2tiles.py`). Ruled out Multiprocessing: The hang occurs even with the `--processes` flag removed from the command. Ruled out output format: The hang persists whether I use `--webp-quality=90` or remove it to default to png tiles. I also tried to replaced subprocess.run with the lower-level `subprocess.Popen` and `proc.communicate(timeout=)` this also hung and failed to trigger the `TimeoutExpired` exception.

Environment Variables are no longer decrypted after update to spring boot 3.5 with jasypt

# We are using spring boot with the jasypt-spring-boot library to decrypt passwords. # After the update from spring boot 3.4.7 to 3.5.3, the decryption of environment variables is no longer working. # The reason for that seems to be the performance optimization of [https://github.com/spring-projects/spring-boot/issues/44862.](https://github.com/spring-projects/spring-boot/issues/44862.) For system environment property sources, it bypasses the property source itself with the decryption logic (with jasyspt, it is the EncryptableSystemEnvironmentPropertySourceWrapper) and just accesses the underlying map directly. # There is already an issue for the problem in the jasypt-spring-boot project: [https://github.com/ulisesbocchio/jasypt-spring-boot/issues/409](https://github.com/ulisesbocchio/jasypt-spring-boot/issues/409) The workaround mentioned there is not working for us. Wrapping the SystemEnvironmentPropertySource in a CompositePropertySource prevents the property source from being recognized as the systemEnvironment (see SpringConfigurationPropertySource.isSystemEnvironmentPropertySource). So the optimization is not used and the properties are decrypted again. But that leads to other unintended problems, for example other environment variables were no longer bound correctly (probably because the SystemEnvironmentPropertyMapper was not added as a direct result of the property source not being recognized as systemEnvironment). # Looking at the spring boot code, I don't see a straight forward way to change the jasypt-spring-boot library or just call the decryption logic from another place. Are there any recommondations from the spring boot side on where to add logic like decrypting environment variables? Does anybody know of a better workaround? Any help is appreciated, thank you.

Why not call a fetch function eagerly when it is not even awaited

I get this message in my terminal when running my svelte frontend: ``` Avoid calling `fetch` eagerly during server side rendering — put your `fetch` calls inside `onMount` or a `load` function instead ``` I understand what it says and I can definitely put it in an onMount function, however, I don't see the meaning of it. Imagine this example application, that is close to how I use it: ``` <script lang="ts"> let response: Promise<string> = $state(loadData()); async function loadData(): Promise<string> { const response = await fetch("http://my_endpoint"); return response.json(); } </script> {#await response} LOADING {:then response} {response} {/await} ``` What I am trying to point at is that the async function `loadData` is not awaited in the script tag. Only via the await directive in the template. I don't see how this could be blocking more than any other normal function call. I wonder if that is just a case that was overlooked when programming this warning or if I create a real mistake that will bite me in the ass in a larger project.

javascript

1

stars icon
pythondocker
maen ababneh

maen ababneh

• asked 2 month ago• 2 month ago
upvote icon

0 Upvotes

views icon

4 Views

answer icon

0 Answers

jasypt
spring
maen ababneh

maen ababneh

• asked 2 month ago• 2 month ago
upvote icon

1 Upvotes

views icon

342 Views

answer icon

1 Answers

maen ababneh

maen ababneh

• asked 2 month ago• 2 month ago
upvote icon

1 Upvotes

views icon

119 Views

answer icon

0 Answers

stars icon
stars icon